CI/CD modernes avec GKE : créer un système CI/CD

Cette architecture de référence vous fournit une méthode et une infrastructure initiale pour créer un système d'intégration continue et de livraison continue (CI/CD) moderne à l'aide d'outils tels que Google Kubernetes Engine, Cloud Build, Skaffold, kustomize, Config Management, Policy Controller Artifact Registry, et Cloud Deploy.

Ce document fait partie d'une série :

Ce document est destiné aux architectes d'entreprise et aux développeurs d'applications, ainsi qu'aux équipes chargées de la sécurité informatique, des DevOps et de l'ingénierie en fiabilité des sites (SRE). Une certaine expérience des outils et des processus de déploiement automatisés est utile pour comprendre les concepts présentés dans ce document.

Workflow CI/CD

Pour créer un système CI/CD moderne, vous devez d'abord choisir les outils et les services qui exécutent les fonctions principales du système. Cette architecture de référence se concentre sur la mise en œuvre des fonctions de base d'un système CI/CD présentées dans le schéma suivant :

Plusieurs équipes gèrent ou partagent la responsabilité du système CI/CD.

Cette mise en œuvre de référence utilise les outils suivants pour chaque composant :

  • Pour la gestion du code source : GitHub
    • Stocke l'application et le code de configuration.
    • Permet d'examiner les modifications.
  • Pour la gestion de la configuration de l'application : kustomize
    • Définit la configuration prévue d'une application.
    • Permet de réutiliser et d'étendre les primitives ou les plans de configuration.
  • Pour l'intégration continue : Cloud Build
    • Teste et valide le code source.
    • Crée des artefacts consommés par l'environnement de déploiement.
  • Pour la livraison continue : Cloud Deploy
    • Définit le processus de déploiement du code dans tous les environnements.
    • Fournit un rollback pour les modifications ayant échoué.
  • Pour la configuration de l'infrastructure : Config Sync
    • Applique systématiquement la configuration du cluster et des règles.
  • Pour l'application des règles : Policy Controller
    • Fournit un mécanisme que vous pouvez utiliser pour définir ce qui est autorisé à s'exécuter dans un environnement donné en fonction des règles de l'organisation.
  • Pour l'orchestration de conteneurs : Google Kubernetes Engine
    • Exécute les artefacts créés pendant l'Intégration continue (CI).
    • Fournit des méthodologies de scaling, de vérification d'état et de déploiement pour les charges de travail.
  • Pour les artefacts de conteneur : Artifact Registry
    • Stocke les artefacts (images de conteneurs) créés lors de l'intégration continue (CI).

Architecture

Cette section décrit les composants CI/CD que vous mettez en œuvre à l'aide de cette architecture de référence : infrastructure, pipeline, dépôts de code et zones de destination.

Pour une présentation générale de ces aspects du système CI/CD, consultez la page CI/CD modernes avec GKE : framework de livraison de logiciels.

Variantes de l'architecture de référence

L'architecture de référence comporte deux modèles de déploiement :

  • Variante multiprojet semblable à un déploiement de production avec des limites d'isolation améliorées
  • Variante à un seul projet, utile pour les démonstrations

Architecture de référence multiprojet

La version multi-project de l'architecture de référence simule des scénarios de production. Dans ces scénarios, différents personas créent une infrastructure, des pipelines CI/CD et des applications avec des limites d'isolation appropriées. Ces personas ou équipes ne peuvent accéder qu'aux ressources requises.

Pour en savoir plus, consultez la page CI/CD modernes avec GKE : framework de livraison de logiciels.

Pour savoir comment installer et appliquer cette version de l'architecture de référence, consultez le modèle de livraison de logiciels.

Architecture de référence à un seul projet

La version single-project de l'architecture de référence montre comment configurer l'intégralité de la plate-forme de livraison de logiciels dans un seul projet Google Cloud. Cette version peut aider les utilisateurs qui ne disposent pas de rôles IAM accordant un accès élevé à installer et à essayer l'architecture de référence en ayant uniquement le rôle de propriétaire sur un projet. Ce document présente la version de l'architecture de référence qui ne comporte qu'un seul projet.

Infrastructure de plate-forme

L'infrastructure de cette architecture de référence est constituée de clusters Kubernetes permettant de prendre en charge les environnements d'application de développement, de préproduction et de production. Le schéma suivant illustre la disposition logique des clusters :

La structure du cluster accepte différentes charges de travail de plate-forme.

Dépôts de code

Cette architecture de référence vous permet de configurer des dépôts pour les opérateurs, les développeurs, ainsi que pour les ingénieurs de plate-forme et de sécurité.

Le schéma suivant illustre la mise en œuvre d'une architecture de référence pour les différents dépôts de code et la manière dont les équipes chargées des opérations, du développement et de la sécurité interagissent avec les dépôts :

Les dépôts les incluent pour respecter les bonnes pratiques, ainsi que pour la configuration des applications et de la plate-forme.

Dans ce workflow, vos opérateurs peuvent gérer les bonnes pratiques de CI/CD et de configuration des applications dans le dépôt d'opérateurs. Lorsque les développeurs intègrent des applications dans le dépôt de développement, ils obtiennent automatiquement les bonnes pratiques, la logique métier de l'application, ainsi que toute configuration spécialisée nécessaire pour leur permettre de fonctionner correctement. Dans le même temps, votre équipe chargée des opérations et de la sécurité peut gérer la cohérence et la sécurité de la plate-forme dans les dépôts de configuration et de règles.

Zones de destination de l'application

Dans cette architecture de référence, la zone de destination d'une application est créée lors de son provisionnement. Dans le document suivant de cette série, CI/CD modernes avec GKE : appliquer le workflow de développement, vous provisionnez une nouvelle application qui crée sa propre zone de destination. Le schéma suivant illustre les principaux composants des zones de destination utilisées dans cette architecture de référence :

Le cluster GKE comprend trois espaces de noms pour différentes applications.

Chaque espace de noms inclut un compte de service qui permet à la fédération d'identité de charge de travail pour GKE d'accéder à des services, tels que Cloud Storage ou Cloud Spanner, en dehors du conteneur Kubernetes. L'espace de noms inclut également d'autres ressources telles que les règles de réseau permettant d'isoler ou de partager des limites avec d'autres espaces de noms ou applications.

L'espace de noms est créé par le compte de service d'exécution de CD. Nous recommandons aux équipes de suivre le principe du moindre privilège pour s'assurer qu'un compte de service d'exécution de CD ne peut accéder qu'aux espaces de noms requis.

Vous pouvez définir l'accès au compte de service dans Config Sync et le mettre en œuvre à l'aide des rôles RBAC (contrôle des accès basé sur le rôle) et des liaisons de rôles. Une fois ce modèle en place, les équipes peuvent déployer toutes les ressources directement dans les espaces de noms qu'elles gèrent, mais ne peuvent pas écraser ou supprimer des ressources d'autres espaces de noms.

Objectifs

  • Déployer l'architecture de référence à un seul projet
  • Explorer les dépôts de code
  • Explorer le pipeline et l'infrastructure

Coûts

Dans ce document, vous utilisez les composants facturables suivants de Google Cloud :

Obtenez une estimation des coûts en fonction de votre utilisation prévue à l'aide du simulateur de coût. Les nouveaux utilisateurs de Google Cloud peuvent bénéficier d'un essai gratuit.

Une fois que vous avez terminé les tâches décrites dans ce document, vous pouvez éviter de continuer à payer des frais en supprimant les ressources que vous avez créées. Pour en savoir plus, consultez la section Effectuer un nettoyage.

Avant de commencer

  1. Dans Google Cloud Console, sur la page de sélection du projet, sélectionnez ou créez un projet Google Cloud.

    Accéder au sélecteur de projet

  2. Vérifiez que la facturation est activée pour votre projet Google Cloud.

  3. Dans la console Google Cloud, activez Cloud Shell.

    Activer Cloud Shell

Déployer l'architecture de référence

  1. Dans Cloud Shell, définissez le projet :

    gcloud config set core/project PROJECT_ID

    Remplacez PROJECT_ID par l'ID de votre projet Google Cloud.

  2. Dans Cloud Shell, clonez le dépôt Git :

    git clone https://github.com/GoogleCloudPlatform/software-delivery-blueprint.git
cd software-delivery-blueprint/launch-scripts
git checkout single-project-blueprint

  3. Créez un jeton d'accès personnel dans GitHub avec les champs d'application suivants :

    • repo
    • delete_repo
    • admin:org
    • admin:repo_hook

  4. Un fichier vide nommé vars.sh figure dans le dossier software-delivery-bluprint/launch-scripts. Ajoutez le contenu suivant au fichier  : 

    cat << EOF >vars.sh
export INFRA_SETUP_REPO="gke-infrastructure-repo"
export APP_SETUP_REPO="application-factory-repo"
export GITHUB_USER=GITHUB_USER
export TOKEN=TOKEN
export GITHUB_ORG=GITHUB_ORG
export REGION="us-central1"
export SEC_REGION="us-west1"
export TRIGGER_TYPE="webhook"
EOF

    Remplacez GITHUB_USER par le nom d'utilisateur GitHub.

    Remplacez TOKEN par le jeton d'accès personnel GitHub.

    Remplacez GITHUB_ORG par le nom de l'organisation GitHub.

  5. Exécutez le script bootstrap.sh. Si Cloud Shell vous invite à donner votre autorisation, cliquez sur Autoriser :

    ./bootstrap.sh

    Le script amorce la plate-forme de livraison de logiciels.

Explorer les dépôts de code

Dans cette section, vous allez explorer les dépôts de code.

Se connecter à GitHub

  1. Dans un navigateur Web, accédez à github.com et connectez-vous à votre compte.
  2. Cliquez sur l'icône représentant une image en haut de l'interface.
  3. Cliquez sur Vos organisations.
  4. Choisissez l'organisation que vous avez fournie en entrée dans le fichier vars.sh.
  5. Cliquez sur l'onglet Dépôts.

Explorer les dépôts de démarrage, d'exploitation, de configuration et d'infrastructure

Les dépôts de démarrage, d'exploitation, de configuration et d'infrastructure permettent aux opérateurs et aux administrateurs de plate-forme de définir les bonnes pratiques courantes pour créer et exploiter la plate-forme. Ces dépôts sont créés dans votre organisation GitHub lors de l'amorçage de l'architecture de référence.

Chaque dépôt de la liste comprend une brève description.

Dépôts de démarrage

Les dépôts de démarrage facilitent l'adoption des bonnes pratiques de CI/CD, d'infrastructure et de développement sur la plate-forme. Pour en savoir plus, consultez la page CI/CD modernes avec GKE : framework de livraison de logiciels.

Dépôts de démarrage d'applications

Dans les dépôts de démarrage d'applications, vos opérateurs peuvent codifier et documenter les bonnes pratiques telles que l'intégration et la livraison continues, la collecte de métriques, la journalisation, les étapes de conteneur et la sécurité des applications. L'architecture de référence inclut des exemples de dépôts de démarrage pour les applications Go, Python et Java.

Les dépôts de démarrage d'applications app-template-python, app-template-java et app-template-golang contiennent du code récurrent que vous pouvez utiliser pour créer des applications. En plus de créer des applications, vous pouvez créer des modèles en fonction des exigences de l'application. Les dépôts de démarrage d'applications fournis par l'architecture de référence contiennent les éléments suivants :

  • Base kustomize et correctifs dans le dossier k8s

  • Code source de l'application

  • Un fichier Dockerfile décrivant comment créer et exécuter l'application

  • Un fichier cloudbuild.yaml décrivant les bonnes pratiques pour les étapes d'intégration continue

  • Un fichier skaffold.yaml décrivant la procédure de déploiement

Dans le document suivant de cette série, CI/CD modernes avec GKE : appliquer le workflow de développement, vous utilisez le dépôt app-template-python pour créer une application.

Dépôts de démarrage de l'infrastructure

Dans les dépôts de démarrage de l'infrastructure, les opérateurs et les administrateurs d'infrastructure peuvent codifier et documenter les bonnes pratiques telles que les pipelines CI/CD, l'IaC, la collecte de métriques, la journalisation et la sécurité de l'infrastructure. L'architecture de référence inclut des exemples de dépôts de démarrage d'infrastructure utilisant Terraform. Le dépôt de démarrage de l'infrastructure infra-template contient du code récurrent pour Terraform que vous pouvez utiliser pour créer les ressources d'infrastructure requises par une application, comme un bucket Cloud Storage ou une base de données Spanner.

Dépôts de modèles partagés

Dans les dépôts de modèles partagés, les administrateurs et les opérateurs d'infrastructure fournissent des modèles standards pour effectuer des tâches. Un dépôt nommé terraform-modules est fourni avec l'architecture de référence. Le dépôt comprend un modèle de code Terraform pour créer différentes ressources d'infrastructure.

Dépôts d'opérateurs

Dans l'architecture de référence, les dépôts d'exploitation sont identiques aux dépôts de démarrage d'applications. Les opérateurs gèrent les fichiers requis pour l'intégration et la livraison continues dans les dépôts de démarrage d'applications. L'architecture de référence inclut les dépôts app-template-python, app-template-java et app-template-golang.

  • Il s'agit de modèles de démarrage qui contiennent les fichiers manifestes Kubernetes de base pour les applications exécutées dans Kubernetes sur la plate-forme. Les opérateurs peuvent mettre à jour les fichiers manifestes dans les modèles de démarrage si nécessaire. Les mises à jour sont prises en compte lors de la création d'une application.
  • Les fichiers cloudbuild.yaml et skaffold.yaml de ces dépôts stockent respectivement les bonnes pratiques concernant l'exécution de l'intégration et de la livraison continues sur la plate-forme. De façon semblable aux configurations d'applications, les opérateurs peuvent mettre à jour et ajouter des étapes aux bonnes pratiques. Les pipelines d'application individuels sont créés à l'aide des dernières étapes.

Dans cette implémentation de référence, les opérateurs utilisent kustomize pour gérer les configurations de base dans le dossier k8s des dépôts de démarrage. Les développeurs sont ensuite libres d'étendre les fichiers manifestes avec des modifications spécifiques à l'application, telles que les noms de ressources et les fichiers de configuration. L'outil kustomize accepte la configuration en tant que données. Avec cette méthodologie, les entrées et les sorties kustomize sont des ressources Kubernetes. Vous pouvez utiliser les résultats d'une modification des fichiers manifestes pour une autre modification.

Le schéma suivant illustre une configuration de base pour une application Spring Boot :

La configuration d'une application est effectuée dans plusieurs dépôts gérés par des équipes distinctes.

La configuration en tant que modèle de données dans kustomize présente un avantage majeur : lorsque les opérateurs mettent à jour la configuration de base, les mises à jour sont automatiquement utilisées par le pipeline de déploiement du développeur lors de sa prochaine exécution, sans aucune modification de la part du développeur.

Pour plus d'informations sur l'utilisation de kustomize pour gérer les fichiers manifestes Kubernetes, consultez la Documentation kustomize.

Dépôts de configuration et de règles

L'architecture de référence inclut une mise en œuvre d'un dépôt de configuration et de règles qui utilise Config Sync et Policy Controller. Le dépôt acm-gke-infrastructure-repo contient la configuration et les règles que vous déployez sur les clusters de l'environnement de l'application. La configuration définie et stockée par les administrateurs de la plate-forme dans ces dépôts est importante, car elle permet de garantir un ressenti et une apparence cohérents pour les équipes chargées des opérations et du développement.

Les sections suivantes décrivent plus en détail comment l'architecture de référence met en œuvre les dépôts de configuration et de règles.

Configuration

Dans cette implémentation de référence, vous utilisez Config Sync pour gérer la configuration des clusters dans la plate-forme et appliquer des règles de manière centralisée. La gestion centralisée vous permet de propager les modifications de configuration dans l'ensemble du système.

À l'aide de Config Sync, votre organisation peut enregistrer ses clusters pour synchroniser leur configuration à partir d'un dépôt Git. Ce processus est connu sous le nom de GitOps. Lorsque vous ajoutez des clusters, ils se synchronisent automatiquement avec la dernière configuration et font en permanence le rapprochement de l'état du cluster avec la configuration si quelqu'un introduit des modifications hors bande.

Pour en savoir plus sur Config Sync, consultez la documentation associée.

Règle

Dans cette mise en œuvre de référence, vous utilisez Policy Controller, qui est basé sur Open Policy Agent, pour intercepter et valider chaque requête auprès des clusters Kubernetes dans la plate-forme. Vous pouvez créer des règles à l'aide du langage de règle Rego, ce qui vous permet de contrôler entièrement non seulement les types de ressources envoyés au cluster, mais également leur configuration.

Dans le schéma suivant, l'architecture illustre un flux de requête permettant de créer une ressource à l'aide de Policy Controller :

Une règle est définie, puis appliquée à l'aide de divers outils tels que kubectl et les clients API.

Vous créez et définissez des règles dans le dépôt Config Sync, et ces modifications sont appliquées au cluster. Ensuite, les nouvelles demandes de ressources de la CLI ou des clients API sont validées en fonction des contraintes imposées par Policy Controller.

Pour en savoir plus sur la gestion des règles, consultez la présentation de Policy Controller.

Dépôts d'infrastructure

L'architecture de référence inclut l'implémentation du dépôt d'infrastructure à l'aide de Terraform. Le dépôt gke-infrastructure-repo contient une infrastructure en tant que code permettant de créer des clusters GKE pour les environnements de développement, de préproduction et de production, et de configurer Config Sync sur ceux-ci à l'aide du dépôt acm-gke-infrastructure-repo. gke-infrastructure-repo contient trois branches, une pour chaque environnement de développement, de préproduction et de production. Il contient également des dossiers de développement, de préproduction et de production sur chaque branche.

Explorer le pipeline et l'infrastructure

L'architecture de référence crée un pipeline dans le projet Google Cloud. Ce pipeline est chargé de créer l'infrastructure partagée.

Pipeline

Dans cette section, vous allez explorer le pipeline Infrastructure as Code et l'exécuter pour créer l'infrastructure partagée, y compris les clusters GKE. Le pipeline est un déclencheur Cloud Build nommé create-infra dans le projet Google Cloud qui est associé au dépôt d'infrastructure gke-infrastructure-repo. Vous suivez la méthodologie GitOps pour créer une infrastructure, comme expliqué dans la vidéo sur les environnements GCP reproductibles à grande échelle avec des pipelines Infrastructure as Code Cloud Build.

gke-infrastructure-repo comporte des branches de développement, de préproduction et de production. Le dépôt contient également des dossiers de développement, de préproduction et de production correspondant à ces branches. Des règles de protection des branches permettent de s'assurer que le code ne peut être transmis qu'à la branche de développement. Pour transmettre le code aux branches de préproduction et de production, vous devez créer une demande d'extraction.

Généralement, une personne ayant accès au dépôt examine les modifications, puis fusionne la demande d'extraction pour s'assurer que seules les modifications prévues sont promues vers la branche supérieure. Pour permettre aux utilisateurs de tester le modèle, les règles de protection des branches ont été assouplies dans l'architecture de référence afin que l'administrateur du dépôt puisse contourner l'examen et fusionner la demande d'extraction.

Lorsqu'un transfert est effectué sur gke-infrastructure-repo, il appelle le déclencheur create-infra. Ce déclencheur identifie la branche où le transfert s'est produit et accède au dossier correspondant dans le dépôt de cette branche. Une fois qu'il a trouvé le dossier correspondant, il exécute Terraform à l'aide des fichiers contenus dans ce dossier. Par exemple, si le code est transmis à la branche de développement, le déclencheur exécute Terraform dans le dossier de développement de la branche de développement pour créer un cluster de développement GKE. De même, lorsqu'un transfert est effectué dans la branche staging, le déclencheur exécute Terraform dans le dossier de préproduction de la branche de préproduction pour créer un cluster de préproduction GKE.

Exécutez le pipeline pour créer des clusters GKE :

  1. Dans la console Google Cloud, accédez à la page Cloud Build.

    Accéder à la page Cloud Build

    • Il existe cinq déclencheurs de webhook Cloud Build. Recherchez le déclencheur nommé create-infra. Ce déclencheur crée l'infrastructure partagée, y compris les clusters GKE.

  2. Cliquez sur le nom du déclencheur. La définition du déclencheur s'affiche.

  3. Cliquez sur OUVRIR L'ÉDITEUR pour afficher les étapes exécutées par le déclencheur.

    Les autres déclencheurs sont utilisés lorsque vous intégrez une application dans CI/CD modernes avec GKE : appliquer le workflow de développement.

    Déclencheurs Cloud Build

  4. Dans la console Google Cloud, accédez à la page Cloud Build.

    Accéder à la page "Historique" de Cloud Build

    Examinez le pipeline présent sur la page "Historique". Lorsque vous avez déployé la plate-forme de livraison de logiciels à l'aide de bootstrap.sh, le script a transféré le code vers la branche de développement du dépôt gke-infrastructure-repo, qui a lancé ce pipeline et créé le cluster de développement GKE.

  5. Pour créer un cluster de préproduction GKE, envoyez une demande d'extraction de la branche de développement à la branche de préproduction :

    1. Accédez à GitHub et au dépôt gke-infrastructure-repo.

    2. Cliquez sur Demandes d'extraction, puis sur Nouvelle demande d'extraction.

    3. Sélectionnez préproduction dans le menu Base et développement dans le menu Comparer.

    4. Cliquez sur Create pull request (Créer une demande de fusion).

  6. Si vous êtes administrateur du dépôt, fusionnez la demande d'extraction. Sinon, demandez à l'administrateur de s'en charger.

  7. Dans la console Google Cloud, accédez à la page Historique de Cloud Build.

    Accéder à la page "Historique" de Cloud Build

    Un deuxième pipeline Cloud Build démarre dans le projet. Ce pipeline crée le cluster de préproduction GKE.

  8. Pour créer des clusters de production GKE, envoyez une demande pull request de la branche de préproduction à la branche de production :

    1. Accédez à GitHub et au dépôt gke-infrastructure-repo.

    2. Cliquez sur Demandes d'extraction, puis sur Nouvelle demande d'extraction.

    3. Sélectionnez production dans le menu Base et préproduction dans le menu Comparer.

    4. Cliquez sur Create pull request (Créer une demande de fusion).

  9. Si vous êtes administrateur du dépôt, fusionnez la demande d'extraction. Sinon, demandez à l'administrateur de s'en charger.

  10. Dans la console Google Cloud, accédez à la page Historique de Cloud Build.

    Accéder à la page "Historique" de Cloud Build

    Un troisième pipeline Cloud Build démarre dans le projet. Ce pipeline crée le cluster de production GKE.

Créer l'infrastructure

Dans cette section, vous allez explorer l'infrastructure créée par les pipelines.

  • Dans Cloud Console, accédez à la page des clusters Kubernetes.

    Accéder à la page des clusters Kubernetes

    Cette page répertorie les clusters utilisés pour le développement (gke-dev-us-central1), la préproduction (gke-staging-us-central1) et la production (gke-prod-us-central1, gke-prod-us-west1) :

    Les détails des clusters incluent l'emplacement, la taille du cluster et le nombre total de cœurs.

Cluster de développement

Le cluster de développement (gke-dev-us-central1) permet à vos développeurs d'accéder à un espace de noms qu'ils peuvent utiliser pour effectuer des itérations sur leurs applications. Nous recommandons aux équipes d'utiliser des outils tels que Skaffold, qui fournissent un workflow itératif en surveillant activement le code en cours de développement et en l'appliquant à nouveau sur les environnements de développement à mesure que des modifications sont apportées. Cette boucle d'itération est semblable au hot reloading. Cependant, au lieu d'être spécifique à un langage, la boucle fonctionne avec n'importe quelle application que vous pouvez créer avec une image Docker. Vous pouvez exécuter la boucle dans un cluster Kubernetes.

Les développeurs peuvent également suivre la boucle CI/CD pour un environnement de développement. Cette boucle prépare les modifications de code à promouvoir dans des environnements en amont.

Dans le document suivant de cette série, CI/CD modernes avec GKE : appliquer le workflow de développement, vous utilisez Skaffold ainsi que l'intégration et la livraison continues pour créer la boucle de développement.

Cluster de préproduction

Ce cluster exécute l'environnement de préproduction de vos applications. Dans cette architecture de référence, vous créez un cluster GKE pour la préproduction. En règle générale, un environnement de préproduction est une réplique exacte de l'environnement de production.

Cluster de production

Dans l'architecture de référence, vous disposez de deux clusters GKE pour vos environnements de production. Pour les systèmes de géoredondance ou à haute disponibilité, nous vous recommandons d'ajouter plusieurs clusters à chaque environnement. Pour tous les clusters dans lesquels les applications sont déployées, il est préférable d'utiliser des clusters régionaux. Cette approche isole vos applications des défaillances au niveau de la zone et de toute interruption due à des mises à niveau de cluster ou de pool de nœuds.

Pour synchroniser la configuration des ressources de cluster, telles que les espaces de noms, les quotas et les stratégies RBAC, nous vous recommandons d'utiliser Config Sync. Pour en savoir plus sur la gestion de ces ressources, consultez la page Dépôts de configuration et de règles.

Appliquer l'architecture de référence

Maintenant que vous avez exploré l'architecture de référence, vous pouvez explorer un workflow de développeur basé sur cette mise en œuvre. Dans le document suivant de cette série, CI/CD modernes avec GKE : appliquer le workflow de développement, vous allez créer une application, ajouter une caractéristique, puis déployer l'application dans les environnements de préproduction et de production.

Effectuer un nettoyage

Si vous souhaitez poursuivre avec le prochain document de cette série, CI/CD modernes avec GKE : appliquer le workflow de développement, ne supprimez pas le projet ni les ressources associés à cette architecture de référence. Autrement, pour éviter que les ressources utilisées dans l'architecture de référence ne soient facturées sur votre compte Google Cloud, vous pouvez supprimer le projet ou supprimer les ressources manuellement.

Supprimer le projet

  1. Dans la console Google Cloud, accédez à la page Gérer les ressources.

    Accéder à la page Gérer les ressources

  2. Dans la liste des projets, sélectionnez le projet que vous souhaitez supprimer, puis cliquez sur Supprimer.
  3. Dans la boîte de dialogue, saisissez l'ID du projet, puis cliquez sur Arrêter pour supprimer le projet.

Supprimer manuellement les ressources

  • Dans Cloud Shell, supprimez l'infrastructure :

      gcloud container clusters delete gke-dev-us-central1
  gcloud container clusters delete gke-staging-us-central1
  gcloud container clusters delete gke-prod-us-central1
  gcloud container clusters delete gke-prod-us-west1
  gcloud beta builds triggers delete create-infra
  gcloud beta builds triggers delete add-team-files
  gcloud beta builds triggers delete create-app
  gcloud beta builds triggers delete tf-plan
  gcloud beta builds triggers delete tf-apply

Étapes suivantes