.NET Aspire, aber nur für lokal
- Matt
.NET Aspire wird von Microsoft als Weg in die Cloud vermarktet, mit Deployment nach Azure und allem, was dazugehört. Genau deshalb habe ich es lange ignoriert, weil meine Projekte diesen Weg nicht gehen.
Dabei löst es ein Problem, das ich jeden Tag habe.
Das eigentliche Problem
Ein Projekt braucht eine Datenbank, einen Cache und zwei eigene Dienste. Der neue Kollege bekommt eine README mit acht Schritten, von denen zwei veraltet sind. Bis alles läuft, vergeht ein halber Tag. Das ist die Situation, die ich im Onboarding-Beitrag beschrieben habe, nur eben technisch.
Mit Aspire steht das in Code:
var builder = DistributedApplication.CreateBuilder(args);
var db = builder.AddPostgres("pg")
.WithDataVolume()
.AddDatabase("kundendb");
var cache = builder.AddRedis("cache");
builder.AddProject<Projects.Api>("api")
.WithReference(db)
.WithReference(cache);
builder.AddProject<Projects.Worker>("worker")
.WithReference(db);
builder.Build().Run();
Ein dotnet run im AppHost-Projekt startet die Container für Postgres und Redis, beide eigenen Projekte, und verdrahtet die Verbindungszeichenketten. Kein Docker-Compose, keine Umgebungsvariablen von Hand.
Das WithDataVolume() ist der Unterschied zwischen brauchbar und nervig: Ohne die Zeile ist die Datenbank nach jedem Neustart leer.
Das Dashboard
Der Teil, den ich unterschätzt hatte. Beim Start öffnet sich eine Oberfläche mit den Logs aller Dienste, den Metriken und vor allem den verteilten Traces. Ein Aufruf, der durch API, Datenbank und Worker läuft, ist dort als eine Kette sichtbar.
Das gibt es sonst nur mit einem Observability-Stack, den lokal niemand aufsetzt. Hier ist es beiläufig dabei, weil Aspire OpenTelemetry ohnehin verdrahtet.
Was ich nicht benutze
Das Deployment. Meine Anwendungen laufen auf Servern, die es seit Jahren gibt, und azd up hat dort nichts zu suchen. Aspire zwingt einen aber auch nicht dazu. Das AppHost-Projekt ist reine Entwicklungsumgebung und geht nie mit in Produktion.
Genau so würde ich es empfehlen: als besseres Docker-Compose mit Dashboard, nicht als Cloud-Strategie. Wenn später doch jemand nach Azure will, ist der Weg offen. Das ist ein netter Nebeneffekt, aber kein Grund.