[infra] Versionner les scripts d'exploitation et les faire poser par Ansible #64

Open
opened 2026-09-02 08:28:40 +00:00 by lenaic · 0 comments
Owner

Exigence couverte

ENF-09, ENF-05

Épreuve servie

EC04 · Cloud et sécurisation

Charge estimée

1 j.h

Ce qu'on veut obtenir

Sortir les scripts d'exploitation des documents Markdown pour en faire des fichiers versionnés, que le playbook Ansible pose sur le serveur. Aujourd'hui deux scripts vivent uniquement sur la machine, et leur contenu est recopié à la main dans une page de documentation : rien ne garantit que les deux copies restent identiques, et rien ne le détecterait.

Critères d'acceptation

  • infra/scripts/pg-backup.sh existe dans le dépôt et remplace le bloc recopié de docs/POSTGRESQL.md, qui n'en garde qu'un renvoi.
  • Le script de sauvegarde de la forge est versionné de la même façon.
  • Les deux tâches planifiées, /etc/cron.d/pg-backup et /etc/cron.d/g2-forge, sont décrites dans le dépôt et posées par le playbook.
  • Le playbook Ansible du #41 déploie les deux scripts et leurs droits, et son rejeu ne casse rien.
  • La liste des bases sauvegardées est lue dans le catalogue plutôt que figée dans une boucle, ce qui supprime la classe d'erreur du 1er septembre.
  • Un contrôle vérifie que le fichier posé sur le serveur est identique à celui du dépôt.

Comment on le vérifie

Commande ansible-playbook en mode vérification, puis diff entre le dépôt et le serveur
Attendu aucun écart, les deux scripts s'exécutent et produisent leurs fichiers
Preuve la sortie du diff et celle d'un passage de chaque script

Manuel d'exploitation à mettre à jour

docs/POSTGRESQL.md et docs/FORGE.md renvoient au fichier au lieu de le recopier

Risque et retour arrière

Un script déployé avec de mauvais droits ou un mauvais propriétaire casse la sauvegarde en silence, ce qui est exactement la panne du 1er septembre. Le contrôle d'identité entre dépôt et serveur est là pour ça. Retour arrière : les scripts actuels restent en place sur le serveur tant que le playbook n'est pas joué.

### Exigence couverte ENF-09, ENF-05 ### Épreuve servie EC04 · Cloud et sécurisation ### Charge estimée 1 j.h ### Ce qu'on veut obtenir Sortir les scripts d'exploitation des documents Markdown pour en faire des fichiers versionnés, que le playbook Ansible pose sur le serveur. Aujourd'hui deux scripts vivent uniquement sur la machine, et leur contenu est recopié à la main dans une page de documentation : rien ne garantit que les deux copies restent identiques, et rien ne le détecterait. ### Critères d'acceptation - [ ] `infra/scripts/pg-backup.sh` existe dans le dépôt et remplace le bloc recopié de `docs/POSTGRESQL.md`, qui n'en garde qu'un renvoi. - [ ] Le script de sauvegarde de la forge est versionné de la même façon. - [ ] Les deux tâches planifiées, `/etc/cron.d/pg-backup` et `/etc/cron.d/g2-forge`, sont décrites dans le dépôt et posées par le playbook. - [ ] Le playbook Ansible du #41 déploie les deux scripts et leurs droits, et son rejeu ne casse rien. - [ ] La liste des bases sauvegardées est lue dans le catalogue plutôt que figée dans une boucle, ce qui supprime la classe d'erreur du 1er septembre. - [ ] Un contrôle vérifie que le fichier posé sur le serveur est identique à celui du dépôt. ### Comment on le vérifie Commande ansible-playbook en mode vérification, puis diff entre le dépôt et le serveur Attendu aucun écart, les deux scripts s'exécutent et produisent leurs fichiers Preuve la sortie du diff et celle d'un passage de chaque script ### Manuel d'exploitation à mettre à jour `docs/POSTGRESQL.md` et `docs/FORGE.md` renvoient au fichier au lieu de le recopier ### Risque et retour arrière Un script déployé avec de mauvais droits ou un mauvais propriétaire casse la sauvegarde en silence, ce qui est exactement la panne du 1er septembre. Le contrôle d'identité entre dépôt et serveur est là pour ça. Retour arrière : les scripts actuels restent en place sur le serveur tant que le playbook n'est pas joué.
florian added this to the EnerVision project 2026-09-02 14:52:04 +00:00
gabriel added the due date 2026-09-11 2026-09-03 12:41:06 +00:00
gabriel added this to the Post-jury milestone 2026-09-03 15:06:02 +00:00
Sign in to join this conversation.
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".
2026-09-11
Reference
g2/enervision#64
No description provided.