DevOps
Un seul hote. La production et le coureur de taches d'integration tournent sur la meme machine, ce qui a dicte plusieurs choix de conception.
Integration continue
Cinq travaux a chaque demande de fusion :
| Travail | Ce qu'il verifie |
|---|---|
secret-scan |
recherche de secrets sur tout l'historique, pas seulement l'etat final |
php-lint |
syntaxe PHP |
static-tests |
PHPStan niveau 6 + PHPUnit contre une vraie MariaDB ephemere |
js-tests |
tests du front de la borne |
shell-tests |
tests des programmes de sauvegarde et de remise a zero |
Deux details qui se defendent a l'oral :
- Le drapeau
--fail-on-skipped: un test saute, la chaine rougit. Un vert qui ment coute plus cher qu'un rouge. - Les tests de bout en bout ne tournent pas en integration. Le coureur de taches dispose du socket Docker mais ne le transmet pas aux travaux, et c'est voulu : le lui donner reviendrait a donner les pleins pouvoirs sur l'hote a tout code qui passe en integration. Les tests de bout en bout se lancent a la main.
Deploiement continu
Le declencheur est un depot sur main. Le travail quotidien allant dans dev,
le deploiement se provoque en fusionnant une release dev -> main.
La chaine :
- verification que le secret contient bien la cle autorisee sur l'hote, dans un travail separe pour que le nom du travail rouge porte le diagnostic ;
- connexion SSH sans commande : c'est une commande forcee cote hote qui decide quoi lancer. Le travail d'integration ne pilote pas Docker ;
- cote hote, scripts/deploy.sh exige un arbre propre, avance en avance rapide seulement, ecrit un marqueur de version, puis reconstruit et remplace les conteneurs ;
- le travail verifie ensuite que
/api/healthsert bien le commit attendu. Tant que la version en ligne ne correspond pas, le deploiement est declare en echec.
La cle d'hote est epinglee : la connexion echoue si la machine en face n'est pas celle attendue. Pas de confiance au premier contact.
docs/architecture/deployment.md — la mise en place cote serveur, a faire une fois.
Taches planifiees
Quatre taches actives dans le conteneur dedie : sauvegarde quotidienne de la base, purge du journal d'audit, purge des compteurs de limitation, expiration des commandes restees en attente de paiement. docker/cron/scripts
Remettre la demonstration a zero
La production est une demonstration publique : un visiteur peut abimer les donnees. Deux programmes couvrent ce risque.
docs/ops/demo-reset.md — le protocole en six etapes, ses garde-fous et ses limites.
scripts/demo-snapshot.sh -f docker-compose.prod.yml # figer un etat de reference
scripts/demo-reset.sh -f docker-compose.prod.yml --dry-run # voir sans rien changer
scripts/demo-reset.sh -f docker-compose.prod.yml # revenir a la reference
La remise a zero verifie l'integrite de la sauvegarde avant la phase destructive, depose une sauvegarde de securite de l'etat courant avant de l'ecraser, et sait revenir en arriere meme si une restauration a ete interrompue en cours de route. Le filet a ete exerce de bout en bout sur une pile jetable, en cassant volontairement une restauration.