Bonnes pratiques pour le contrôle des versions

Ce document présente les bonnes pratiques de contrôle des versions à prendre en compte lors de l'utilisation de Terraform pour Google Cloud.

Comme pour les autres formes de code, stockez le code d'infrastructure dans le contrôle des versions afin de conserver l'historique et de faciliter les rollbacks.

Ce guide n'est pas une introduction à Terraform. Pour une présentation de l'utilisation de Terraform avec Google Cloud, consultez la page Premiers pas avec Terraform.

Utiliser une stratégie d'embranchement par défaut

Pour tous les dépôts contenant du code Terraform, utilisez par défaut la stratégie suivante :

  • La branche main est la branche de développement principale et représente le dernier code approuvé. La branche main est protégée.
  • Le développement s'effectue sur des branches de fonctionnalités et de correction de bugs qui partent de la branche main.
    • Nommez les branches de fonctionnalités feature/$feature_name.
    • Nommez les branches de correction de bugs fix/$bugfix_name.
  • Une fois la fonctionnalité ou la correction de bug terminée, refusionnez-la dans la branche main avec une demande d'extraction.
  • Pour éviter les conflits de fusion, redéfinissez les branches avant de les fusionner.

Utiliser des branches d'environnement pour les configurations racine

Pour les dépôts qui incluent des configurations racine déployées directement sur Google Cloud, une stratégie de déploiement sécurisé est requise. Nous vous recommandons de disposer d'une branche distincte pour chaque environnement. Ainsi, les modifications apportées à la configuration Terraform peuvent être promues en fusionnant les modifications entre les différentes branches.

Branche distincte pour chaque environnement

Autoriser une visibilité étendue

Rendre le code source et les dépôts Terraform largement visibles et accessibles dans tous les corps d'ingénierie, des propriétaires (par exemple, SRE) aux parties prenantes de l'infrastructure (par exemple, les développeurs). Ainsi, les parties prenantes peuvent mieux comprendre l'infrastructure dont elles dépendent.

Encouragez les parties prenantes de l'infrastructure à envoyer des demandes de fusion dans le cadre du processus de demande de modification.

Ne jamais intégrer de secret dans un commit

N'intégrez jamais de secrets dans un commit pour le contrôle des sources, y compris dans la configuration Terraform. Importez-les plutôt dans un système tel que Secret Manager, puis référencez-les en utilisant des sources de données.

Gardez à l'esprit que ces valeurs sensibles peuvent toujours se retrouver dans le fichier d'état et être également exposées en tant que sorties.

Organiser les dépôts en fonction des limites de l'équipe

Bien que vous puissiez utiliser des répertoires distincts pour gérer les limites logiques entre les ressources, ce sont les limites organisationnelles et logistiques qui déterminent la structure du dépôt. En général, suivez le principe de conception selon lequel les configurations ayant différentes exigences d'approbation et de gestion doivent être séparées dans différents dépôts de gestion de code source. Pour illustrer ce principe, voici quelques configurations de dépôt possibles :

  • Un seul dépôt central : dans ce modèle, tout le code Terraform est géré de manière centralisée par une équipe de plate-forme unique. Ce modèle fonctionne mieux lorsqu'une équipe d'infrastructure dédiée est responsable de la gestion du cloud et approuve les modifications demandées par d'autres équipes.

  • Dépôts d'équipe : dans ce modèle, chaque équipe est responsable de son propre dépôt Terraform, dans lequel elle gère tout ce qui est lié à l'infrastructure dont elle est propriétaire. Par exemple, l'équipe de sécurité peut disposer d'un dépôt dans lequel tous les contrôles de sécurité sont gérés, et les équipes de développement peuvent disposer de leur propre dépôt Terraform pour déployer et gérer leur application.

    L'organisation des dépôts en fonction des limites d'équipe constitue la meilleure structure pour la plupart des scénarios d'entreprise.

  • Dépôts découplés : dans ce modèle, chaque composant Terraform logique est placé dans son propre dépôt. Par exemple, la mise en réseau peut disposer d'un dépôt dédié alors qu'un autre peut être utilisé pour la création et la gestion de projets. Cette approche est plus adaptée aux environnements hautement décentralisés, dans lesquels les responsabilités changent fréquemment entre les équipes.

Exemple de structure de dépôt

Vous pouvez combiner ces principes pour répartir la configuration Terraform sur différents types de dépôts :

  • Élémentaire
  • Spécifique aux application et aux équipes

Dépôt élémentaire

Un dépôt élémentaire contenant les principaux composants centraux tels que les dossiers ou la configuration IAM d'organisation. Ce dépôt peut être géré par l'équipe cloud centrale.

  • Dans ce dépôt, incluez un répertoire pour chaque composant principal (dossiers, réseaux, etc.).
  • Dans les répertoires de composants, incluez un dossier distinct pour chaque environnement (en appliquant les conseils de structure de répertoire mentionnées précédemment).

Structure de dépôt élémentaire

Dépôts spécifiques aux applications et aux équipes

Déployez les dépôts spécifiques à une application et à une équipe séparément pour chaque équipe afin de gérer sa configuration Terraform unique spécifique à l'application.

Structure du dépôt spécifique à l'application et à l'équipe

Étapes suivantes