5.4Checklist production et certifications
L'essentiel en 30 secondes
- Huit oui ou pas de prod : tags immuables, images scannées et non-root, redémarrage + healthchecks, volumes sauvegardés et restauration testée, secrets hors git, un seul port publié, logs avec rotation, CI seule usine.
- On n'opère que ce qu'on voit : métriques en direct, alertes avant clients, espace disque sous surveillance — un disque plein arrête tout.
- Après ce guide : certification Docker générique d'abord (elle couronne ce guide), certification Kubernetes ensuite si cap Kubernetes — par labs pratiques, avec validation senior/DSI avant toute prod réelle.
Mini-cas filé — Idir audite avant la prod
Dernier épisode : Idir, devops junior à Alger, doit mettre en production le stack de sa structure. Au lieu de déployer vite, il imprime la checklist et audite : un tag mouvant en prod, un secret dans le dépôt, aucune sauvegarde testée, aucun monitoring disque. Il corrige un point après l'autre, teste la restauration, sort les secrets du dépôt, active la rotation des logs — puis fait valider l'ensemble par son référent senior avant d'ouvrir la prod. Dernier épisode des cas 5.1-5.3 — Idir boucle orchestration et production par l'audit.
Dernier épisode des cas 5.1-5.3 — Idir corrige puis fait valider avant la prod.
1. La checklist avant prod
Tags immuables (jamais de tag mouvant en prod), images scannées et non-root, redémarrage + healthchecks sur chaque service durable, volumes sauvegardés avec restauration testée, secrets hors git (fichier d'exemple versionné, vraies valeurs ailleurs), un seul port publié (le proxy), logs avec rotation, Compose versionné, CI seule usine des images. Idir coche chaque case : un seul « non » = pas de prod.
La checklist est une porte, pas un décor : on corrige chaque « non » un par un, avec test, avant d'ouvrir. Idir imprime la sienne et la fait cocher à deux.
2. Superviser le minimum vital
Métriques des conteneurs en direct, sondes d'alerte (disponibilité, disque), espace disque sous surveillance : images accumulées, logs sans rotation et volumes orphelins remplissent les disques — un disque plein arrête tout. On n'opère bien que ce qu'on voit : alertes avant clients.
Sauvegardes et scans automatisés (pas manuels), restauration testée (une sauvegarde non testée n'est pas une sauvegarde), rotation des logs réglée dès le Compose. Idir programme l'alerte disque avant la première prod.
3. Et après ? Certifications et validation
De façon générique : une certification Docker valide ce guide (images, réseaux, volumes, Compose, Swarm, sécurité), une certification Kubernetes certifie l'étape suivante. Les deux se préparent par labs : rejouez chaque niveau en aveugle, jamais par bachotage.
Et surtout : junior ne met pas seul en production — Idir fait valider son audit par son référent senior / la DSI avant d'ouvrir la prod, avec sauvegardes, secrets et monitoring vérifiés. La pratique encadrée bat le par-cœur solitaire.
🔎 Exemple concret — L'audit express du stack d'Idir
Huit cases, zéro excuse.
[ ] tags immuables, pas de mouvant en prod
[ ] non-root + scan sans critique
[ ] restart + healthcheck sur chaque durable
[ ] volumes : sauvegarde + restauration testee
[ ] secrets hors git, exemple versionne
[ ] seul le proxy publie les ports
[ ] logs avec rotation, disque alerte
[ ] CI seule usine, compose versionneLecture : Idir coche chaque case avec preuve (test, log, restauration).
Leçon : imprimez-la : c'est votre porte de sortie vers la prod.
Vocabulaire de la section
- Checklist prod
- Les huit oui exigés avant toute mise en production.
Exemple simple : Idir refuse la prod tant qu'une case est à non.
Ce que ce n'est pas : un déploiement « on verra bien » sans audit.
Réflexe : ai-je huit oui prouvés avant d'ouvrir ?
- Rotation des logs
- La limite de taille et de croissance des journaux de conteneurs.
Exemple simple : Idir règle taille max et fichiers max dans son Compose.
Ce que ce n'est pas : des journaux qui grossissent jusqu'au disque plein.
Réflexe : mes logs sont-ils bornés et surveillés ?
- Supervision
- Voir et alerter : métriques, sondes de dispo, espace disque.
Exemple simple : Idir est alerté avant les clients quand le disque se remplit.
Ce que ce n'est pas : découvrir la panne par les appels clients.
Réflexe : suis-je alerté avant mes utilisateurs ?
- Sauvegarde testée
- Une sauvegarde dont la restauration a été rejouée avec succès.
Exemple simple : Idir restaure ses volumes sur un bac à sable avant la prod.
Ce que ce n'est pas : une archive jamais rejouée.
Réflexe : ai-je rejoué ma restauration ce mois-ci ?
- Validation senior
- La relecture de l'audit par un référent avant ouverture de la prod.
Exemple simple : Idir fait valider checklist, secrets et monitoring par son senior.
Ce que ce n'est pas : une mise en prod solitaire de junior.
Réflexe : qui a relu et validé mon audit ?
En pratique — Auditer votre stack
- Imprimez la checklist et auditez votre stack actuel.
- Corrigez chaque « non » un par un, avec test.
- Testez sauvegarde + restauration, sortez les secrets du dépôt.
- Faites valider par votre référent senior / DSI, puis planifiez la certification par labs.
Script prêt à dire — demander la validation avant prod
« Avant d'ouvrir la prod à Alger, voici mon audit : tags figés, images scannées non-root, healthchecks, sauvegardes avec restauration testée, secrets hors dépôt, logs avec rotation et monitoring disque. Il me reste deux cases à corriger — je vous propose de les revoir ensemble et de valider l'ouverture une fois les huit oui obtenus. »
À dire au référent senior / DSI pour faire valider l'audit avant toute mise en production.
Modèle copier-coller — fiche audit prod
FICHE AUDIT PROD — stack : ___ · date : ___
[ ] tags immuables (mouvant interdit) · [ ] scan OK + non-root
[ ] restart + healthcheck par durable · [ ] seul proxy publie
[ ] sauvegarde OK + restauration testee le : ___
[ ] secrets hors git (exemple versionne) · [ ] logs rotation + disque alerte
[ ] CI seule usine · compose versionne
VALIDE PAR (senior/DSI) : ___ · date : ___ · GO PROD ? OUI / NONSolo / petit budget
Idir seul : la checklist imprimée + une restauration testée valent mieux qu'aucun audit.
TPE / équipe réduite
Audit à deux : l'un coche, l'autre vérifie les preuves avant validation.
PME à Alger
Idir cale à Alger une revue prod : audit projeté, chaque non planifié avant ouverture.
Équipe qui démarre
Binôme : l'un corrige les non, l'autre rejoue restauration et alertes.
✓ Bonnes pratiques
- Imprimez la checklist, cochez à deux avec preuves.
- Automatisez sauvegardes + scans, testez la restauration.
- Préparez les certifications par labs répétés, pas par cœur.
✗ Pièges fréquents
- « On verra en prod » avec des cases à non.
- Superviser après la panne au lieu d'alerter avant.
- Préparer les certifications par bachotage.
Points clés à retenir
- Huit oui = prod, un non = on corrige et on re-teste.
- On voit (supervision, alertes, disque) avant d'opérer.
- Sauvegarde testée + secrets hors git + CI seule usine.
- Certifications par labs, prod validée par le senior/DSI.
Défi 48h — appliquez demain
Remplissez la fiche audit prod (modèle ci-dessus) pour votre stack réel : chaque non devient une correction planifiée, puis faites-la relire avant toute prod.
- Je peux citer les huit cases de la checklist.
- Mon stack est audité, corrigé et validé.
- Je sais préparer la certification par labs, pas par cœur.
Questions fréquentes
Quelle rotation pour les logs ?
Par défaut les journaux grossissent sans fin : limitez taille et nombre de fichiers (options de rotation dans le Compose / la config de journalisation) et centralisez tôt. Un disque plein arrête tout — combinez rotation, nettoyage des images et volumes orphelins, et alertes disque.
Par quelle certification commencer ?
De façon générique : d'abord celle qui couronne exactement ce guide (Docker : images, réseaux, volumes, Compose, Swarm, sécurité), ensuite celle de Kubernetes seulement si Kubernetes est votre cible. Les deux exigent des labs pratiques réguliers — rejouez chaque niveau en aveugle — et une validation encadrée avant toute production réelle.
Un point de la checklist est à « non ». Que faire ?