Déploiement & opérations

Faire tourner Chinaski en production : les services systemd, le reverse proxy devant le site public, les scripts de déploiement, et les pages opérationnelles (logs, performance, air-gap, promotions) qui le maintiennent en bonne santé. La section suppose que l’installation de la mise en route est faite ; elle couvre ce que vous faites réellement tourner.

Dans cette section

• Services systemd : les unités d’instance avec template (chinaski@<N>, backup, MCP), ce qu’elles font, leur durcissement, et comment les activer/redémarrer.
• Proxy inverse : les deux cibles de proxy (sortie statique + le démon du CMS), les routes qui doivent être transmises (/forms/, /documents/), les en-têtes de proxy qui comptent, et la règle de confiance d’une vraie IP client.
• Le serveur Hypnotoad : le modèle de serveur (master + workers), le comportement de rechargement sans interruption, la config EOTW/offline fournie, et la différence démon-vs-hypnotoad.
• Configuration : conventions du fichier env, la LISTEN_URL/LISTEN, la gestion du secret, et l’organisation des réglages par instance.
• Hébergement statique : servir la sortie construite avec nginx ou Caddy ; les formats _redirects et les routes qu’un site quasi statique doit quand même transmettre.
• Déploiement SSH / rsync : pousser la sortie construite vers un hôte distant après chaque build réussi.
• Publier depuis un téléphone : faire tourner l’admin sur un téléphone Android avec Termux et publier vers Cloudflare R2 comme hôte public.
• Publier depuis un ordinateur portable : faire tourner l'administration sur un ordinateur portable Linux et publier vers Cloudflare R2 comme hébergeur public.
• Publiez votre site avec Cloudflare R2 : guide pas à pas pour publier votre site sur Cloudflare R2 : bucket, clés d'accès, domaine personnalisé, règle de réécriture et réglages de déploiement de Chinaski.
• Webhooks de build & publication : déclencher des webhooks sur les événements de build/publication pour notifier des systèmes externes.
• Mode air-gap : installer et faire tourner entièrement hors ligne ; ce que l’interrupteur désactive ; bundles hors ligne et mises à jour hors ligne.
• Logs & monitoring : journalisation journald, les endpoints de santé, les logs de build, et la vue des métriques.
• Performance : parallélisme de build, en-têtes de cache, index de base de données, et l’histoire du benchmark.
• Promotion Guard : comment un build refuse de dégrader le site en ligne (pages en moins, liens cassés, régressions d’accessibilité) et les chemins de forçage/contournement.

Comment les pièces s’emboîtent

L’agencement de production standard est petit :

1. Une unité systemd fait tourner le démon du CMS écoutant sur la loopback (LISTEN_URL=http://127.0.0.1:<port>).
2. Un reverse proxy (Caddy ou nginx) sert le site public depuis l’arborescence de sortie statique, en transmettant seulement les routes de type formulaires/documents/admin au démon du CMS.
3. Les builds régénèrent l’arborescence statique, déclenchés depuis le dashboard, un webhook ou le script de deploy, et le script de deploy (ou une cible rsync/S3) déplace la sortie vers l’emplacement de service.
4. Le monitoring tourne contre les endpoints de santé, et le mode air-gap (activé par défaut dans les installations fraîches) garde tout le stack hors du commerce des appels sortants sauf ouverture explicite.

La boucle se ferme avec les backups (leur propre section) et des deploys qui échouent en sécurité : un build échoué ne redémarre jamais le service au-dessus d’une sortie qui n’a jamais été promue. Ainsi, toute l’histoire opérationnelle tient en deux minutes de lecture : ce qui tourne, ce qui est servi, ce qui reconstruit, comment garder les deux à jour, et où regarder quand ils ne le sont pas.