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.
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 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 terraform-example-foundation 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 |
|---|---|
Amorçage d'une organisation Google Cloud Cette étape configure également un pipeline CI/CD pour le code du plan lors des étapes suivantes.
|
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 |
|---|---|
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. |
|
Configure les environnements de développement, hors production et de production au sein de l'organisation Google Cloud que vous avez créée. |
|
ou |
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 de VM et les bases de données) 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.
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'elles 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 |
|---|---|
Configure une structure de dossiers, des projets et un pipeline d'infrastructure. |
|
|
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és à 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 d'abord exécuter la commande |
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 |
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 |
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 |
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.
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 (pull request, PR) 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, suivez les principales étapes suivantes :
- 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. - Lorsque vous terminez le travail dans la branche de fonctionnalité, ouvrez une demande d'extraction qui cible la branche de développement.
- Lorsque vous envoyez la demande d'extraction, celle-ci déclenche le pipeline de base pour effectuer
terraform planetterraform validateafin de préparer et de vérifier les modifications. - Après avoir validé les modifications apportées au code, fusionnez la fonctionnalité ou la correction de bug dans la branche de développement.
- Le processus de fusion déclenche le pipeline de base pour exécuter
terraform applyafin de déployer les dernières modifications de la branche de développement dans l'environnement de développement. - 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.
- 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
- Découvrez les bonnes pratiques relatives aux opérations (document suivant de cette série).