Questo tutorial mostra come configurare Config Sync per Google Kubernetes Engine (GKE) in due ambienti, uno per lo sviluppo e uno 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. Il deployment delle applicazioni Foo Corp viene eseguito in GKE, con 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. L'obiettivo dell'amministratore della piattaforma è garantire che entrambi gli ambienti rimangano conformi ai criteri di Foo Corp e che le risorse di livello base, come gli spazi dei nomi e gli account di servizio Kubernetes, rimangano coerenti in entrambi gli ambienti.
Il seguente diagramma mostra una 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,
deveprod, in progetti separati. - Tre repository GitHub,
foo-config-source,foo-config-devefoo-config-prod. Questi sono i 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 repositoryfoo-config-dev, il clusterprodè sincronizzato con il repositoryfoo-config-prod. - Secret di Secret Manager con il tuo nome utente Git e un token sviluppatore. Cloud Build usa questi secret per il commit dei repository GitHub.
- Una pipeline Cloud Build, di cui è stato eseguito il push nel repository
foo-config-source. Questa pipeline utilizzakustomize buildper visualizzare i repositoryfoo-config-devefoo-config-prodpersonalizzati con le configurazioni YAML, utilizzando "Base" e "overlay" infoo-config-source. Questi overlay Kustomize ti sono stati forniti nella cartellaconfig-source/.
Obiettivi
- Prepara l'ambiente eseguendo script per creare e configurare i cluster e i repository che utilizzi con Config Sync.
- Creare un trigger di Cloud Build per il rendering automatico della configurazione per due ambienti diversi, utilizzando Kustomize.
- Imposta Config Sync per sincronizzare la configurazione visualizzata per i due ambienti separati.
Costi
In questo documento vengono utilizzati i seguenti componenti fatturabili di Google Cloud:
Per generare una stima dei costi in base all'utilizzo previsto,
utilizza il Calcolatore prezzi.
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:
Nella pagina del selettore dei progetti, nella console Google Cloud, scegli o crea due progetti Google Cloud.
-
Verifica che la fatturazione sia attivata per il tuo progetto Google Cloud. Scopri come verificare se la fatturazione è abilitata per un progetto.
Creare o avere accesso a un account GitHub.
In GitHub, crea un token di accesso personale con ambiti
repoedelete_repo. Copia il valore del token negli appunti. Ti servirà per i passaggi futuri.
Preparazione dell'ambiente
Per preparare il tuo ambiente a questo tutorial, completa i seguenti passaggi:
Apri Cloud Shell:
Vai alla console Google Cloud.
Nell'angolo in alto a destra della console, fai clic sul pulsante Attiva Cloud Shell:
Cloud Shell include gli strumenti
nomosekubectldi cui hai bisogno per completare il tutorial.Clona il repository di esempio di Anthos Config Management:
git clone https://github.com/GoogleCloudPlatform/anthos-config-management-samples.gitPassa alla cartella che contiene le risorse necessarie per questo tutorial:
cd anthos-config-management-samples/multi-environments-kustomize/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 di sviluppoPROD_PROJECT_ID: l'ID del progetto Google Cloud che vuoi utilizzare come progetto di produzioneDEV_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 tuo cluster di produzioneGITHUB_USERNAME: il tuo nome utente GitHubGITHUB_TOKEN: il token di accesso personale che hai creato nella sezione Prima di iniziareGITHUB_EMAIL: il tuo indirizzo email GitHub
Configura l'ambiente Git locale per l'utilizzo del tuo nome utente e della tua 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
Creazione delle risorse
Per concentrarti sul flusso di lavoro da utilizzare durante la configurazione di 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
Per creare due cluster, esegui lo script
./create-clusters.sh:./create-clusters.shQuesto script crea un cluster GKE denominato
devnel progetto di sviluppo e un cluster GKE denominatoprodnel progetto di produzione. Questo script abilita anche le API GKE e Anthos e si connette ai tuoi clusterdeveprodin modo che tu possa accedere alle loro API conkubectl.Output di esempio:
kubeconfig entry generated for dev. Fetching cluster endpoint and auth data. kubeconfig entry generated for prod. ⭐️ Done creating clusters.Per registrare i cluster in due parchi risorse Anthos separati, esegui lo script
register-clusters.sh:./register-clusters.shQuesto script crea un account di servizio Google Cloud e una chiave per la registrazione del cluster Anthos, quindi utilizza il comando
gcloud container fleet memberships registerper registrare i clusterdeveprodin Anthos nei propri progetti.Output di esempio:
Waiting for Feature Config Management to be created...done. ⭐️ Done registering clusters.
Crea i tuoi repository GitHub
Per creare tre repository GitHub, esegui lo script
create-repos.sh:./create-repos.shQuesto script crea tre repository GitHub:
foo-config-source,foo-config-devefoo-config-prod. Gli utenti eseguono il commit della configurazione nel repository di origine e una pipeline CI (che crei in pochi passaggi) esegue le configurazioni in altri due repository, utilizzando valori specifici dideveprod. Da qui, il clusterdevviene sincronizzato dafoo-config-deve il clusterprodviene sincronizzato dafoo-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
Per creare i secret di Secret Manager nel progetto di produzione con le tue credenziali Git, esegui lo script
secret-manager-git.sh:./secret-manager-git.shCreare i tuoi secret in questo modo consente a Cloud Build di eseguire il push a GitHub per tuo conto. La pipeline di Cloud Build che configurerai in seguito utilizzerà 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 questo comando:
cat foo-config-source/cloudbuild.yaml
Questa pipeline utilizza Kustomize per eseguire il rendering dei manifest per lo sviluppo e il repository di produzione utilizzando i manifest della 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 repository foo-config-source/ in GitHub, puoi
vedere i manifest base/ e gli overlay Kustomize di dev/ e prod/ utilizzati da
questa pipeline.
Ogni directory in questo repository contiene un file kustomization.yaml, in cui sono elencati i file che Kustomize deve gestire e applicare al cluster. In dev/kustomization.yaml e
prod/kustomization.yaml viene definita una serie di patch. Queste patch manipolano le risorse base/ per quell'ambiente specifico.
Ad esempio, l'oggetto RoleBinding nel repository foo-config-dev consente a tutti gli sviluppatori Foo Corp di eseguire il deployment di pod nel cluster Dev, mentre l'associazione dei ruoli nel repository foo-
config-prod consente solo a un agente di deployment continuo, deploy-bot@foo-corp.com, di eseguire il deployment di 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:
Utilizzando il tuo progetto di produzione, nella console Google Cloud, vai alla pagina Trigger di Cloud Build:
Fai clic su Connetti repository.
Nella finestra Connetti repository, completa la procedura seguente:
- Nel campo Select source (Seleziona origine), lascia selezionato GitHub e fai clic su Continue (Continua).
- Nel campo GitHub Account, assicurati che sia selezionato il campo
GITHUB_USERNAMEche hai definito in precedenza. - Nell'elenco a discesa Repository, seleziona il repository
foo-config-sourcee fai clic su OK. - Seleziona la casella di controllo per accettare i Termini e condizioni.
- Fai clic su Connetti.
Dopo aver connesso il repository, fai clic su Crea trigger.
Nella pagina Crea trigger visualizzata, completa i seguenti campi:
- Nel campo Nome, aggiungi:
Foo-Config-Render. - Configura i campi Descrizione e Tag come preferisci. Non sono necessari per questo tutorial.
- Nel campo Evento, lascia selezionata l'opzione Trasferisci a un ramo.
- Nell'elenco a discesa Repository, seleziona
foo-config-source. - Lascia nel campo Ramo il valore
^main$. - Nel campo Type (Tipo), lascia selezionato Autorilevato.
- Nel campo Località, lascia selezionato Repository.
- Fai clic su Crea per tornare alla pagina Panoramica degli attivatori.
- Nel campo Nome, aggiungi:
Esegui il trigger
Poiché hai già eseguito il push nel repository foo-config-source prima di creare questo trigger, puoi eseguirlo manualmente per attivare il rendering del repository dev e prod:
- Nell'elenco degli attivatori, nella riga
Foo-Config-Render, fai clic su Esegui. Viene visualizzata la finestra Esegui trigger. - Nella finestra Esegui trigger, assicurati che il campo del ramo sia
main, quindi fai clic su Esegui trigger. Viene visualizzato un messaggio che indica che la build è stata avviata nel 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 nel repository
foo-config-devefoo-config-prod.Al termine della build, apri uno dei tuoi repository di sviluppo o produzione in GitHub. Dovresti vedere i file YAML che completano il repository e un aggiornamento README che indica il SHA del commit del repository
foo-config-sourceda cui è stato creato l'ultimo repository.
Configurazione di Config Sync
Ora che hai aggiunto le 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 Sync con le configurazioni dei tuoi repository.
Verificare la configurazione
In questa sezione verificherai che i tuoi cluster siano sincronizzati con le configurazioni del tuo repository:
Per controllare lo stato dell'installazione di Config Sync, esegui il comando
nomos status:nomos statusDovresti vedere che sia i cluster di sviluppo che quelli di produzione sono ora 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 ```Usa
kubectlper passare al cluster di sviluppo:kubectl config use-context "gke_${DEV_PROJECT}_${DEV_CLUSTER_ZONE}_dev"Per verificare che le risorse siano sincronizzate, ottieni gli spazi dei nomi. Dovresti vedere lo spazio dei nomi
foo, sincronizzato dal repositoryfoo-config-dev.kubectl get namespaceOutput 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 9m30sHai 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 intatti i progetti di sviluppo e produzione, esegui lo script di pulizia:
./cleanup.sh
Elimina i progetti
- Nella console Google Cloud, vai alla pagina Gestisci risorse.
- Nell'elenco dei progetti, seleziona il progetto che vuoi eliminare, quindi fai clic su Elimina.
- Nella finestra di dialogo, digita l'ID del progetto e fai clic su Chiudi per eliminare il progetto.
Passaggi successivi
- Scopri di più sulle implementazioni sicure con Anthos Config Management
- Scopri come convalidare le app in base ai criteri aziendali in una pipeline CI
- Esplora le best practice per la gestione dei criteri con Anthos Config Management e GitLab
- Esplora architetture di riferimento, diagrammi e best practice su Google Cloud. Dai un'occhiata al nostro Cloud Architecture Center.