Déploiement

Tous les services de l'écosystème suivent un même modèle de déploiement. Cette page le décrit.

Aucun détail propre aux hôtes ici

Les détails d'exploitation — adresses des serveurs, noms d'utilisateur, configuration secrète — ne figurent pas sur ce site public. Ils se trouvent dans un runbook fermé, à l'intérieur du dépôt concerné.

Le modèle général

        Internet
            │
            ▼
   ┌─────────────────┐
   │   edge nginx    │  TLS termination · HSTS · rate limit
   │   (conteneur)   │  chaque vhost → un service interne
   └────────┬────────┘
            │  réseau Docker partagé
   ┌────────┴──────────────────────────────┐
   │                                       │
   ▼                ▼                      ▼
 appli A          appli B              site statique
 (Go + Next)     (Go + Next)            (nginx)
   │                │
   └────────┬───────┘
            ▼
   PostgreSQL · Redis  (partagés)

Principes directeurs :

1. Un seul edge, plusieurs vhosts. À l'extérieur, un unique conteneur nginx détient les ports 80/443. Chaque domaine a son bloc server et fait proxy vers un service interne.
2. Les services internes ne sont pas exposés. Les applications n'écoutent que sur le réseau Docker partagé, ou se lient à 127.0.0.1. Elles sont inaccessibles directement depuis l'extérieur.
3. Infrastructure partagée. Une instance de PostgreSQL et une de Redis servent plusieurs applications ; chacune a sa propre base ou son propre schéma.
4. Docker Compose — chaque application a sa propre stack compose, rattachée au réseau partagé.

L'edge nginx

L'edge prend en charge :

Rôle	Détail
Terminaison TLS	Certificats Let's Encrypt, renouvellement automatique
HSTS	max-age=63072000; includeSubDomains
Rate limit	Par zone : auth (strict) · app (souple) · api
Reverse proxy	vhost → service interne
Refus des hôtes inconnus	Default server → coupure de la connexion

La configuration de l'edge est gérée par git

Le répertoire conf.d de l'edge nginx est synchronisé depuis un dépôt déterminé, via git. Toute modification manuelle sur l'hôte sera écrasée par git reset --hard au déploiement suivant.

Ajouter ou modifier un vhost passe donc par un commit dans le dépôt, que la CI se charge de diffuser.

Un second modèle — le service possède son propre vhost

Il existe aussi un modèle où un vhost qui ne concerne qu'un seul service réside dans le dépôt de ce service plutôt que dans un fichier central, et où son déploiement installe lui-même la configuration dans le conf.d de l'edge, sous forme de fichier distinct.

L'avantage : la modification se termine dans un seul dépôt, sans attendre le déploiement d'une autre équipe. La condition : la configuration doit être entièrement autonome — elle ne peut dépendre ni d'une zone de rate-limit ni d'un default server définis dans un autre fichier.

Ce site fonctionne précisément ainsi — voir Cette plateforme documentaire.

Certificats

• Let's Encrypt, via certbot en mode webroot.
• Le challenge ACME est servi sur le port 80, à /.well-known/acme-challenge/.
• Le renouvellement est automatique, hebdomadaire par cron ; en cas de succès, nginx est rechargé.

Pour ajouter un domaine :

1. Faites pointer le DNS vers le serveur.
2. Ajoutez le domaine au bloc ACME du port 80.
3. Obtenez le certificat avec certbot.
4. Ajoutez le vhost HTTPS et désignez-y le certificat.
5. Lancez nginx -t, puis rechargez.

Sites statiques (portails de documentation)

Les sites de documentation sont du HTML statique pré-construit. Le moyen le plus simple de les servir :

• construire site/ avec MkDocs,
• copier le résultat sur le serveur,
• le faire servir par un petit conteneur nginx:alpine,
• faire proxy depuis l'edge nginx vers ce conteneur.

Il n'y a pas de runtime applicatif : peu de ressources consommées, peu de choses susceptibles de casser.

Ce site fonctionne exactement ainsi — voir Cette plateforme documentaire pour le détail.

Déploiement des applications

Deux modèles coexistent pour les applications :

Modèle	Détail
Build sur l'hôte	La CI synchronise le dépôt sur l'hôte et lance docker compose build && up -d
Via un registry	La CI construit l'image et la pousse vers un registry ; l'hôte fait pull && up -d

La tendance va vers moins de dépendances : certains cas sont passés d'un registry externe à un build directement sur l'hôte.

Déploiements partiels : la CI détermine les services à reconstruire à partir des chemins modifiés (paths-filter). Un changement dans une application n'affecte pas les autres.

Rollback

• Site statique — décompresser l'archive de la construction précédente.
• Application — revenir au tag d'image précédent (que l'on peut épingler avec une variable <SVC>_IMAGE_TAG).

Contrôles de santé

Chaque service dispose d'un endpoint /health. Les healthcheck de compose vérifient que l'infrastructure (PostgreSQL, Redis) est prête et ne démarrent l'application qu'ensuite.

Liste de contrôle de déploiement

• [ ] DNS correctement pointé
• [ ] Certificat émis et couvert par le renouvellement automatique
• [ ] Vhost edge ajouté et commité dans le dépôt
• [ ] nginx -t passe
• [ ] Services internes non exposés vers l'extérieur
• [ ] /health répond
• [ ] Secrets par variables d'environnement, absents du dépôt
• [ ] Méthode de rollback clairement définie

Pour le détail de l'automatisation, voir CI/CD.