.NET and ASP.NET Core auf Nodion deployen

.NET and ASP.NET Core Schritt für Schritt deployen

1. Ein Projekt im Root, sonst DOTNET_PROJECT Nodion veröffentlicht die eine .csproj oder .fsproj im Base Directory, Framework-abhängig. Bei mehreren Projekten oder einer Solution mit Projekten in Unterordnern setzt du auf dem Tab Environment DOTNET_PROJECT mit dem Häkchen Build auf den Pfad des Web-Projekts; im Root braucht es dann trotzdem eine .sln oder global.json, damit Nodion .NET erkennt. Das Base Directory auf den Projektordner zu setzen, klappt nur, wenn das Projekt keine Projekte außerhalb davon referenziert, denn der Build sieht nichts oberhalb dieses Ordners. Build variable

   DOTNET_PROJECT=src/MyApp.Web/MyApp.Web.csproj

2. Die Adresse Nodion überlassen Nodion startet die App mit ASPNETCORE_URLS=http://0.0.0.0:$PORT. Entferne fest eingetragene URLs wie app.Run("http://localhost:5000") und Kestrel-Endpoints in der appsettings.json, denn die haben Vorrang. Eine API ohne Seite unter / braucht einen Health-Endpoint; seinen Pfad trägst du in den App-Einstellungen als Health-Check-Pfad ein. Program.cs

   var builder = WebApplication.CreateBuilder(args);
   builder.Services.AddHealthChecks();
   
   var app = builder.Build();
   app.MapHealthChecks("/healthz");
   app.MapGet("/", () => "Hello from Nodion");
   
   app.Run();

3. AllowedHosts für den Health Check offen lassen Der Health Check ruft jede Instanz mit ihrer internen IP als Host auf. Der Template-Standard "AllowedHosts": "*" lässt ihn durch. Eine Liste deiner Domains lässt ASP.NET Core mit 400 antworten, und das Release geht nie live; bleib bei * oder prüf Hosts in einer eigenen Middleware, die den Health-Check-Pfad auslässt. appsettings.json

   {
     "AllowedHosts": "*"
   }

4. App anlegen und PostgreSQL anhängen Lege eine Application aus deinem Repository in der Region EU Central an, dann eine PostgreSQL-Datenbank in derselben Region. Npgsql arbeitet mit Key-Value-Connection-Strings, nicht mit postgres://-URLs wie DATABASE_URL. Lass dir beim Anhängen auf dem Tab Environment deshalb host, port, database, user und password unter eigenen Namen injizieren und bau daraus den Connection String. Program.cs

   var cs = new Npgsql.NpgsqlConnectionStringBuilder
   {
       Host = builder.Configuration["DB_HOST"],
       Port = int.Parse(builder.Configuration["DB_PORT"] ?? "5432"),
       Database = builder.Configuration["DB_NAME"],
       Username = builder.Configuration["DB_USER"],
       Password = builder.Configuration["DB_PASSWORD"],
   }.ConnectionString;
   builder.Services.AddDbContext<AppDbContext>(o => o.UseNpgsql(cs));

5. EF-Core-Migrationen anwenden Nodion führt keine EF-Core-Migrationen aus, und im Run-Image steckt kein SDK, dotnet ef kann also nicht als Release-Schritt laufen. Wende sie beim Start der App mit Database.Migrate() an, das passt für eine einzelne Instanz, oder wechsel zu einem Dockerfile, das ein EF-Core-Migration-Bundle baut und es als Release Command der App ausführt. Program.cs

   using (var scope = app.Services.CreateScope())
   {
       scope.ServiceProvider.GetRequiredService<AppDbContext>().Database.Migrate();
   }

Gut zu wissen

• SDK- und Runtime-VersionDie .NET-Version kommt aus der global.json, sonst aus dem TargetFramework des Projekts im Base Directory, sonst .NET 10, und das Run-Image bekommt die ASP.NET-Core-Runtime derselben Version. Ein Projekt im Unterordner wird dafür nicht gelesen; eine net8.0- oder net9.0-App, die du per DOTNET_PROJECT auswählst, braucht also eine global.json mit dieser Version. Nodion installiert das aktuelle SDK dieser Version, das ein neueres Feature Band sein kann; setz dort deshalb "rollForward": "latestFeature".
• Production-EinstellungenNodion setzt ASPNETCORE_ENVIRONMENT nicht, ASP.NET Core läuft also als Production und liest appsettings.Production.json zusätzlich zur appsettings.json. Secrets gehören in Environment-Variablen, die als Secret markiert sind; ConnectionStrings__Default wird zu ConnectionStrings:Default.

Was Nodion für dich betreibt

• Deploys ohne Downtime Push auf deinen Branch und Nodion baut ein neues Release. Der Traffic wechselt erst, wenn die neuen Instanzen ihren Health Check bestehen; ein fehlgeschlagenes Release lässt das laufende stehen. Apps mit lokalem Volume starten stattdessen neu, weil die Disk zu einer Instanz gehört.
• Datenbanken neben der App Managed PostgreSQL, pgvector, MySQL, Valkey und ClickHouse in derselben Region. Angehängte Datenbanken kommen als DATABASE_URL, REDIS_URL oder CLICKHOUSE_URL in die App.
• Previews pro Pull Request Schalte Previews ein, und Pull Requests aus deinem Repository bekommen eine eigene App mit eigener URL und frischen, leeren Datenbanken, automatisch oder per Hand angelegt. Forks und Bot-Pull-Requests werden übersprungen.
• Worker, Cron Jobs und Skalierung Worker laufen als weitere Prozesse derselben App, Jobs planst du auf dem Tab Cron, und jeden Prozess skalierst du auf bis zu 16 Instanzen.
• Release-Schritt Mit Buildpacks läuft eine release:-Zeile in der Procfile bei jedem neuen Build. Dockerfile-Apps sowie Redeploys und Rollbacks auf ein früheres Image nutzen einen Release Command, der an der App selbst gesetzt ist; er hat auch Vorrang vor der Procfile-Zeile. Bei statischen Sites läuft ein Release-Schritt in einem Image, das nur die gebauten Dateien enthält.
• Logs und Metriken Build-, Release- und Laufzeit-Logs sowie CPU-, Speicher-, Disk- und Netzwerk-Metriken für jede Instanz im Dashboard.
• Domains und HTTPS Ein Default-Hostname mit HTTPS ab dem ersten Deploy; deine eigenen Domains bekommen automatisch Zertifikate.

Weiterlesen

• Dockerfile vs Buildpacks: was solltest du nutzen? Beide machen aus deinem Code ein Container-Image. Der Unterschied ist, wer die Build-Schritte schreibt, und das entscheidet über Kontrolle, Wartung und Security-Updates.
• Heroku-Alternativen mit EU-Hosting: 5 Optionen im Vergleich Eine deutsche Plattform und US-Clouds mit EU-Regionen, verglichen nach Sitz, Regionen und Managed Databases.

.NET and ASP.NET Core auf Nodion: Fragen und Antworten