-
Des backups de base qui restaurent vraiment : le pgdata que j'ai perdu
J'ai supprimé un répertoire de données Postgres qui vivait dans un bind mount, sans rien derrière. Mon plan de backup, c'était l'espoir. Voici le setup de backup pas cher sur un seul VPS que j'aurais dû avoir, y compris l'étape que tout le monde saute.
-
Docker n'a jamais redémarré ma base : le prix de restart: no
Un conteneur est mort la nuit et rien ne l'a relancé, parce que chaque service était en restart: no. Les healthchecks que j'avais ne pouvaient pas aider, et la raison surprend la plupart des gens.
-
Les tests étaient déjà écrits. Rien ne les a jamais lancés.
Une régression est arrivée en production, et le test qui l'aurait attrapée était déjà dans le repo. Il n'y avait aucun script de test, et le seul workflow CI ne se déclenchait jamais sur un push. Comment j'ai câblé tout ça.
-
Docker a contourné mon pare-feu : le port de la base était ouvert sur internet
Mon pare-feu bloquait le port 5432. Il était joignable depuis internet quand même, parce que Docker écrit ses propres règles iptables que vos règles INPUT et ufw ne voient jamais. Pourquoi, et comment vraiment le fermer.
-
Le docker build qui a rempli le disque et fait tomber la production
La production est tombée sans changement de code. La cause : un docker compose build qui orphelinait une nouvelle image <none> à chaque déploiement jusqu'à remplir le disque. Ce qui l'a vraiment vidé, et le vrai correctif.
-
Faire tourner un SaaS sur un seul VPS avec Docker Compose : l'audit honnête
Tout le produit tourne sur un seul VPS derrière un docker-compose.yml. Voici pourquoi c'était le bon choix au lancement, et la carte honnête de chaque point de défaillance unique qu'il cache.