Pourquoi la gestion de l'état et des environnements est cruciale avant que votre infrastructure ne tombe en panne
Imaginez que vous et un collègue gérez le même serveur. Vous mettez à jour la configuration du pare-feu pour ouvrir le port 443. Votre collègue, sans le savoir, modifie la même configuration pour ouvrir le port 80 à la place. Vous appliquez tous les deux vos changements à quelques minutes d'intervalle. Résultat : le serveur se retrouve avec des règles contradictoires. Quelle modification est réellement en vigueur ? Personne ne le sait.
C'est le premier vrai problème qui survient lorsque l'on gère l'infrastructure avec du code : le dernier à appliquer l'emporte. Mais gagner ne signifie pas que la bonne modification est en place. Peut-être que le changement de votre collègue était le bon, mais qu'il s'est terminé quelques secondes plus tard. Ou peut-être que le vôtre était correct, mais qu'il a été écrasé. Dans les deux cas, l'état final du serveur ne correspond à ce que personne n'avait prévu.
Ce problème a un nom : le conflit d'état. L'état est simplement l'enregistrement de ce à quoi ressemble votre infrastructure à un instant donné. Lorsque vous écrivez du code pour créer un serveur, le fichier d'état enregistre que le serveur existe, sa taille, le réseau auquel il est connecté, etc. Sans état, votre outil n'a aucune idée si un serveur existe déjà ou s'il doit être créé. Sans état, il ne peut pas non plus dire ce qui a changé depuis la dernière exécution de votre code.
Le problème du flou entre environnements
Considérez maintenant un scénario différent. Vous développez une nouvelle fonctionnalité sur votre ordinateur portable. Vous avez besoin d'un serveur pour la tester. Vous lancez un serveur dans votre compte cloud, vous essayez la fonctionnalité, puis vous oubliez de le supprimer. Ce serveur continue de tourner, continue d'engendrer des coûts, et personne ne sait qu'il existe. Quelques semaines plus tard, l'équipe de production remarque un serveur inconnu dans le même compte cloud. A-t-il été créé intentionnellement ? À quoi sert-il ? Est-il sécurisé ? Personne ne peut répondre.
Les deux problèmes — conflit d'état et mélange d'environnements — sont plus faciles à comprendre lorsqu'on les voit côte à côte.
C'est le problème du mélange d'environnements. Un environnement est simplement l'endroit où votre application ou votre infrastructure s'exécute. Idéalement, les environnements de développement, de recette et de production sont clairement séparés. Mais lorsque tout le monde peut créer des ressources dans le même compte cloud sans règles, les environnements se mélangent. Un serveur de développement peut accidentellement se connecter au réseau de production. Une base de données de production peut être effacée parce que quelqu'un a exécuté un script de développement dans le mauvais contexte.
Pourquoi la gestion manuelle masque ces problèmes
Les problèmes d'état et d'environnement n'apparaissent pas lorsque vous gérez l'infrastructure manuellement. Lorsque vous vous connectez à un serveur et modifiez la configuration une par une, vous voyez exactement ce qui se passe. Vous savez sur quel serveur vous êtes. Vous savez ce que vous avez changé. Il n'y a pas de fichier d'état caché à corrompre.
Mais lorsque vous gérez l'infrastructure avec du code, vous cessez de travailler directement sur les serveurs. Vous travaillez sur des fichiers d'état. Vous modifiez le code, l'outil lit l'état, le compare avec la réalité, puis effectue les modifications. Ce processus rend tout reproductible et auditable. Mais il introduit également de nouveaux modes de défaillance.
Les fichiers d'état peuvent être corrompus. Deux personnes peuvent modifier le même fichier d'état en même temps. L'état peut dériver de la réalité lorsque quelqu'un effectue une modification manuelle en dehors de l'outil. Les environnements peuvent se mélanger parce que le même code est appliqué partout sans limites claires.
Les concepts clés à comprendre
L'état est la source de vérité pour votre infrastructure. Il indique à votre outil de provisionnement ce qui existe déjà et ce qui doit changer. Des outils populaires comme Terraform, Pulumi et AWS CDK reposent tous sur des fichiers d'état. Sans un état précis, ces outils ne peuvent pas déterminer quoi créer, mettre à jour ou supprimer.
L'environnement est le contexte dans lequel votre application s'exécute. Au minimum, la plupart des équipes ont besoin de trois environnements :
- Développement : Où vous expérimentez et cassez des choses. Cet environnement doit être peu coûteux, rapide à recréer et isolé de tout le reste.
- Recette : Où vous validez les changements avant la production. Il doit refléter la production aussi fidèlement que possible sans le même risque.
- Production : Où les utilisateurs réels interagissent avec votre application. Cet environnement a les exigences de stabilité les plus élevées.
Ce qui se passe lorsque vous ignorez la gestion de l'état et des environnements
Les équipes qui négligent ces fondations rencontrent des schémas de douleur prévisibles :
- Des serveurs mystères apparaissent dans les comptes de production. Personne ne sait qui les a créés ni pourquoi. Les équipes de sécurité paniquent.
- Les déploiements échouent parce que les fichiers d'état sont verrouillés. Le pipeline d'un développeur détient le verrou d'état, bloquant tout le monde.
- La recette et la production dérivent. Les changements testés en recette fonctionnent bien, mais la production se comporte différemment parce que les environnements ne sont plus identiques.
- Des modifications accidentelles en production. Un développeur exécute un script destiné au développement, mais sa session terminal pointe vers l'environnement de production. Un simple changement de configuration fait tomber le site.
- Les retours arrière deviennent impossibles. Le fichier d'état ne correspond plus à la réalité, donc l'outil ne peut pas revenir à un état connu et correct.
Une approche pratique pour commencer
Vous n'avez pas besoin d'une équipe plateforme complexe pour résoudre ces problèmes. Commencez par les bases :
Séparez les comptes cloud ou les projets par environnement. Si vous utilisez AWS, créez des comptes séparés pour le développement, la recette et la production. Si vous utilisez GCP, utilisez des projets séparés. C'est l'isolation la plus forte que vous puissiez obtenir.
Utilisez un stockage d'état distant avec verrouillage. Stockez vos fichiers d'état dans un emplacement partagé comme S3, GCS ou Azure Blob Storage. Activez le verrouillage d'état pour que deux pipelines ne puissent pas modifier le même état simultanément.
Nommez vos ressources de manière cohérente. Incluez le nom de l'environnement dans chaque nom de ressource ou étiquette. Cela évite toute confusion lorsque vous regardez une liste de serveurs.
Automatisez la création d'environnements. Écrivez des scripts ou des pipelines qui créent et détruisent les environnements à la demande. Si vous pouvez recréer un environnement à partir de zéro en quelques minutes, vous réduisez le risque de dérive d'état.
Restreignez qui peut appliquer des changements en production. Utilisez des portes d'approbation ou des comptes de service séparés pour les déploiements en production. Tout le monde n'a pas besoin d'un accès à la production.
Une liste de contrôle rapide pour évaluer votre configuration actuelle
- Pouvez-vous lister chaque serveur ou ressource dans votre environnement de production en ce moment ?
- Savez-vous qui a créé chaque ressource et pourquoi ?
- Pouvez-vous recréer votre environnement de recette à partir de zéro en moins d'une heure ?
- Votre fichier d'état est-il stocké à distance avec verrouillage activé ?
- Vos environnements de développement, recette et production sont-ils dans des comptes cloud ou projets séparés ?
- Un développeur peut-il accidentellement appliquer un changement en production depuis son ordinateur portable ?
Si vous avez répondu "non" à l'une de ces questions, vous avez du travail à faire.
L'essentiel à retenir
La gestion de l'état et des environnements n'est pas un sujet avancé que vous traitez après que votre infrastructure est déjà en place. C'est le fondement qui rend tout le reste possible. Sans un état clair, vos outils ne peuvent pas fonctionner correctement. Sans environnements clairs, vos changements fuiront à travers les frontières et provoqueront des pannes imprévisibles.
Commencez par la séparation la plus simple que vous puissiez gérer : des comptes cloud ou des projets séparés pour chaque environnement, un état distant avec verrouillage et un nommage cohérent. Cela seul empêchera la plupart des problèmes courants qui affligent les équipes gérant l'infrastructure avec du code. Faites-le avant que les serveurs mystères n'apparaissent, pas après.