Déployez .NET and ASP.NET Core sur Nodion

Déployez .NET and ASP.NET Core étape par étape

1. Un seul projet à la racine, ou DOTNET_PROJECT Nodion publie l'unique .csproj ou .fsproj du répertoire indiqué dans le champ Base directory, en mode dépendant du framework. Avec plusieurs projets, ou une solution dont les projets sont dans des sous-dossiers, définissez DOTNET_PROJECT sur le chemin du projet web dans l'onglet Environment, en cochant Build ; la racine a quand même besoin d'un .sln ou d'un global.json pour que Nodion détecte .NET. Faire pointer le champ Base directory vers le dossier du projet ne fonctionne que si ce projet ne référence aucun projet situé en dehors, car le build ne voit rien au-dessus de ce dossier. Build variable

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

2. Laissez l'adresse à Nodion Nodion lance l'app avec ASPNETCORE_URLS=http://0.0.0.0:$PORT. Supprimez les URL codées en dur comme app.Run("http://localhost:5000") et les endpoints Kestrel dans appsettings.json, qui ont priorité sur cette variable. Une API sans page sur / a besoin d'un endpoint de health check ; définissez son chemin comme chemin du health check dans les paramètres de l'app. 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. Laissez AllowedHosts ouvert pour le health check Le health check appelle chaque instance avec son IP interne comme hôte. La valeur par défaut du template, "AllowedHosts": "*", le laisse passer. Avec une liste de vos domaines, ASP.NET Core répond 400 et la release n'est jamais mise en ligne ; gardez *, ou vérifiez les hôtes dans votre propre middleware en excluant le chemin du health check. appsettings.json

   {
     "AllowedHosts": "*"
   }

4. Créez l'app et rattachez PostgreSQL Créez une application depuis votre dépôt dans la région EU Central, puis une base de données PostgreSQL dans la même région. Npgsql utilise des chaînes de connexion clé-valeur, pas des URL postgres:// comme DATABASE_URL : en rattachant la base de données dans l'onglet Environment, injectez donc host, port, database, user et password sous vos propres noms et construisez la chaîne de connexion à partir de ces variables. 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. Appliquez les migrations EF Core Nodion n'exécute pas les migrations EF Core, et l'image d'exécution ne contient pas de SDK : dotnet ef ne peut donc pas tourner comme étape de release. Appliquez-les au démarrage de l'app avec Database.Migrate(), ce qui convient pour une seule instance, ou passez à un Dockerfile qui construit un bundle de migration EF Core et l'exécute comme commande de release de l'app. Program.cs

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

Bon à savoir

• Version du SDK et du runtimeLa branche .NET vient de global.json, sinon du TargetFramework du projet situé dans le répertoire indiqué dans le champ Base directory, sinon c'est .NET 10 ; l'image d'exécution reçoit le runtime ASP.NET Core de la même branche. Un projet dans un sous-dossier n'est pas lu pour cela : une app net8.0 ou net9.0 sélectionnée avec DOTNET_PROJECT a donc besoin d'un global.json avec cette version. Nodion installe le SDK actuel de cette branche, qui peut appartenir à un feature band plus récent, donc définissez-y "rollForward": "latestFeature".
• Réglages de productionNodion ne définit pas ASPNETCORE_ENVIRONMENT : ASP.NET Core tourne donc en Production et lit appsettings.Production.json en plus de appsettings.json. Gardez les secrets dans des variables d'environnement marquées comme secrètes ; ConnectionStrings__Default correspond à ConnectionStrings:Default.

Ce que Nodion gère pour vous

• Déploiements sans interruption Faites un push sur votre branche : Nodion construit une nouvelle release. Le trafic bascule lorsque les nouvelles instances réussissent leur health check ; si la release échoue, celle en cours reste active. Les apps avec un volume local redémarrent, car le disque appartient à une seule instance.
• Bases de données à côté de l'app PostgreSQL, pgvector, MySQL, Valkey et ClickHouse managés, dans la même région. Les bases de données rattachées arrivent sous forme de DATABASE_URL, REDIS_URL ou CLICKHOUSE_URL.
• Previews par pull request Activez les previews, et les pull requests de votre dépôt obtiennent leur propre app, avec sa propre URL et des bases de données neuves et vides, créées automatiquement ou à la main. Les pull requests issues de forks ou de bots sont ignorées.
• Workers, cron jobs et mise à l'échelle Exécutez les workers comme processus supplémentaires de la même app, planifiez des tâches dans l'onglet Cron et mettez chaque processus à l'échelle jusqu'à 16 instances.
• Étape de release Avec les buildpacks, une ligne release: du Procfile s'exécute à chaque nouveau build. Les apps Dockerfile, ainsi que les redéploiements ou les rollbacks vers une image antérieure, utilisent une commande de release définie sur l'app elle-même, qui prime aussi sur la ligne du Procfile. Sur les sites statiques, l'étape de release s'exécute dans une image qui ne contient que les fichiers générés par le build.
• Logs et métriques Logs de build, de release et d'exécution, ainsi que les métriques CPU, mémoire, disque et réseau de chaque instance, dans le dashboard.
• Domaines et HTTPS Un nom d'hôte par défaut avec HTTPS dès le premier déploiement, et des certificats automatiques pour vos propres domaines.

Pour aller plus loin

• Dockerfile vs buildpacks : lequel choisir ? Les deux transforment votre code en image de conteneur. La différence, c'est qui écrit les étapes du build, et cela détermine le contrôle, la maintenance et les mises à jour de sécurité.
• Alternatives à Heroku avec hébergement dans l'UE : 5 options Une plateforme allemande et des clouds américains avec des régions dans l'UE, comparés par siège, régions et bases de données managées.

.NET and ASP.NET Core sur Nodion : questions et réponses