Utiliser Config Sync dans plusieurs environnements

Ce tutoriel explique comment configurer Config Sync pour Google Kubernetes Engine (GKE) dans deux environnements, un pour le développement et un pour la production, en suivant les bonnes pratiques pour Anthos Config Management.

Dans ce scénario, vous faites partie d'une équipe d'administration de plateforme de Foo Corp. Les applications de Foo Corp sont déployées sur GKE, avec des ressources réparties sur deux projets, dev et prod. Le projet dev contient un cluster GKE de développement et le projet prod contient le cluster GKE de production. En tant qu'administrateur de plateforme, votre objectif est de vous assurer que les deux environnements respectent les règles de Foo Corp. et que les ressources de base, telles que les espaces de noms Kubernetes et les comptes de service, restent cohérentes dans les deux environnements.

Le schéma suivant présente les environnements que vous allez configurer dans le présent tutoriel :

Présentation des environnements que vous allez configurer dans ce tutoriel.

Comme illustré dans le schéma précédent, vous allez créer les ressources suivantes dans le cadre du présent tutoriel :

  • Deux projets Google Cloud représentant les environnements de développement et de production.
  • Deux clusters GKE, dev et prod, dans des projets distincts.
  • Trois dépôts GitHub, foo-config-source, foo-config-dev et foo-config-prod. Il s'agit de dépôts non structurés Config Sync contenant des configurations YAML pour Foo Corp.
  • Config Sync installé sur les deux clusters. Le cluster dev est synchronisé avec le dépôt foo-config-dev, et le cluster prod est synchronisé avec le dépôt foo-config-prod.
  • Secret Manager avec votre nom d'utilisateur Git et un jeton de développeur. Cloud Build utilise ces secrets pour valider les dépôts GitHub.
  • Un pipeline Cloud Build, transféré vers le dépôt foo-config-source Ce pipeline utilise kustomize build pour effectuer le rendu personnalisé de dépôts foo-config-dev et foo-config-prod avec des configurations YAML, en utilisant les paramètres "Base" et "overlays" dans foo-config-source. Ces superpositions Kustomize vous sont fournies dans le dossier config-source/.

Objectifs

  • Préparer votre environnement en exécutant des scripts pour créer et configurer les clusters et les dépôts que vous utiliserez avec Config Sync.
  • Créer un déclencheur Cloud Build permettant d'afficher automatiquement la configuration de deux environnements différents à l'aide de Kustomize
  • Configurer Config Sync pour synchroniser la configuration de rendu pour les deux environnements distincts.

Coûts

Ce tutoriel utilise 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é ce tutoriel, vous pouvez éviter de continuer à payer des frais en supprimant les ressources que vous avez créées. Consultez la page Effectuer un nettoyage pour en savoir plus.

Les nouveaux utilisateurs de Google Cloud peuvent bénéficier d'un essai gratuit.

Avant de commencer

Avant de commencer ce tutoriel, assurez-vous d'avoir effectué les étapes suivantes :

  1. Dans Google Cloud Console, sur la page de sélection du projet, choisissez ou créez deux projets Google Cloud.

    Accéder au sélecteur de projet

  2. Assurez-vous que la facturation est activée pour votre projet Cloud. Découvrez comment vérifier que la facturation est activée pour votre projet.

  3. Créer un compte GitHub ou y avoir accès

  4. Dans GitHub, créez un jeton d'accès personnel avec les champs d'application repo et delete_repo. Copiez la valeur du jeton dans votre presse-papiers. Vous en aurez besoin pour les prochaines étapes.

Préparer l'environnement

Afin de préparer votre environnement pour ce tutoriel, procédez comme suit :

  1. Ouvrez Cloud Shell.

    1. Accédez à Google Cloud Console.

      Google Cloud Console

    2. Dans l'angle supérieur droit de la console, cliquez sur le bouton Activer Cloud Shell :

    Les outils nomos et kubectl dont vous avez besoin pour suivre ce tutoriel sont préinstallés avec Cloud Shell.

  2. Clonez l'exemple de dépôt Anthos Config Management :

    git clone https://github.com/GoogleCloudPlatform/anthos-config-management-samples.git
    
  3. Accédez au dossier contenant les ressources dont vous avez besoin pour ce tutoriel :

    cd anthos-config-management-samples/multi-environments-kustomize/
    
  4. Pour exécuter les scripts utilisés dans ce tutoriel, définissez les variables suivantes :

    export DEV_PROJECT="DEV_PROJECT_ID"
    export PROD_PROJECT="PROD_PROJECT_ID"
    export DEV_CLUSTER_ZONE="DEV_CLUSTER_ZONE"
    export PROD_CLUSTER_ZONE="PROD_CLUSTER_ZONE"
    export GITHUB_USERNAME="GITHUB_USERNAME"
    export GITHUB_TOKEN="GITHUB_TOKEN"
    export GITHUB_EMAIL="GITHUB_EMAIL"
    

    Remplacez les éléments suivants :

    • DEV_PROJECT_ID : ID du projet Google Cloud que vous souhaitez utiliser comme projet de développement.
    • PROD_PROJECT_ID : ID du projet Google Cloud que vous souhaitez utiliser comme projet de production.
    • DEV_CLUSTER_ZONE : zone Compute Engine dans laquelle vous souhaitez créer votre cluster de développement. Exemple : us-central1-c.
    • PROD_CLUSTER_ZONE : zone Compute Engine dans laquelle vous souhaitez créer votre cluster de production.
    • GITHUB_USERNAME : votre nom d'utilisateur GitHub.
    • GITHUB_TOKEN : jeton d'accès personnel que vous avez créé dans la section Avant de commencer.
    • GITHUB_EMAIL : votre adresse e-mail GitHub.
  5. Configurez votre environnement Git local de sorte à utiliser votre nom d'utilisateur et votre adresse e-mail GitHub :

    git config --global user.name $GITHUB_USERNAME
    git config --global user.email $GITHUB_EMAIL
    git config --global credential.helper store
    git config --global credential.helper cache
    

Créer vos ressources

Pour vous permettre de vous concentrer sur le workflow à utiliser lorsque vous configurez Config Sync pour plusieurs environnements, le répertoire multi-environments-kustomize contient des scripts que vous pouvez utiliser pour automatiser la configuration de Config Sync.

Créer et enregistrer vos clusters

  1. Pour créer deux clusters, exécutez le script ./1-create-clusters.sh :

    ./1-create-clusters.sh
    

    Ce script crée un cluster GKE nommé dev dans le projet de développement et un cluster GKE nommé prod dans le projet de production. Ce script active également les API GKE et Anthos et se connecte à vos clusters dev et prod afin que vous puissiez accéder à leurs API avec kubectl.

    Exemple de résultat :

    kubeconfig entry generated for dev.
    Fetching cluster endpoint and auth data.
    kubeconfig entry generated for prod.
    ⭐️ Done creating clusters.
    
  2. Pour enregistrer vos clusters dans deux flottes Anthos distinctes, exécutez le script register-clusters.sh :

    ./2-register-clusters.sh
    

    Ce script crée un compte de service Google Cloud et une clé pour l'enregistrement du cluster Anthos, puis utilise la commande gcloud container hub memberships register pour enregistrer les clusters dev et prod dans Anthos, dans leurs projets respectifs.

    Exemple de résultat :

    Waiting for Feature Config Management to be created...done.
    ⭐️ Done registering clusters.
    

Créer vos dépôts GitHub

  1. Pour créer trois dépôts GitHub, exécutez le script create-repos.sh :

    ./3-create-repos.sh
    

    Ce script crée trois dépôts GitHub : foo-config-source, foo-config-dev et foo-config-prod. Les utilisateurs valident la configuration dans le dépôt source, après quoi un pipeline CI (que vous créerez dans les prochaines étapes) effectue le rendu des configurations dans les deux autres dépôts en utilisant les valeurs correspondantes de dev et prod. Ensuite, le cluster dev est synchronisé à partir de foo-config-dev, et le cluster prod est synchronisé à partir de foo-config-prod.

    Exemple de résultat :

    # Output omitted
    😸 Creating foo-config-prod repo...
    {
      "id": 364312792,
      "node_id": "MDEwOlJlcG9zaXRvcnkzNjQzMTI3OTI=",
      "name": "foo-config-prod",
     ...
    }
    Cloning into 'foo-config-prod'...
    warning: You appear to have cloned an empty repository.
    [main (root-commit) b681a3d] Initialize
     1 file changed, 0 insertions(+), 0 deletions(-)
     create mode 100644 README.md
    Enumerating objects: 3, done.
    Counting objects: 100% (3/3), done.
    Writing objects: 100% (3/3), 211 bytes | 211.00 KiB/s, done.
    Total 3 (delta 0), reused 0 (delta 0), pack-reused 0
    To https://github.com/askmeegs/foo-config-prod.git
    * [new branch]      main -> main
    

Créer vos secrets

  1. Pour créer des secrets Secret Manager dans le projet de production avec vos identifiants Git, exécutez le script secret-manager-git.sh :

    ./4-secret-manager-git.sh
    

    Le fait de créer vos secrets de cette manière permet à Cloud Build d'envoyer des requêtes à GitHub en votre nom. Le pipeline Cloud Build que vous allez configurer par la suite obtient vos informations d'authentification GitHub directement depuis Secret Manager.

    Résultat attendu :

    🔐 Creating secret manager secrets in prod project...
    Created secret [github-username].
    Created version [1] of the secret [github-username].
    Created secret [github-email].
    Created version [1] of the secret [github-email].
    Created secret [github-token].
    Created version [1] of the secret [github-token].
    ✅ Granting Cloud Build secret manager access...
    Project number is: ########
    Updated IAM policy for project [project-id].
    # Output omitted
    

Créer un déclencheur Cloud Build

Maintenant que vous avez configuré votre environnement, vous pouvez explorer votre pipeline Cloud Build.

Pour afficher le pipeline Cloud Build, exécutez la commande suivante :

cat foo-config-source/cloudbuild.yaml

Ce pipeline utilise Kustomize pour afficher les fichiers manifestes des dépôts de développement et de production en utilisant les manifestes présents dans le répertoire base/.

Résultat attendu :

steps:
- name: 'gcr.io/google-samples/cloudbuild-kustomize:latest'
  id: Render foo-config-dev
  entrypoint: 'bash'
  args:
  - '-eEuo'
  - 'pipefail'
  - '-c'
  - |-
    git clone https://github.com/$$GITHUB_USERNAME/foo-config-dev && \
    cd foo-config-dev
    git config user.email $$GITHUB_EMAIL
    git config user.name $$GITHUB_USERNAME
    git remote set-url origin https://$$GITHUB_USERNAME:$$GITHUB_TOKEN@github.com/$$GITHUB_USERNAME/foo-config-dev.git
    cd ..

    kustomize build overlays/dev --output foo-config-dev/
    cd foo-config-dev

    rm README.md
    echo "Update: ${SHORT_SHA}" > README.md

    git add . && \
    git commit -m "Rendered: ${SHORT_SHA}
    Built from commit ${COMMIT_SHA} of repository foo-config-source - main branch
    Author: $(git log --format='%an <%ae>' -n 1 HEAD)" && \
    git push origin main
  secretEnv: ['GITHUB_EMAIL', 'GITHUB_USERNAME', 'GITHUB_TOKEN']
- name: 'gcr.io/google-samples/cloudbuild-kustomize:latest'
  id: Render foo-config-prod
...

Si vous accédez à votre dépôt foo-config-source/ dans GitHub, vous pouvez afficher les fichiers manifestes base/ et les superpositions Kustomize dev/ et prod/ utilisées par ce pipeline.

Chaque répertoire de ce dépôt contient un fichier kustomization.yaml qui répertorie les fichiers que Kustomize doit gérer et appliquer au cluster. Une série de correctifs est définie dans dev/kustomization.yaml et prod/kustomization.yaml. Ces correctifs manipulent les ressources base/ pour cet environnement spécifique.

Par exemple, l'objet RoleBinding dans le dépôt foo-config-dev permet à tous les développeurs de Foo Corp de déployer des pods sur le cluster de développement, tandis que le RoleBinding dans le dépôt foo- config-prod permet uniquement à un agent de déploiement continu, deploy-bot@foo-corp.com, de déployer des pods en production :

apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization
bases:
- ../../base
patches:
# ServiceAccount - make name unique per environ
- target:
    kind: ServiceAccount
    name: foo-ksa
  patch: |-
    - op: replace
      path: /metadata/name
      value: foo-ksa-dev
    - op: replace
      path: /metadata/namespace
      value: foo-dev
# Pod creators - give all Foo Corp developers access
- target:
    kind: RoleBinding
    name: pod-creators
  patch: |-
    - op: replace
      path: /subjects/0/name
      value: developers-all@foo-corp.com
commonLabels:
  environment: dev

Créer votre déclencheur

Dans cette section, vous allez créer un déclencheur Cloud Build qui lance automatiquement une compilation chaque fois que vous apportez des modifications à votre code source :

  1. En utilisant votre projet de production dans Google Cloud Console, accédez à la page des déclencheurs Cloud Build :

    Ouvrez les déclencheurs

  2. Cliquez sur Connecter des dépôts.

  3. Dans la fenêtre des dépôts Connect, procédez comme suit :

    1. Dans le champ Select source (Sélectionner une source), laissez GitHub sélectionné, puis cliquez sur Continue (Continuer).
    2. Dans le champ Compte GitHub, assurez-vous que la valeur GITHUB_USERNAME que vous avez définie précédemment est bien sélectionnée.
    3. Dans la liste déroulante Dépôt, sélectionnez le dépôt foo-config-source, puis cliquez sur OK.
    4. Cochez la case pour accepter les conditions d'utilisation.
    5. Cliquez sur Se connecter.
  4. Une fois votre dépôt connecté, cliquez sur Créer un déclencheur.

  5. Sur la page Créer un déclencheur qui s'affiche, remplissez les champs suivants :

    1. Dans le champ Nom, ajoutez : Foo-Config-Render.
    2. Configurez les champs Description et Tags selon vos besoins. Ces champs ne sont pas requis pour ce tutoriel.
    3. Dans le champ Événement, laissez l'option Déployer sur une branche sélectionnée.
    4. Dans la liste déroulante Dépôt, sélectionnez foo-config-source.
    5. Laissez le champ Branche sur ^main$.
    6. Dans le champ Type, laissez l'option Détection automatique sélectionnée.
    7. Dans le champ Emplacement, laissez l'option Dépôt sélectionné.
    8. Cliquez sur Créer pour revenir à la page de présentation des déclencheurs.

Exécuter votre déclencheur

Comme vous avez déjà transféré le dépôt foo-config-source avant de créer ce déclencheur, vous pouvez l'exécuter manuellement pour déclencher le rendu des dépôts de développement et de production :

  1. Dans la liste des déclencheurs, sur la ligne Foo-Config-Render, cliquez sur Exécuter. La fenêtre Exécuter le déclencheur s'affiche.
  2. Dans la fenêtre Exécuter le déclencheur, assurez-vous que le champ de la branche est bien défini sur main, puis cliquez sur Exécuter le déclencheur.
  3. Un message Compilation démarrée sur la branche principale s'affiche. Cliquez sur Afficher sur ce message pour afficher la page Informations sur la compilation.

    La compilation doit s'exécuter correctement et la sortie de compilation Kustomize doit être inscrite dans les dépôts foo-config-dev et foo-config-prod, respectivement.

  4. Une fois la compilation terminée, ouvrez l'un de vos dépôts (développement ou production) dans GitHub. Vous devriez voir des fichiers YAML dans le dépôt ainsi qu'une mise à jour du README indiquant le SHA de commit du dépôt foo-config-source à partir duquel ce dépôt a été compilé pour la dernière fois.

Configurer Config Sync

Maintenant que vous avez ajouté des configurations à vos dépôts, vous pouvez installer Config Sync et vérifier l'installation.

Installer Config Sync

Pour installer Config Sync, exécutez le script install-config-sync.sh sur les clusters de développement et de production :

./5-install-config-sync.sh

Résultat attendu :

😺 Populating configmangement.yaml with your GitHub repo info...
🔁 Installing ConfigSync on the dev cluster...
Updated property [core/project].
Switched to context "DEV_CLUSTER".
Waiting for Feature Config Management to be updated...done.
🔁 Installing ConfigSync on the prod cluster...
Updated property [core/project].
Switched to context "PROD_CLUSTER".
Waiting for Feature Config Management to be updated...done.

Config Sync est maintenant synchronisé avec les configurations de vos dépôts.

Vérifiez votre configuration.

Dans cette section, vous allez vérifier que vos clusters se synchronisent bien avec les configurations de votre dépôt :

  1. Pour vérifier l'état de l'installation de Config Sync, exécutez la commande nomos status :

    nomos status
    

    Vous devriez constater que vos clusters de développement et de production sont maintenant synchronisés avec leurs dépôts respectifs :

    gke_DEV_PROJECT_ID_us-central1-c_dev
      --------------------
      <root>   https:/github.com/GITHUB_USERNAME/foo-config-dev@main
      SYNCED   8f2e196f
      Managed resources:
         NAMESPACE   NAME                                                 STATUS
                     clusterrole.rbac.authorization.k8s.io/pod-creator    Current
                     namespace/default                                    Current
                     namespace/foo                                        Current
         default     rolebinding.rbac.authorization.k8s.io/pod-creators   Current
         foo         serviceaccount/foo-ksa-dev                           Current
    
    *gke_PROD_PROJECT_ID_us-central1-c_prod
       --------------------
       <root>   https:/github.com/GITHUB_USERNAME/foo-config-prod@main
       SYNCED   c91502ee
       Managed resources:
          NAMESPACE   NAME                                                 STATUS
                      clusterrole.rbac.authorization.k8s.io/pod-creator    Current
                      namespace/default                                    Current
                      namespace/foo                                        Current
          default     rolebinding.rbac.authorization.k8s.io/pod-creators   Current
          foo         serviceaccount/foo-ksa-prod                          Current
    
      ```
    
  2. Utilisez kubectl pour basculer vers le cluster de développement :

    kubectl config use-context "gke_${DEV_PROJECT}_${DEV_CLUSTER_ZONE}_dev"
    
  3. Pour vérifier que les ressources sont synchronisées, obtenez les espaces de noms. L'espace de noms foo doit s'afficher, synchronisé à partir du dépôt foo-config-dev.

    kubectl get namespace
    

    Exemple de résultat :

    NAME                           STATUS   AGE
    config-management-monitoring   Active   9m38s
    config-management-system       Active   9m38s
    default                        Active   47h
    foo                            Active   9m5s
    kube-node-lease                Active   47h
    kube-public                    Active   47h
    kube-system                    Active   47h
    resource-group-system          Active   9m30s
    

    Vous avez maintenant configuré le rendu automatisé de la configuration pour des environnements de développement et de production, dans plusieurs projets et environnements Google Cloud.

Nettoyer

Pour éviter que les ressources utilisées lors de ce tutoriel soient facturées sur votre compte Google Cloud, supprimez le projet contenant les ressources, ou conservez le projet et les ressources individuelles.

Supprimer toutes les ressources

Pour supprimer les ressources que vous avez créées dans le cadre de ce tutoriel, tout en conservant intacts les projets de développement et de production, exécutez le script de nettoyage :

./cleanup.sh

Supprimer les projets

  1. Dans Cloud Console, 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.

Étape suivante