Méthodologie de déploiement

Last reviewed 2023-12-20 UTC

Nous vous recommandons d'utiliser une infrastructure déclarative pour déployer vos fondations de manière cohérente et contrôlable. Cette approche permet d'assurer une gouvernance cohérente en appliquant des contrôles de stratégie concernant les configurations de ressources acceptables dans vos pipelines. Le plan est déployé à l'aide d'un flux GitOps, avec Terraform utilisé pour définir une Infrastructure as Code (IaC), un dépôt Git pour le contrôle et l'approbation des versions du code, et Cloud Build pour l'automatisation CI/CD dans le pipeline de déploiement. Pour obtenir une présentation de ce concept, consultez la page Gérer une Infrastructure as Code avec Terraform, Cloud Build et GitOps.

Les sections suivantes décrivent comment le pipeline de déploiement est utilisé pour gérer les ressources de votre organisation.

Couches de pipeline

Pour séparer les équipes et la pile technologique chargée de gérer différentes couches de votre environnement, nous vous recommandons un modèle utilisant différents pipelines et différents personas responsables de chaque couche de la pile.

Le schéma suivant présente notre modèle recommandé pour séparer un pipeline de base, un pipeline d'infrastructure et un pipeline d'application.

Pipelines de plan.

Le schéma présente les couches de pipeline dans ce modèle:

  • Le pipeline de base déploie les ressources de base utilisées sur la plate-forme. Nous recommandons à une seule équipe centrale de gérer les ressources de base utilisées par plusieurs unités commerciales et charges de travail.
  • Le pipeline d'infrastructure déploie les projets et l'infrastructure utilisés par les charges de travail, telles que les instances ou VM de bases de données. Le plan configure un pipeline d'infrastructure distinct pour chaque unité commerciale, ou vous pouvez préférer un seul pipeline d'infrastructure utilisé par plusieurs équipes.
  • Le pipeline d'applications déploie les artefacts pour chaque charge de travail, tels que les conteneurs ou les images. Vous pouvez avoir de nombreuses équipes de développement d'applications avec des pipelines d'application individuels.

Les sections suivantes présentent l'utilisation de chaque couche de pipeline.

Le pipeline de base

Le pipeline de base déploie les ressources de base. Il configure également le pipeline d'infrastructure utilisé pour déployer l'infrastructure utilisée par les charges de travail.

Pour créer le pipeline de base, vous devez d'abord cloner ou dupliquer la base Terraform-example dans votre propre dépôt Git. Suivez les étapes du fichier README de 0-bootstrap pour configurer votre dossier et vos ressources d'amorçage.

Étape Description

0-bootstrap

Amorçage d'une organisation Google Cloud Cette étape configure également un pipeline CI/CD pour le code du plan lors des étapes suivantes.

  • Le projet CICD contient le pipeline de base Cloud Build pour le déploiement de ressources.
  • Le projet seed inclut les buckets Cloud Storage contenant l'état Terraform de l'infrastructure de base et inclut des comptes de service à privilèges élevés utilisés par le pipeline de base pour créer des ressources. L'état Terraform est protégé via la gestion des versions d'objets de stockage. Lorsque le pipeline CI/CD s'exécute, il agit en tant que comptes de service gérés dans le projet seed.

Une fois que vous avez créé le pipeline de base à l'étape 0-bootstrap, les étapes suivantes déploient des ressources sur le pipeline de base. Consultez les instructions de fichier README pour chaque étape et mettez en œuvre chaque étape de manière séquentielle.

Étape Description

1-org

Configure les dossiers partagés de premier niveau, les projets pour les services partagés, la journalisation au niveau de l'organisation et les paramètres de sécurité de base via des règles d'administration.

2-environments

Configure les environnements de développement, hors production et de production au sein de l'organisation Google Cloud que vous avez créée.

3-networks-dual-svpc

ou

3-networks-hub-and-spoke

configure les VPC partagés dans la topologie choisie et les ressources réseau associées.

Pipeline d'infrastructure

Le pipeline d'infrastructure déploie les projets et l'infrastructure (par exemple, les instances et les bases de données de VM) utilisées par les charges de travail. Le pipeline de base déploie plusieurs pipelines d'infrastructure. Cette séparation entre le pipeline de base et le pipeline d'infrastructure permet de séparer les ressources à l'échelle de la plate-forme des ressources spécifiques à la charge de travail.

Le schéma suivant montre comment le plan configure plusieurs pipelines d'infrastructure destinés à être utilisés par des équipes distinctes.

Pipelines d'infrastructure multiples

Le schéma décrit les concepts clés suivants:

  • Chaque pipeline d'infrastructure permet de gérer les ressources d'infrastructure indépendamment des ressources de base.
  • Chaque unité commerciale dispose de son propre pipeline d'infrastructure, géré dans un projet dédié du dossier common.
  • Chacun des pipelines d'infrastructure dispose d'un compte de service autorisé à déployer des ressources uniquement sur les projets associés à cette unité commerciale. Cette stratégie crée une séparation des tâches entre les comptes de services privilégiés utilisés pour le pipeline de base et ceux utilisés par chaque pipeline d'infrastructure

Cette approche comportant plusieurs pipelines d'infrastructure est recommandée lorsque vous disposez de plusieurs entités au sein de votre organisation qui ont les compétences et l'intérêt pour gérer leur infrastructure séparément, en particulier si elles ont des exigences différentes, telles que les types de stratégie de validation du pipeline qu'ils souhaitent appliquer. Vous pouvez également avoir un seul pipeline d'infrastructure géré par une seule équipe avec des règles de validation cohérentes.

Dans la section terraform-example-foundation, l'étape 4 configure un pipeline d'infrastructure et l'étape 5 illustre un exemple d'utilisation de ce pipeline pour déployer des ressources d'infrastructure.

Étape Description

4-projects

Configure une structure de dossiers, des projets et un pipeline d'infrastructure.

5-app-infra (Facultatif)

Déploie des projets de charge de travail avec une instance Compute Engine en utilisant le pipeline d'infrastructure comme exemple.

Pipeline de l'application

Le pipeline d'application est responsable du déploiement des artefacts d'application pour chaque charge de travail individuelle, comme les images ou les conteneurs Kubernetes qui exécutent la logique métier de votre application. Ces artefacts sont déployés sur les ressources d'infrastructure déployées par votre pipeline d'infrastructure.

Le plan d'entreprise de base configure votre pipeline de base et votre pipeline d'infrastructure, mais ne déploie pas de pipeline d'application. Pour obtenir un exemple de pipeline d'application, consultez le plan d'application d'entreprise.

Automatiser votre pipeline avec Cloud Build

Le plan utilise Cloud Build pour automatiser les processus CI/CD. Le tableau suivant décrit les contrôles intégrés au pipeline de base et au pipeline d'infrastructure déployés par le dépôt terraform-example-foundation. Si vous développez vos propres pipelines à l'aide d'autres outils d'automatisation CI/CD, nous vous recommandons d'appliquer des contrôles similaires.

Contrôle Description

Séparer les configurations de compilation pour valider le code avant le déploiement

Le plan utilise deux fichiers de configuration de compilation Cloud Build pour l'ensemble du pipeline, et chaque dépôt associé à une étape comporte deux déclencheurs Cloud Build qui sont associées à ces fichiers de configuration de compilation. Lorsque du code est transféré vers une branche de dépôt, les fichiers de configuration de compilation sont déclenchés pour exécuter la première commande cloudbuild-tf-plan.yaml, ce qui valide votre code à l'aide de vérifications des stratégies et de la planification Terraform par rapport à cette branche, puis cloudbuild-tf-apply.yaml exécute terraform apply sur le résultat de ce plan.

Vérifications des règles Terraform

Le plan inclut un ensemble de contraintes Open Policy Agent appliquées par la validation de stratégie dans Google Cloud CLI. Ces contraintes définissent les configurations de ressources acceptables pouvant être déployées par le pipeline. Si une compilation ne répond pas aux règles de la première configuration de compilation, alors la deuxième configuration de compilation ne déploie aucune ressource.

Les règles appliquées dans le plan sont dupliquées à partir de GoogleCloudPlatform/policy-library sur GitHub. Vous pouvez écrire des règles supplémentaires pour la bibliothèque afin d'appliquer des règles personnalisées qui répondent à vos besoins.

Principe du moindre privilège

Le pipeline de base possède un compte de service différent pour chaque étape avec une stratégie d'autorisation qui n'accorde que les rôles IAM minimaux pour cette étape. Chaque déclencheur Cloud Build s'exécute en tant que compte de service spécifique pour cette étape. L'utilisation de comptes différents permet de limiter le risque que la modification d'un dépôt puisse affecter les ressources gérées par un autre dépôt. Pour comprendre les rôles IAM spécifiques appliqués à chaque compte de service, consultez le code Terraform sa.tf lors de l'étape d'amorçage.

Pools privés Cloud Build

Le plan utilise des pools privés Cloud Build. Les pools privés vous permettent éventuellement d'appliquer des contrôles supplémentaires, tels que la restriction d'accès aux dépôts publics ou l'exécution de Cloud Build dans un périmètre VPC Service Controls.

Compilateurs personnalisés Cloud Build

Le plan crée son propre compilateur personnalisé pour exécuter Terraform. Pour en savoir plus, consultez 0-bootstrap/Dockerfile. Ce contrôle impose que le pipeline s'exécute de manière cohérente avec un ensemble connu de bibliothèques aux versions épinglées.

Approbation de déploiement

Vous pouvez éventuellement ajouter une étape d'approbation manuelle à Cloud Build. Cette approbation ajoute un point de contrôle supplémentaire après le déclenchement de la compilation, mais avant son exécution, afin qu'un utilisateur privilégié puisse l'approuver manuellement.

Stratégie d'embranchement

Nous recommandons la stratégie d'une branche persistante pour envoyer du code à votre système Git et déployer des ressources via le pipeline de base. Le schéma suivant décrit la stratégie de branche persistante.

Stratégie de branche du déploiement du plan

Le schéma décrit trois branches persistantes dans Git (développement, hors production et production) qui reflètent les environnements Google Cloud correspondants. Il existe également plusieurs branches de fonctionnalités éphémères qui ne correspondent pas aux ressources déployées dans vos environnements Google Cloud.

Nous vous recommandons d'appliquer un processus de demande d'extraction dans votre système Git afin que tout code fusionné dans une branche persistante soit associé à une demande d'extraction approuvée.

Pour développer du code avec cette stratégie de branche persistante, procédez comme suit:

  1. Lorsque vous développez de nouvelles fonctionnalités ou travaillez sur une correction de bug, créez une branche basée sur la branche de développement. Utilisez une convention d'attribution de noms pour votre branche, qui inclut le type de modification, un numéro de ticket ou un autre identifiant, ainsi qu'une description lisible, telle que feature/123456-org-policies.
  2. Lorsque vous terminez le travail dans la branche de fonctionnalité, ouvrez une demande d'extraction qui cible la branche de développement.
  3. Lorsque vous envoyez la demande d'extraction, celle-ci déclenche le pipeline de base pour effectuer terraform plan et terraform validate afin de préparer et de vérifier les modifications.
  4. Après avoir validé les modifications apportées au code, fusionnez la fonctionnalité ou la correction de bug dans la branche de développement.
  5. Le processus de fusion déclenche le pipeline de base pour exécuter terraform apply afin de déployer les dernières modifications de la branche de développement dans l'environnement de développement.
  6. Examinez les modifications apportées à l'environnement de développement à l'aide d'examens manuels, de tests fonctionnels ou de tests de bout en bout pertinents pour votre cas d'utilisation. Faites ensuite la promotion des modifications dans l'environnement hors production en ouvrant une demande d'extraction qui cible la branche hors production et en fusionnant vos modifications.
  7. Pour déployer des ressources dans l'environnement de production, répétez le même processus que pour l'étape 6 : examinez et validez les ressources déployées, ouvrez une demande d'extraction sur la branche de production et fusionnez.

Étapes suivantes