Binaires, sans Docker

Cette voie publie le backend et le frontend sous forme de fichiers ordinaires et les exécute avec le gestionnaire de services que vous utilisez déjà. Elle offre le plus de contrôle et le moins d'automatisation.

La voie la moins balisée des trois

Le dépôt ne fournit aucun installeur pour cette configuration : c'est l'image conteneur que le projet construit, teste et déploie. Tout ce qui suit est dérivé de ce que fait réellement cette image, mais vous assemblez les pièces vous-même. Si vous voulez simplement une instance qui fonctionne, Docker comporte moins de pièces mobiles.

Prérequis

  • SDK .NET 10.0 sur la machine qui compile, et le runtime ASP.NET Core 10.0 sur celle qui exécute le backend. global.json déclare le SDK 10.0.100 comme plancher, avec rollForward: latestFeature : tout SDK 10.0 à partir de 10.0.100 construit le dépôt, et la bande de fonctionnalités installée la plus haute est utilisée.
  • PostgreSQL, avec une base vide et un compte propriétaire.
  • Un reverse proxy portant votre certificat TLS, et deux noms d'hôte.
  • Les quatre secrets des prérequis communs.

Publier les deux applications

Depuis un clone du dépôt. Le backend est une application ASP.NET Core classique ; le frontend est du Blazor WebAssembly, donc sa sortie est un dossier de fichiers statiques, pas un processus.

dotnet publish src/Aetheus.Back/Aetheus.Back.csproj \
    -c Release -o /opt/aetheus/back

dotnet publish src/Aetheus.Front/Aetheus.Front.csproj \
    -c Release -o /opt/aetheus/front-publish \
    -p:StaticWebAssetsPublishFingerprint=false

Les fichiers à servir sont dans /opt/aetheus/front-publish/wwwroot, pas dans le dossier de publication lui-même. C'est ce répertoire wwwroot que votre serveur web ou votre reverse proxy exposera sur l'hôte applicatif.

Indiquer votre API au frontend

Le frontend est téléchargé et exécuté par le navigateur du visiteur : il ne peut donc pas lire de variable d'environnement côté serveur. Son adresse d'API est inscrite dans un fichier JSON qu'il récupère au démarrage, wwwroot/appsettings.json. Éditez-le après la publication, en remplaçant l'URL de base par la vôtre :

{
  "ApiBaseUrl": "https://api.example.com"
}

À refaire après chaque mise à jour

Une publication écrase wwwroot/appsettings.json. Scriptez donc cette édition dans votre déploiement, ou conservez une copie à restaurer. L'image conteneur automatise exactement cette étape, à partir de la variable d'environnement API_BASE_URL.

Configurer le backend

Le backend lit la configuration .NET standard : chaque réglage peut donc être fourni en variable d'environnement selon la convention du double tiret bas. Le minimum :

ASPNETCORE_ENVIRONMENT=Production
ASPNETCORE_URLS=http://127.0.0.1:5080

ConnectionStrings__Default=Host=127.0.0.1;Port=5432;Database=aetheus;Username=aetheus;Password=A_CHANGER

Auth__JwtKey=A_CHANGER
Auth__EncryptionKey=A_CHANGER
Auth__EncryptionSalt=A_CHANGER
Auth__AdminPassword=A_CHANGER

# URL publique de cette API, telle que le navigateur et les agents l'atteindront.
Aetheus__PublicApiBaseUrl=https://api.example.com
# L'hôte applicatif, autorisé en origine CORS. Sans lui, le frontend se charge et chaque appel échoue.
Cors__Origins__0=https://app.example.com

# État persistant. Sauvegardez ces quatre répertoires.
DataProtection__KeyPath=/var/lib/aetheus/dp-keys
GitLight__RepositoriesPath=/var/lib/aetheus/git-repos
ArtifactStorage__BasePath=/var/lib/aetheus/artifacts
PackageRegistry__BasePath=/var/lib/aetheus/packages

Liez à 127.0.0.1, pas à 0.0.0.0 : le reverse proxy doit être le seul à joindre le backend, et écouter sur toutes les interfaces exposerait l'API en clair.

Exécution sous Linux avec systemd

Créez /etc/aetheus/back.env avec les réglages ci-dessus, un CLE=valeur par ligne, puis /etc/systemd/system/aetheus-back.service :

[Unit]
Description=Aetheus backend
After=network-online.target postgresql.service
Wants=network-online.target

[Service]
Type=simple
User=aetheus
Group=aetheus
WorkingDirectory=/opt/aetheus/back
EnvironmentFile=/etc/aetheus/back.env
ExecStart=/usr/bin/dotnet /opt/aetheus/back/Aetheus.Back.dll
Restart=on-failure
RestartSec=5

StateDirectory=aetheus
ProtectSystem=full
ProtectHome=true
NoNewPrivileges=true

[Install]
WantedBy=multi-user.target
sudo systemctl daemon-reload
sudo systemctl enable --now aetheus-back
curl -sf http://127.0.0.1:5080/health/ready

Le backend applique ses migrations de base au démarrage : le premier démarrage réussi est donc aussi ce qui crée le schéma. /health/ready répondant 200 signifie que le processus est démarré et que la base est joignable.

Sous Windows

Pas de service Windows nu

Le backend ne s'intègre pas à l'hôte de services Windows : un service enregistré avec sc.exe ne démarre pas. Sur une machine Windows, hébergez le backend en application IIS avec le module ASP.NET Core : voir la page IIS, qui porte un badge « non testé ».

Servir les fichiers du frontend

Le frontend est statique : n'importe quel serveur web peut servir wwwroot. Deux règles comptent, et elles figurent dans les pages Apache, IIS et nginx :

  • les chemins inconnus doivent retomber sur index.html, car le routage se fait dans le navigateur ;
  • index.html et tout ce qui est sous _framework/ ne doivent pas être mis en cache, sinon un navigateur continuera d'amorcer la version précédente après une mise à jour.

Installer les agents

Les agents s'installent depuis l'application, pas depuis ce clone. Dans l'interface web, ouvrez un projet, ajoutez un serveur, et suivez l'assistant : il produit l'archive de l'agent et un jeton d'enregistrement à usage unique.

Sur la machine cible, extrayez l'archive et lancez l'installeur qu'elle contient :

# Linux
sudo sh /opt/aetheus-agent/install-agent-linux.sh

L'agent Windows n'est pas pris en charge pour l'instant : son installeur figure dans l'archive mais n'aboutit pas. Les agents tournent sous Linux.

L'installeur demande l'URL de l'API, le jeton d'enregistrement et un nom d'affichage, écrit la configuration, enregistre le service et vérifie sa santé. L'agent n'émet que des appels HTTPS sortants : aucune règle de pare-feu entrante n'est nécessaire.

Mise à jour

  1. Arrêtez le service backend.

  2. Publiez la nouvelle version par-dessus /opt/aetheus/back, et le nouveau frontend par-dessus son wwwroot.

  3. Restaurez wwwroot/appsettings.json avec votre ApiBaseUrl.

  4. Démarrez le backend. Les migrations s'appliquent au démarrage : surveillez le journal jusqu'à ce que /health/ready réponde 200.

Sauvegardez la base et les quatre répertoires d'état avant chaque mise à jour. Une migration de schéma ne s'annule pas en redémarrant l'ancien binaire.