Tester les modifications d'infrastructure sans casser la production
Un développeur modifie une règle de pare-feu. "Juste un petit ajustement de config", pense-t-il. Quelques minutes plus tard, plus personne ne peut accéder à l'application. Les utilisateurs signalent des erreurs. L'équipe s'agite pour comprendre ce qui s'est passé.
Ce scénario se produit plus souvent que la plupart des équipes ne veulent l'admettre. Les changements d'infrastructure comportent des risques cachés. Une erreur de configuration de base de données peut corrompre des données. Un changement de politique réseau peut isoler des services entiers. Et contrairement au code applicatif, les problèmes d'infrastructure affectent souvent tout à la fois.
La question que chaque équipe doit se poser : où tester les modifications d'infrastructure avant qu'elles n'atteignent la production ?
Le problème des environnements pour l'infrastructure
Quand les équipes géraient les serveurs manuellement, la réponse était souvent vague. Certains avaient un serveur de test. D'autres modifiaient directement la production parce que "c'est juste une petite modification de config". Les petites modifications d'infrastructure ont rarement un petit impact.
Les applications ont une réponse naturelle à ce problème : les environnements de staging. Vous testez la nouvelle fonctionnalité en staging, vérifiez qu'elle fonctionne, puis déployez en production. L'infrastructure nécessite la même approche, mais avec une particularité.
Vous ne pouvez pas toujours copier l'infrastructure à l'identique. Créer des serveurs, réseaux et bases de données en double coûte de l'argent réel. Un environnement de staging qui reflète une configuration de production avec des dizaines de serveurs, des équilibreurs de charge et des clusters de bases de données peut multiplier votre facture d'infrastructure. Le défi est de trouver l'équilibre entre des tests approfondis et la maîtrise des coûts.
Le principe fondamental : isoler avant de tester
Chaque modification d'infrastructure doit passer par un environnement isolé avant de toucher la production. L'isolation ici est stricte : l'environnement de staging ne doit partager aucune ressource avec la production. Pas de base de données partagée. Pas de réseau partagé. Pas d'accès aux données utilisateur réelles.
Si votre staging et votre production partagent encore un serveur ou se trouvent dans le même VPC, ce n'est pas de l'isolation. Une erreur dans le staging peut se répercuter sur la production. Une base de données de staging mal configurée peut écraser les données de production. Des règles réseau partagées peuvent exposer les services de staging au trafic de production.
L'isolation seule ne suffit pas. L'environnement de staging doit reproduire la configuration de production aussi fidèlement que possible. Si la production utilise trois serveurs derrière un équilibreur de charge, le staging doit avoir la même configuration. Si la production utilise une version spécifique de base de données, le staging doit correspondre.
L'objectif n'est pas de rendre le staging aussi puissant que la production. L'objectif est de détecter les problèmes qui n'apparaissent qu'avec des configurations spécifiques. Une requête de base de données qui fonctionne parfaitement sur une petite instance de staging peut expirer en production sous charge. Une règle réseau qui passe dans une configuration simplifiée peut bloquer le trafic légitime dans la topologie réelle.
Couches d'environnement pratiques
La plupart des équipes finissent par avoir plusieurs couches d'environnements d'infrastructure. Chaque couche sert un objectif différent et présente des compromis différents entre coût et fidélité.
L'environnement de développement est destiné aux développeurs qui testent de petites modifications. Il peut utiliser des ressources minimales et des configurations simplifiées. Un seul petit serveur au lieu d'un cluster. Une base de données locale au lieu d'une configuration répliquée. L'exigence clé est l'isolation par rapport au staging et à la production. Les environnements de développement ne doivent jamais toucher aux ressources de production, même accidentellement.
L'environnement de staging est destiné aux tests intégrés. Il doit refléter la configuration de production aussi fidèlement que possible, même si l'échelle est plus petite. Même version de système d'exploitation. Mêmes versions d'exécution. Même topologie réseau. La différence réside généralement dans la capacité : moins de serveurs, des instances plus petites, moins de stockage. Mais les modèles de configuration doivent correspondre.
L'environnement de production exécute le service réel. Les modifications n'y parviennent qu'après avoir réussi les étapes de développement et de staging.
Le diagramme ci-dessous montre comment les modifications transitent par chaque couche d'environnement, avec des passerelles de validation empêchant les changements non vérifiés d'atteindre la production.
Le piège de la configuration
Un détail qui fait trébucher de nombreuses équipes : la configuration spécifique à l'environnement. Les mots de passe de base de données, les clés API et les adresses de serveur diffèrent évidemment entre les environnements. Mais les autres configurations doivent rester cohérentes.
Les versions de système d'exploitation doivent être les mêmes dans tous les environnements. Les versions d'exécution doivent correspondre. Les règles de journalisation doivent être identiques. Lorsque celles-ci diffèrent entre les environnements, vous créez une faille où les problèmes peuvent se cacher. Un bug qui n'apparaît que sur une version spécifique du système d'exploitation pourrait ne jamais se manifester en staging si le staging utilise une version différente.
La solution consiste à séparer la configuration par type. Les valeurs spécifiques à l'environnement vont dans des fichiers séparés par environnement. La configuration commune est écrite une fois et appliquée partout. Lorsque vous mettez à niveau la version du système d'exploitation, vous la modifiez à un seul endroit, pas dans trois fichiers différents.
Comment le CI/CD gère les environnements d'infrastructure
Le pipeline pour les modifications d'infrastructure suit une séquence claire :
- Examiner la modification via une revue de code ou des outils de planification
- Appliquer automatiquement la modification au staging
- Exécuter des tests pour vérifier que les ressources sont créées correctement
- Valider que les ressources existantes ne sont pas cassées
- Appliquer la même modification à la production
Chaque étape se fait via les mêmes outils d'infrastructure-as-code. Le même plan Terraform, le même playbook Ansible, le même programme Pulumi s'exécute d'abord sur le staging. S'il réussit, il s'exécute sur la production.
Ce processus garantit que chaque modification d'infrastructure passe par un environnement qui reflète la production avant d'affecter les utilisateurs réels. Le pipeline impose la discipline que les processus manuels ignorent souvent.
Liste de contrôle pratique pour les environnements d'infrastructure
- Le staging se trouve dans un VPC ou un compte séparé de la production
- Le staging n'a pas accès aux bases de données ou au stockage de production
- Le staging utilise la même version de système d'exploitation et les mêmes versions d'exécution que la production
- La configuration commune est définie une fois et partagée entre les environnements
- Les valeurs spécifiques à l'environnement sont isolées dans des fichiers séparés
- Le pipeline applique d'abord les modifications au staging, puis à la production
- Des tests sont exécutés après l'application au staging pour vérifier l'exactitude
Prochaines étapes
Tester les modifications d'infrastructure dans des environnements isolés détecte la plupart des problèmes avant qu'ils n'atteignent la production. Mais cela ne détecte pas tout. Une modification qui fonctionne parfaitement en staging peut encore causer des problèmes lorsqu'elle est appliquée à la production à grande échelle ou sous des modèles de trafic réels.
C'est là que la politique et la gouvernance entrent en jeu. La prochaine étape consiste à définir des règles sur les modifications autorisées, qui peut les approuver et quelles conditions doivent être remplies avant le déploiement en production. Mais c'est un sujet pour un autre article.
Pour l'instant, le point essentiel est le suivant : si vos modifications d'infrastructure vont directement en production sans passer par un environnement de staging isolé, vous êtes à un petit ajustement de config d'une panne de production. Mettez d'abord en place les environnements. Laissez le pipeline imposer la discipline. Vos utilisateurs vous remercieront.