Arrêtez de Mélanger les Environnements : Pourquoi vos États Dev et Prod ne Devraient Jamais se Toucher

Vous avez trois dossiers : dev, staging et prod. Chacun contient des fichiers de configuration, des enregistrements d'état et des définitions de ressources. Lorsque vous devez mettre à jour une règle de pare-feu, vous ouvrez les trois dossiers et effectuez la même modification trois fois. Un après-midi, vous oubliez de mettre à jour staging. Deux semaines plus tard, un déploiement vers staging échoue car le pare-feu bloque une connexion qui fonctionne partout ailleurs. Personne ne le remarque jusqu'à ce que la mise en production soit bloquée.

Cette situation est courante. Les équipes commencent avec un environnement, puis en ajoutent un autre, puis un autre. La séparation semble claire car les dossiers ont des noms différents. Mais la séparation n'est que cosmétique. Le vrai problème est que la même personne, le même outil et le même modèle d'accès peuvent toucher chaque environnement sans aucune barrière de sécurité.

Le Vrai Problème de la Séparation des Environnements

La séparation des environnements ne concerne pas les noms de dossiers. Il s'agit de garantir que les modifications en développement n'affectent jamais accidentellement la production, et que les tests en staging reflètent réellement les conditions de production.

Lorsque vous utilisez le même fichier d'état pour tous les environnements, vous créez un point de défaillance unique. Une erreur en développement peut supprimer une ressource de production. Un pipeline CI mal configuré peut appliquer des valeurs de staging à l'infrastructure de production. Ces risques ne sont pas théoriques. Ils se produisent lorsque les équipes partagent des fichiers d'état, des backends ou des identifiants d'accès entre les environnements.

L'objectif est de rendre impossible la modification accidentelle de la production tout en travaillant sur le développement. Cela nécessite plus que de la discipline. Cela nécessite une séparation structurelle.

Trois Approches pour la Séparation des Environnements

1. Dossiers Séparés

Le diagramme suivant présente chaque approche avec sa structure et ses caractéristiques clés :

C'est l'approche la plus simple. Vous créez un dossier pour chaque environnement : dev/, staging/, prod/. Chaque dossier contient ses propres fichiers de configuration et son propre fichier d'état. Lorsque vous exécutez une commande, vous spécifiez le dossier à utiliser.

Cela fonctionne bien pour les petites équipes avec peu d'environnements. Vous pouvez voir les différences entre les environnements en comparant les fichiers côte à côte. La structure est facile à comprendre. Les nouveaux membres de l'équipe peuvent trouver ce dont ils ont besoin sans demander.

Le problème apparaît lorsque les environnements partagent la majeure partie de leur configuration. Le développement et le staging peuvent ne différer que par la taille du serveur et le nom de la base de données. Lorsque vous devez modifier un paramètre de sécurité, vous devez mettre à jour trois fichiers. En oublier un crée une dérive invisible. Avec le temps, les environnements divergent jusqu'à ce que le staging ne représente plus la production.

2. Structure Partagée avec Fichiers de Configuration Séparés

Au lieu de dupliquer l'ensemble de la configuration, vous conservez un ensemble de définitions de ressources et des fichiers séparés pour les valeurs spécifiques à l'environnement. Les fichiers principaux définissent la logique et la structure. Les fichiers de configuration contiennent des valeurs comme les noms de serveurs, les tailles d'instances et les chaînes de connexion.

Cette approche réduit la duplication. Vous écrivez les définitions de ressources une seule fois. Lorsque vous modifiez une règle de pare-feu, vous la modifiez à un seul endroit. Les fichiers spécifiques à l'environnement ne contiennent que les valeurs qui diffèrent réellement.

La contrepartie est la complexité. Vous devez comprendre comment les fichiers de configuration fusionnent avec les définitions principales. Vous devez vous assurer que chaque environnement dispose du fichier de configuration correct. Une valeur manquante peut entraîner l'échec d'un déploiement ou, pire, l'utilisation d'une valeur par défaut incorrecte pour cet environnement.

3. Backends d'État Séparés

C'est l'approche la plus mature. Chaque environnement utilise un backend différent pour stocker son fichier d'état. Le fichier d'état enregistre chaque ressource qui a été créée et gérée. Lorsque les backends sont séparés, l'état de développement ne peut pas se mélanger accidentellement avec l'état de production.

Voici un exemple concret de configuration de backends d'état séparés dans Terraform avec S3 :

# configuration du backend pour l'environnement de production
terraform {
  backend "s3" {
    bucket = "my-company-tfstate"
    key    = "prod/terraform.tfstate"
    region = "us-east-1"
  }
}

Pour l'environnement de staging, vous utiliseriez le même bucket mais une clé différente :

terraform {
  backend "s3" {
    bucket = "my-company-tfstate"
    key    = "staging/terraform.tfstate"
    region = "us-east-1"
  }
}

Et pour le développement :

terraform {
  backend "s3" {
    bucket = "my-company-tfstate"
    key    = "dev/terraform.tfstate"
    region = "us-east-1"
  }
}

Le fichier d'état de chaque environnement est stocké sous un préfixe séparé dans le même bucket S3. Vous pouvez ensuite appliquer des politiques d'accès au niveau du bucket ou du préfixe, garantissant que les développeurs ne peuvent lire et écrire que le préfixe dev/ tandis que l'accès à la production est restreint à votre pipeline CI/CD.

Vous pouvez appliquer des politiques d'accès au niveau du backend. Les membres de l'équipe de développement ne peuvent accéder qu'au backend de développement. Les équipes d'exploitation ou SRE détiennent l'accès au backend de production. Un développeur exécutant une commande depuis son ordinateur portable ne peut pas toucher aux ressources de production car ses identifiants n'ont pas accès au backend de production.

Cette séparation est essentielle car les fichiers d'état contiennent des informations sensibles. L'état de production enregistre généralement les adresses IP des serveurs, les connexions aux bases de données et les configurations de sécurité. Si les états de production et de développement sont stockés au même endroit, une fuite ou une modification accidentelle affecte les deux environnements. Avec des backends séparés, vous pouvez appliquer différentes politiques de sécurité à chaque environnement.

Quand Utiliser Chaque Approche

Choisissez des dossiers séparés lorsque votre projet est petit, que vous avez peu d'environnements et que les ressources diffèrent considérablement entre les environnements. C'est un bon point de départ, mais prévoyez de passer à autre chose à mesure que l'équipe grandit.

Choisissez une structure partagée avec des fichiers de configuration séparés lorsque vos environnements ont la même structure mais des valeurs différentes. Cela fonctionne bien pour les équipes qui ont standardisé leur infrastructure et n'ont besoin que de faire varier des paramètres comme la taille, la région ou le nommage.

Choisissez des backends d'état séparés lorsque votre équipe est nombreuse, que la production doit être strictement protégée ou que vous avez besoin d'une piste d'audit pour chaque modification. C'est l'approche qui passe à l'échelle avec la complexité organisationnelle.

L'Aspect Politique de la Séparation des Environnements

La séparation technique n'est que la moitié de la solution. Vous pouvez avoir une séparation parfaite des backends, mais si chaque membre de l'équipe a accès au backend de production depuis son ordinateur portable, la séparation est sans signification.

La séparation des environnements nécessite des politiques. Qui peut lire l'état de production ? Qui peut le modifier ? Qui peut approuver les modifications de l'infrastructure de production ? Ces questions doivent être répondues et appliquées via des contrôles d'accès, et non par des accords verbaux.

Certaines équipes utilisent un pipeline CI/CD séparé pour les déploiements en production. Le pipeline de production s'exécute uniquement à partir d'une branche spécifique, nécessite des approbations et utilise des identifiants qui ne sont pas disponibles pour les développeurs. Cela ajoute une couche supplémentaire de séparation au-delà du backend lui-même.

Liste de Vérification Pratique

• Chaque environnement utilise un backend d'état différent
• Le backend de production n'est accessible que depuis un pipeline CI/CD, pas depuis des machines locales
• Les backends de développement et de staging sont accessibles aux développeurs
• Les fichiers d'état sont chiffrés au repos
• L'accès à l'état de production nécessite une approbation et est journalisé
• Les valeurs de configuration sont validées avant d'atteindre la production

L'Essentiel à Retenir

La séparation des environnements n'est pas un problème de structure de dossiers. C'est un problème d'isolation de l'état. Lorsque vous traitez chaque environnement comme un système complètement séparé avec son propre backend d'état, ses propres contrôles d'accès et son propre pipeline de déploiement, vous éliminez la possibilité de modifications accidentelles entre environnements. Commencez par des dossiers séparés si vous le devez, mais passez à des backends séparés avant que votre équipe ne dépasse cinq personnes. Le coût de la correction d'une panne de production causée par un état partagé est toujours plus élevé que le coût de la mise en place d'une séparation appropriée dès le départ.