DevOps et infrastructure

Problèmes métier

• Un déploiement qui ne marche que parce qu'il vit dans la tête d'un développeur et la configuration d'un ordinateur.
• Des sauvegardes jamais restaurées, si bien que personne ne sait vraiment si elles marchent avant le jour où on en a besoin.
• Aucun monitoring, si bien que l'équipe apprend une panne par un client plutôt que par une alerte.
• Des secrets et clés API commités dans le dépôt ou envoyés sur un chat, au lieu d'être gérés via des variables d'environnement ou un gestionnaire de secrets.
• Un seul VPS faisant tourner la base, l'app et le reverse proxy sans séparation, si bien qu'un mauvais déploiement peut faire tomber toute la pile d'un coup.
• Aucun environnement de staging assez proche de la production pour attraper une différence de configuration avant qu'elle n'atteigne les clients.
• Une configuration serveur manuelle et non documentée, si bien que remplacer un VPS en panne veut dire reconstruire la config de mémoire plutôt que d'exécuter un script.
• Des logs éparpillés entre conteneurs sans endroit central pour les chercher, si bien que déboguer un problème veut dire se connecter en SSH à trois endroits différents et grepper à la main.

Processus de développement

1. Conteneuriser l'app avec Docker pour que l'environnement testé soit celui qui part en production, avec un reverse proxy gérant le TLS et le routage.
2. Mettre en place la CI/CD pour que chaque push exécute les mêmes étapes de build et de tests, interceptant un déploiement cassé avant qu'il atteigne la production.
3. Planifier des sauvegardes pour la base de données réellement utilisée — PostgreSQL, MySQL ou SQLite — et vérifier la restauration, pas juste le code de sortie du job de sauvegarde.
4. Gérer les secrets via des variables d'environnement ou un gestionnaire de secrets, jamais commités dans le dépôt, et les faire tourner quand quelqu'un avec accès part.
5. Séparer les responsabilités même sur un seul serveur — base, app, reverse proxy dans leurs propres conteneurs — pour qu'un mauvais déploiement de l'un ne fasse pas tomber les autres.
6. Garder le staging assez proche de la production — mêmes conteneurs, forme de données similaire — pour qu'une différence de config apparaisse là, pas devant les clients.
7. Scripter le provisioning des serveurs (ou utiliser l'infra as code) pour que remplacer un VPS en panne soit exécuter un script, pas reconstruire la config de mémoire sous pression.
8. Centraliser les logs de chaque conteneur en un seul endroit consultable, pour que déboguer un problème soit une requête de recherche, pas une session SSH dans trois machines différentes.

Ce que vous obtenez

• Un déploiement qui marche pareil sur la machine suivante que sur la première, parce que l'environnement est défini dans le code, pas dans une mémoire.
• Des sauvegardes dont la restauration a vraiment été prouvée, pas juste planifiées en espérant que ça marche.
• Des problèmes révélés par une alerte avant qu'un client ne les remarque, parce que le monitoring est calibré pour l'équipe, pas ignoré comme un dashboard que personne n'ouvre.
• Des secrets qui ne traînent pas dans un historique git à la portée de quiconque a accès au dépôt.
• Un mauvais déploiement qui fait tomber un conteneur au lieu de toute la pile, parce que les responsabilités ont été séparées dès le départ.
• Des différences de configuration attrapées en staging, avant d'atteindre un client, plutôt que débuguées en direct en production.
• Un serveur en panne remplacé en exécutant un script en quelques minutes, au lieu d'un après-midi stressant à reconstruire la config de mémoire.
• Un problème débogué depuis une seule vue de logs consultable au lieu de sessions SSH dans trois conteneurs différents en espérant trouver la bonne ligne.
• Un historique de déploiement qui montre exactement ce qui a changé et quand, pour qu'une régression se retrace jusqu'au commit qui l'a causée plutôt que d'être devinée.

Projets choisis