Utilizzo di Config Sync in più ambienti con Cloud Build

Questo tutorial mostra come configurare Config Sync per Google Kubernetes Engine (GKE) in due ambienti, uno per lo sviluppo e l'altro per la produzione, utilizzando le best practice per Anthos Config Management.

In questo scenario, fai parte del team di amministrazione della piattaforma di Foo Corp. Le applicazioni Foo Corp vengono sottoposte a deployment in GKE, con le risorse suddivise in due progetti, dev e prod. Il progetto dev contiene un cluster GKE di sviluppo, mentre il progetto prod contiene il cluster GKE di produzione. Il tuo obiettivo come amministratore della piattaforma è garantire che entrambi gli ambienti rispettino i criteri di Foo Corp's e che le risorse di livello base, come gli spazi dei nomi e gli account di servizio di Kubernetes, rimangano coerenti in entrambi.

Il seguente diagramma mostra una panoramica degli ambienti che hai configurato in questo tutorial:

Panoramica degli ambienti che hai configurato in questo tutorial.

Come mostrato nel diagramma precedente, in questo tutorial creerai le seguenti risorse:

  • Due progetti Google Cloud che rappresentano gli ambienti di sviluppo e produzione.
  • Due cluster GKE, dev e prod, nei progetti separati.
  • Tre repository GitHub, foo-config-source, foo-config-dev e foo-config-prod. Si tratta di repository non strutturati di Config Sync che contengono configurazioni YAML per Foo Corp.
  • Config Sync è installato su entrambi i cluster. Il cluster dev è sincronizzato con il repository foo-config-dev, il cluster prod è sincronizzato con il repository foo-config-prod.
  • Secret di Secret Manager con il tuo nome utente Git e un token sviluppatore. Cloud Build utilizza questi secret per effettuare il commit nei repository GitHub.
  • Una pipeline di Cloud Build, di cui è stato eseguito il push, al repository foo-config-source. Questa pipeline utilizza kustomize build per visualizzare repository personalizzati foo-config-dev e foo-config-prod con configurazioni YAML, utilizzando gli elementi "Base" e "overlay" in foo-config-source. Questi overlay Kustomize ti sono stati forniti nella cartella config-source/.

Obiettivi

  • Prepara l'ambiente eseguendo script per creare e configurare i cluster e i repository che utilizzi con Config Sync.
  • Crea un trigger di Cloud Build per visualizzare automaticamente la configurazione per due ambienti diversi, utilizzando Kustomize.
  • Imposta Config Sync per sincronizzare la configurazione sottoposta a rendering per i due ambienti separati.

Costi

Questo tutorial utilizza i seguenti componenti fatturabili di Google Cloud:

Per generare una stima dei costi in base all'utilizzo previsto, utilizza il Calcolatore prezzi. I nuovi utenti di Google Cloud possono beneficiare di una prova gratuita.

Al termine di questo tutorial, puoi evitare una fatturazione continua eliminando le risorse che hai creato. Per scoprire di più, vedi Pulizia.

Prima di iniziare

Prima di iniziare questo tutorial, assicurati di aver completato i seguenti passaggi:

  1. In Google Cloud Console, nella pagina del selettore dei progetti, scegli o crea due progetti Google Cloud.

    Vai al selettore progetti

  2. Assicurati che la fatturazione sia attivata per il tuo progetto Cloud. Scopri come verificare se la fatturazione è abilitata su un progetto.

  3. Creare o avere accesso a un account GitHub.

  4. In GitHub, crea un token di accesso personale con ambiti repo e delete_repo. Copia il valore del token negli appunti. Ti servirà per i passaggi successivi.

Preparazione dell'ambiente

Per preparare il tuo ambiente per questo tutorial, completa i seguenti passaggi:

  1. Apri Cloud Shell:

    1. Vai a Google Cloud Console.

      Google Cloud console

    2. Nell'angolo in alto a destra della console, fai clic sul pulsante Attiva Cloud Shell:

    Cloud Shell include gli strumenti nomos e kubectl di cui hai bisogno per completare il tutorial.

  2. Clona il repository di esempio di Anthos Config Management:

    git clone https://github.com/GoogleCloudPlatform/anthos-config-management-samples.git
    
  3. Passa alla cartella che contiene le risorse necessarie per questo tutorial:

    cd anthos-config-management-samples/multi-environments-kustomize/
    
  4. Per eseguire gli script utilizzati in questo tutorial, imposta le seguenti variabili:

    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"
    export CM_CONFIG_DIR="cloud-build-rendering"
    

    Sostituisci quanto segue:

    • DEV_PROJECT_ID: l'ID del progetto Google Cloud che vuoi utilizzare come progetto sviluppatore
    • PROD_PROJECT_ID: l'ID del progetto Google Cloud che vuoi utilizzare come progetto di produzione
    • DEV_CLUSTER_ZONE: la zona di Compute Engine in cui vuoi creare il cluster di sviluppo. Ad esempio: us-central1-c.
    • PROD_CLUSTER_ZONE: la zona di Compute Engine in cui vuoi creare il cluster di produzione
    • GITHUB_USERNAME: il tuo nome utente GitHub
    • GITHUB_TOKEN: il token di accesso personale che hai creato nella sezione Prima di iniziare.
    • GITHUB_EMAIL: il tuo indirizzo email GitHub
  5. Configura il tuo ambiente Git locale in modo che utilizzi il tuo nome utente e il tuo indirizzo email 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
    

Creare le tue risorse

Per concentrarti sul flusso di lavoro che devi utilizzare quando configuri Config Sync per più ambienti, la directory multi-environments-kustomize contiene script che puoi utilizzare per automatizzare la configurazione di Config Sync.

Crea e registra i tuoi cluster

  1. Per creare due cluster, esegui lo script ./create-clusters.sh:

    ./create-clusters.sh
    

    Questo script crea un cluster GKE denominato dev nel progetto di sviluppo e un cluster GKE denominato prod nel progetto di produzione. Questo script abilita anche le API GKE e Anthos e si connette ai cluster dev e prod per consentirti di accedere alle loro API con kubectl.

    Output di esempio:

    kubeconfig entry generated for dev.
    Fetching cluster endpoint and auth data.
    kubeconfig entry generated for prod.
    ⭐️ Done creating clusters.
    
  2. Per registrare i tuoi cluster in due gruppi di Anthos separati, esegui lo script register-clusters.sh:

    ./register-clusters.sh
    

    Questo script crea un account di servizio Google Cloud e una chiave per la registrazione del cluster Anthos, quindi utilizza il comando gcloud container hub memberships register per registrare i cluster dev e prod in Anthos nei loro progetti.

    Output di esempio:

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

Crea i tuoi repository GitHub

  1. Per creare tre repository GitHub, esegui lo script create-repos.sh:

    ./create-repos.sh
    

    Questo script crea tre repository GitHub: foo-config-source, foo-config-dev e foo-config-prod. Gli utenti impegnano la configurazione nel repository di origine e una pipeline CI (che crei in pochi passaggi) esegue il rendering delle configurazioni negli altri due repository, utilizzando valori specifici di dev e prod. Da qui, il cluster dev viene sincronizzato da foo-config-dev e il cluster prod viene sincronizzato da foo-config-prod.

    Output di esempio:

    # 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
    

Crea i tuoi secret

  1. Per creare secret di Secret Manager nel progetto di produzione con le tue credenziali Git, esegui lo script secret-manager-git.sh:

    ./secret-manager-git.sh
    

    La creazione dei tuoi secret in questo modo consente a Cloud Build di eseguire il push a GitHub per tuo conto. La pipeline di Cloud Build da configurare successivamente riceve le informazioni di autenticazione di GitHub direttamente da Secret Manager.

    Output previsto:

    🔐 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
    

Creazione di un trigger di Cloud Build

Ora che hai configurato il tuo ambiente, puoi esplorare la pipeline di Cloud Build.

Per visualizzare la pipeline di Cloud Build, esegui il comando seguente:

cat foo-config-source/cloudbuild.yaml

Questa pipeline utilizza Kustomize per eseguire il rendering di manifest per lo sviluppo e il repository di prodotti utilizzando i manifest nella directory base/.

Output previsto:

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
...

Se accedi al tuo repository foo-config-source/ in GitHub, puoi vedere i manifest base/ e gli overlay Kustomize dev/ e prod/ utilizzati da questa pipeline.

Ogni directory in questo repository contiene un file kustomization.yaml, che elenca i file che Kustomize deve gestire e applicare al cluster. In dev/kustomization.yaml e prod/kustomization.yaml è stata definita una serie di patch. Queste patch manipolano le risorse base/ per quell'ambiente specifico.

Ad esempio, il RoleBinding nel repository foo-config-dev consente a tutti gli sviluppatori di Foo Corp di eseguire il deployment dei pod nel cluster di sviluppo, mentre il RoleBinding nel repository foo- config-prod consente solo a un agente di deployment continuo, deploy-bot@foo-corp.com, di eseguire il deployment dei pod in produzione:

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

Crea il trigger

In questa sezione creerai un trigger di Cloud Build che avvia automaticamente una build ogni volta che apporti modifiche al codice sorgente:

  1. Utilizzando il tuo progetto di produzione, in Google Cloud Console, vai alla pagina Trigger di Cloud Build:

    Apri trigger

  2. Fai clic su Connetti repository.

  3. Nella finestra dei repository di Connect, completa quanto segue:

    1. Nel campo Select source (Seleziona origine), lascia selezionato GitHub e fai clic su Continue.
    2. Nel campo GitHub Account, assicurati che sia selezionato il valore GITHUB_USERNAME definito in precedenza.
    3. Dall'elenco a discesa Repository, seleziona il repository foo-config-source e fai clic su OK.
    4. Seleziona la casella di controllo per accettare i Termini e condizioni.
    5. Fai clic su Connect (Connetti).
  4. Dopo la connessione del repository, fai clic su Crea trigger.

  5. Nella pagina Crea trigger visualizzata, completa i seguenti campi:

    1. Nel campo Nome, aggiungi: Foo-Config-Render.
    2. Configura i campi Descrizione e Tag come preferisci. Non sono necessarie per questo tutorial.
    3. Nel campo Event (Evento), lascia selezionato Push a un ramo.
    4. Dall'elenco a discesa Repository, seleziona foo-config-source.
    5. Lascia il campo Ramo (Ramo) impostato su ^main$.
    6. Nel campo Type (Tipo), lascia selezionata l'opzione Rilevata automaticamente.
    7. Nel campo Location, lascia selezionato Repository.
    8. Fai clic su Crea per tornare alla pagina Panoramica degli attivatori.

Esegui il trigger

Poiché hai già eseguito il push al repository foo-config-source prima di creare questo attivatore, puoi eseguirlo manualmente per attivare il rendering del repository dev e prod:

  1. Nell'elenco degli attivatori, nella riga Foo-Config-Render, fai clic su Esegui. Viene visualizzata la finestra Esegui trigger.
  2. Nella finestra Esegui trigger, assicurati che il campo del ramo sia main e poi fai clic su Esegui trigger.
  3. Viene visualizzato un messaggio che indica Build start on branch main (Build avviata sul ramo principale). Fai clic su Mostra in questo messaggio per visualizzare la pagina Dettagli build.

    La build dovrebbe essere eseguita correttamente, scrivendo l'output della build Kustomize rispettivamente nei repository foo-config-dev e foo-config-prod.

  4. Al termine, apri uno dei tuoi repository dev o prod in GitHub. Dovresti vedere i file YAML che completano il repository e un aggiornamento README che indica l'SHA di commit del repository foo-config-source da cui è stato creato l'ultimo repository.

Configurazione di Config Sync

Ora che hai aggiunto configurazioni ai tuoi repository, puoi installare Config Sync e verificare l'installazione.

Installa Config Sync

Per installare Config Sync, sul cluster di sviluppo e produzione, esegui lo script install-config-sync.sh:

./install-config-sync.sh

Output previsto:

😺 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.

È in corso la sincronizzazione di Config con le configurazioni dei tuoi repository.

Verificare la configurazione

In questa sezione verificherai che i cluster siano sincronizzati con le configurazioni nel tuo repository:

  1. Per controllare lo stato dell'installazione di Config Sync, esegui il comando nomos status:

    nomos status
    

    Dovresti vedere che sia i cluster di sviluppo sia quelli di produzione sono sincronizzati con i rispettivi repository:

    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. Usa kubectl per passare al cluster di sviluppo:

    kubectl config use-context "gke_${DEV_PROJECT}_${DEV_CLUSTER_ZONE}_dev"
    
  3. Per verificare che le risorse siano sincronizzate, ottieni gli spazi dei nomi. Dovresti vedere lo spazio dei nomi foo, sincronizzato dal repository foo-config-dev.

    kubectl get namespace
    

    Output di esempio:

    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
    

    Hai configurato il rendering automatico della configurazione per un ambiente di sviluppo e produzione in più progetti e ambienti Google Cloud.

Esegui la pulizia

Per evitare che al tuo Account Google Cloud vengano addebitati costi relativi alle risorse utilizzate in questo tutorial, elimina il progetto che contiene le risorse oppure mantieni il progetto ed elimina le singole risorse.

Elimina tutte le risorse

Per eliminare le risorse che hai creato in questo tutorial, ma per mantenere invariati i progetti dev e prod, esegui lo script di pulizia:

./cleanup.sh

Elimina i progetti

  1. In Cloud Console, vai alla pagina Gestisci risorse.

    Vai a Gestisci risorse

  2. Nell'elenco dei progetti, seleziona il progetto da eliminare, quindi fai clic su Elimina.
  3. Nella finestra di dialogo, digita l'ID del progetto e fai clic su Chiudi per eliminare il progetto.

Passaggi successivi