Mettre en production

Précédemment. Le Dockerfile produit deux images : un migrateur, qui applique les migrations, et le service, qui ne contient que ce qui s’exécute, sans un seul secret.

Le site tourne sur un serveur loué, dans des conteneurs Docker, derrière un serveur web (Caddy) qui reçoit les visiteurs, s’occupe du HTTPS et leur transmet les requêtes. La base Postgres tourne sur le même serveur, dans son propre conteneur. Les fichiers, eux, sont chez Cloudflare R2 (partie « Stockage et médias »).

Ce qui vit sur le serveur, et pas dans le dépôt#

Le dépôt contient le code et la recette de l’image. Il ne contient pas ce qui est propre au serveur :

Le service du site, dans ce compose, se construit à partir du clone (build: context), reçoit ses arguments de build, et lit son fichier d’environnement au démarrage (env_file:). L’hôte de la base, dans ce fichier, est le nom du service Postgres dans le compose, pas localhost : dans un conteneur, localhost désigne le conteneur lui-même (partie « Configuration »).

L’ordre d’un déploiement 🚀#

Pourquoi la migration avant le conteneur#

L’inverse — le nouveau code d’abord — fait démarrer un site qui lit des colonnes qui n’existent pas encore. Le démarrage lui-même interroge la base (la section suivante) : chaque vérification échoue, et chaque page qui touche la nouvelle colonne répond une erreur, jusqu’à la migration.

L’ordre retenu demande en échange que l’ancien code supporte le nouveau schéma, le temps de reconstruire l’image. C’est le cas d’une migration qui ajoute (une table, une colonne facultative ou avec une valeur par défaut) : l’ancien code ne la voit pas. Une migration qui retire ou renomme se fait en deux déploiements : d’abord le code qui ne lit plus l’ancienne colonne, ensuite la migration qui la supprime.

Lancer la migration#

Le dépôt fournit l’image migrator (chapitre 1), dont la seule commande est prisma migrate deploy. Le compose du serveur la lance comme un service à part, akfc-migrator, et le site en dépend :

  akfc:    # …    depends_on:      postgres:        condition: service_started      pgbouncer:        condition: service_started      akfc-migrator:        condition: service_completed_successfully  akfc-migrator:    build:      context: ./backends/akfc      target: migrator    container_name: akfc-migrator    restart: "no"    env_file: ./backends/akfc/.env    networks:      - web      - internal

À chaque docker compose up du site, Compose construit l’image du migrateur, la lance dans le réseau interne — où le nom du service Postgres se résout —, attend qu’elle se termine sans erreur (service_completed_successfully), et seulement alors démarre le nouveau conteneur du site. Sans migration nouvelle, le migrateur le dit et s’arrête :

21 migrations found in prisma/migrationsNo pending migrations to apply.

Une migration qui échoue arrête la chaîne : le nouveau conteneur ne démarre pas, et le site continue de tourner sur l’ancien. La base, elle, a pu recevoir une partie de la migration — Prisma ne l’enveloppe pas dans une transaction. L’échec est noté dans _prisma_migrations, et les déploiements suivants s’arrêtent au même endroit tant qu’il n’a pas été examiné, la base remise d’aplomb, et l’échec résolu (prisma migrate resolve). C’est une raison de plus de tester chaque migration sur la base locale, puis dans les tests de bout en bout, qui rejouent toutes les migrations depuis zéro (partie « Qualité »). restart: "no" empêche Docker de relancer le migrateur en boucle : il tourne une fois par déploiement.

La sandbox enchaîne déjà ses services ainsi (chapitre 3). Sur le serveur, la migration a longtemps été une étape à la main du déploiement, et l’oublier mettait en ligne un code qui attendait une base plus récente que la vraie (partie « Données ») ; elle fait désormais partie du up.

En secours, une migration peut aussi partir du clone, avec la CLI Prisma de ses dépendances. Le fichier d’environnement désigne alors un hôte (le nom du service Postgres) que le serveur lui-même, hors des conteneurs, ne connaît pas : l’adresse de la base se donne le temps de la commande, pointée sur le conteneur Postgres. dotenv ne remplace pas une variable déjà présente : celle donnée sur la ligne de commande l’emporte sur le fichier.

migrate deploy applique les migrations qui manquent, dans l’ordre, et les enregistre dans la table _prisma_migrations : relancé, il ne refait rien. Il n’en crée jamais, et ne réinitialise jamais rien — contrairement à migrate dev et migrate reset, qui n’ont rien à faire en production.

Ce que le site fait en démarrant#

Au démarrage du serveur Node, Next appelle register() dans instrumentation.ts, une fois. Le site y vérifie et répare ce dont il a besoin pour fonctionner, puis lance ses tâches de fond :

// ⚠ Fichier introuvable : apps/web/src/instrumentation.ts// Il a été déplacé ou supprimé depuis la rédaction de ce chapitre.

Lire les journaux#

Après un déploiement, les journaux du conteneur disent ce qui s’est passé :

Une erreur de connexion à la base au démarrage (P1001, « can’t reach database server ») se lit d’abord dans l’adresse : un hôte localhost dans le fichier d’environnement du conteneur, un nom de service mal orthographié, un rôle qui n’existe pas. Chaque erreur corrigée en révèle parfois une autre plus loin : c’est un progrès, pas un échec.

Faire de la place#

Chaque construction laisse des images et un cache de construction. Sur un serveur au disque modeste, ils finissent par le remplir, et la construction suivante échoue. Le dépôt fournit un nettoyage sûr :

// ⚠ Fichier introuvable : docker-cleanup.sh// Il a été déplacé ou supprimé depuis la rédaction de ce chapitre.

Il supprime le cache de construction et les images qu’aucun conteneur n’utilise, et jamais les volumes : c’est dans les volumes (et les dossiers montés) que vivent les données, la base en premier. docker system prune --volumes, au contraire, efface tout volume qu’aucun conteneur n’utilise — celui d’une base dont le conteneur vient d’être supprimé par un docker compose down, par exemple.

Revenir en arrière#

Un déploiement qui casse se défait en reconstruisant l’image du commit précédent : git checkout <commit> dans le clone, puis docker compose up -d --build pour le service du site. La base, elle, reste au nouveau schéma — une migration ne se défait pas. C’est là que les migrations qui ajoutent paient : l’ancien code fonctionne sur la base migrée, et le retour arrière est immédiat. Une fois la cause trouvée et corrigée, le clone revient sur la branche (git checkout main), et le déploiement suivant repart de l’étape 1.

Récapitulatif#

À suivre#

La production est faite pour les membres. Pour essayer le site sans rien risquer — le montrer, tester une idée, tout casser —, il en faut une copie complète, qui tourne seule.