Déploiement et mises à jour

Principe#

Le déploiement part toujours du poste de l'équipe technique, qui détient le dépôt Git. Le script deploy/deployer.sh :

1. signale les fichiers suivis modifiés mais non commités (ils ne seront pas déployés) ;
2. envoie au serveur, par SSH, l'archive du commit courant (git archive HEAD) : jamais un fichier non commité, jamais deploy/.env ;
3. sur le serveur, décompresse le code dans /opt/read/code.nouveau, y lie /opt/read/.env et écrit le commit dans VERSION ;
4. remplace /opt/read/code par la nouvelle version et garde la précédente dans /opt/read/code.ancien ;
5. lance docker compose up -d --build en arrière-plan, avec le compte rendu dans /opt/read/deploiement.log.

Le serveur n'a besoin d'aucun accès au dépôt Git.

Déployer une nouvelle version#

1. Sur le poste, placez-vous sur le commit à déployer (branche main à jour, tests réussis).

2. Lancez :

   Copier

   deploy/deployer.sh <alias-ssh>

   Sous Windows : SSH=/c/Windows/System32/OpenSSH/ssh.exe deploy/deployer.sh <alias-ssh>.

3. Suivez la construction sur le serveur :

   Copier

   tail -f /opt/read/deploiement.log

   Les constructions suivantes réutilisent les paquets NuGet déjà téléchargés (cache de construction) : quelques minutes suffisent.

4. Vérifiez la version et l'état :

   Copier

   cat /opt/read/code/VERSION
   cd /opt/read/code && docker compose ps -a

   Attendu : app « healthy », migrations « Exited (0) », db et caddy « Up ».

5. Ouvrez le site, connectez-vous, parcourez quelques pages.

Pendant la construction, l'ancienne version reste en service ; seul le remplacement des conteneurs provoque une coupure de quelques secondes.

Migrations du schéma#

À chaque docker compose up, le service migrations démarre avant l'application :

• il applique les migrations du schéma manquantes, avec le compte propriétaire (POSTGRES_USER) ;
• il crée ou met à jour le rôle de l'application (POSTGRES_APP_USER) : droits de lecture et d'écriture sur toutes les tables (y compris les nouvelles), mais ni modification ni effacement du journal d'audit, ni écriture dans l'historique des migrations ;
• il s'arrête. L'application ne démarre que s'il s'est terminé sans erreur.

L'application ne migre jamais elle-même en production (Base__Migrer=false).

Revenir à la version précédente#

Si la nouvelle version pose problème, sur le serveur :

cd /opt/read && rm -rf code && mv code.ancien code && cd code && docker compose up -d --build

Un seul niveau de retour arrière est conservé sur le serveur. Pour revenir plus loin, déployez l'ancien commit depuis le poste (git checkout <commit> puis deploy/deployer.sh).

Versions figées#

Pour qu'une construction soit reproductible, toutes les images et outils ont une version exacte :

Mise à jour mensuelle#

Chaque mois, pour recevoir les correctifs de sécurité :

1. Relevez la dernière version de la même branche de chaque image : Docker Hub pour postgres:16.x-alpine, caddy:2.x-alpine, alpine et rclone/rclone ; la liste https://mcr.microsoft.com/v2/dotnet/aspnet/tags/list (et …/dotnet/sdk/…) pour .NET 10.
2. Mettez à jour les fichiers du tableau ci-dessus.
3. Lancez la suite de tests (dotnet test, Docker requis), commitez.
4. Faites une sauvegarde, puis déployez.
5. Vérifiez le site, puis lancez une restauration d'essai.

Le système du serveur se met à jour seul (unattended-upgrades). Docker, lui, se met à jour par apt : sudo apt update && sudo apt upgrade lors d'une fenêtre de maintenance, suivi d'une vérification des conteneurs.