Deployment di un progetto di zona di destinazione

Puoi utilizzare Config Controller per eseguire il deployment e gestire in modo dichiarativo una zona di destinazione in Google Cloud.

Questo tutorial aiuta gli amministratori dell'organizzazione a configurare Google Cloud per carichi di lavoro aziendali scalabili e pronti per la produzione mediante il deployment di un progetto base di zona di destinazione, che include best practice per il networking, la sicurezza e la gestione delle risorse.

Obiettivi

Durante il processo di deployment della zona di destinazione, dovrai:

  1. Imposta Config Controller e sincronizzazione delle risorse da un repository Git al tuo ambiente Google Cloud.
  2. Scopri progetti che acquisiscono pattern di progettazione comuni per Google Cloud, come il deployment di un VPC condiviso.
  3. Crea una pipeline di deployment automatizzata (basata su Cloud Build) che ti consente di personalizzare i progetti, di trasformarli con le funzioni kpt e di eseguire il deployment delle risorse utilizzando Config Connector.

Questi componenti vengono combinati nel flusso di lavoro descritto nel seguente diagramma:

Un amministratore della piattaforma che esegue il deployment di progetti tramite Config Controller

Costi

Prima di iniziare

Prima di configurare la zona di destinazione, devi preparare alcuni dettagli.

  1. Accedi al tuo Account Google.

    Se non ne hai già uno, crea un nuovo account.

  2. Nella pagina del selettore dei progetti in Google Cloud Console, seleziona o crea un progetto Google Cloud.

    Vai al selettore progetti

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

  4. Installa e inizializza l'interfaccia a riga di comando di Google Cloud.
  5. Nella pagina del selettore dei progetti in Google Cloud Console, seleziona o crea un progetto Google Cloud.

    Vai al selettore progetti

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

  7. Installa e inizializza l'interfaccia a riga di comando di Google Cloud.
  8. Installa Git se non è già installato.
  9. Crea gruppi Google che verranno utilizzati per concedere l'accesso alla tua organizzazione. In particolare, dovresti avere un gruppo per gli amministratori dell'organizzazione e un gruppo per gli amministratori della fatturazione.
  10. Installa gli strumenti Kubernetes (nomos, kubectl e kpt) utilizzati per questo tutorial. Puoi anche installare i componenti direttamente dalle rispettive pagine.
    gcloud components install pkg
  11. Kpt richiede Docker versione 20.10.0 o successiva. Installa Docker se non è già installato. Fai riferimento ai passaggi successivi all'installazione per gestire Docker come utente non root.

Preparazione dell'ambiente

Prima di eseguire il deployment del progetto base della zona di destinazione, devi impostare alcune variabili di ambiente:

export PROJECT_ID=PROJECT_ID
export CONFIG_CONTROLLER_NAME=config-controller-1
export BILLING_ACCOUNT=$(gcloud alpha billing projects describe $PROJECT_ID \
  '--format=value(billingAccountName)' | sed 's/.*\///')
export ORG_ID=$(gcloud projects get-ancestors ${PROJECT_ID} --format='get(id)' | tail -1)
gcloud config set project ${PROJECT_ID}

Sostituisci quanto segue:

  • PROJECT_ID: l'ID progetto in cui verrà ospitato Config Controller

Configurazione di Config Controller

Config Controller fornisce un piano di controllo gestito, basato su Kubernetes, per la configurazione delle risorse cloud. È preinstallato in Policy Controller, Config Sync e Config Connector.

  1. Nel progetto, abilita l'API Config Controller e l'API GKE da cui dipende Config Controller:
     gcloud services enable krmapihosting.googleapis.com container.googleapis.com
    
  2. Crea il tuo Config Controller. Questa operazione potrebbe richiedere più di 15 minuti.
    gcloud anthos config controller create ${CONFIG_CONTROLLER_NAME} \
      --location=us-central1
  3. Verifica che Config Controller sia stato creato correttamente:
    gcloud anthos config controller list --location=us-central1
  4. Esegui l'autenticazione in Config Controller in modo da poter iniziare ad applicare la configurazione:
    gcloud anthos config controller get-credentials ${CONFIG_CONTROLLER_NAME} \
      --location us-central1
  5. Concedi a Config Controller l'autorizzazione per gestire le risorse Google Cloud nel progetto di gestione:
    export SA_EMAIL="$(kubectl get ConfigConnectorContext -n config-control \
      -o jsonpath='{.items[0].spec.googleServiceAccount}' 2> /dev/null)"
    gcloud projects add-iam-policy-binding "${PROJECT_ID}" \
      --member "serviceAccount:${SA_EMAIL}" \
      --role "roles/owner" \
      --project "${PROJECT_ID}"
  6. Concedi a Config Controller l'autorizzazione per gestire le risorse a livello di organizzazione, per il deployment del progetto base della zona di destinazione:
    gcloud organizations add-iam-policy-binding $ORG_ID \
      --role=roles/resourcemanager.organizationAdmin \
      --condition=None \
      --member="serviceAccount:${SA_EMAIL}"

Creazione di una pipeline GitOps

Configurando Config Controller per la sincronizzazione con un repository Git, puoi collaborare alle modifiche alla tua zona di destinazione e gestire un audit trail solido.

In questo passaggio, eseguirai il deployment del tuo primo progetto base. Questo progetto include:

  • Due Cloud Source Repositories: un repository "source" in cui eseguirerai il commit delle modifiche e un repository "deployment" che contiene una copia della configurazione finale applicata a Config Controller.
  • Un trigger di Cloud Build che controlla le modifiche nel repository di origine, esegue eventuali funzioni kpt incluse e esegue il commit dell'output finale nel repository di deployment.
  • Una configurazione di Config Sync che connette Config Controller al repository di deployment.

Esegui il deployment del progetto base

  1. Abilita il servizio Resource Manager sul tuo progetto:
    gcloud services enable cloudresourcemanager.googleapis.com
  2. Scarica il progetto base GitOps da GitHub alla tua macchina locale usando kpt:
    kpt pkg get https://github.com/GoogleCloudPlatform/blueprints.git/catalog/gitops@main gitops
  3. Questo progetto base può essere personalizzato utilizzando un numero di setters. Apri il file gitops/setters.yaml per modificarli:
    # Copyright 2021 Google LLC
    #
    # Licensed under the Apache License, Version 2.0 (the "License");
    # you may not use this file except in compliance with the License.
    # You may obtain a copy of the License at
    #
    #      http://www.apache.org/licenses/LICENSE-2.0
    #
    # Unless required by applicable law or agreed to in writing, software
    # distributed under the License is distributed on an "AS IS" BASIS,
    # WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
    # See the License for the specific language governing permissions and
    # limitations under the License.
    apiVersion: v1
    kind: ConfigMap
    metadata:
      name: setters
      annotations:
        config.kubernetes.io/local-config: "true"
    data:
      # This should be the project where you deployed Config Controller
      project-id: project-id
      project-number: "1234567890123"
      # This should be the name of your Config Controller instance
      cluster-name: cluster-name
      # You can leave these defaults
      namespace: config-control
      deployment-repo: deployment-repo
      source-repo: source-repo
    
  4. Personalizza questo progetto sostituendo i seguenti setter nel file precedente:
    • cluster-name: il nome che hai scelto per il controller di configurazione. Puoi recuperarlo utilizzando questo comando:
      echo ${CONFIG_CONTROLLER_NAME}
    • project-id: l'ID progetto in cui viene eseguito il deployment di Config Controller.
    • project-number: il numero per il progetto in cui viene eseguito il deployment di Config Controller. Puoi recuperarlo utilizzando questo comando:
      gcloud projects describe ${PROJECT_ID} --format='get(projectNumber)'
  5. Esegui il rendering del progetto base per propagare le personalizzazioni a tutte le risorse:
    kpt fn render gitops/
  6. Applica il progetto al tuo cluster Config Controller:
    kubectl apply --wait -f gitops/ --recursive
  7. Attendi che i repository vengano creati dal progetto base:
    kubectl wait --for=condition=READY -f gitops/source-repositories.yaml

Salva il progetto base in Git

Ora salva il progetto nel repository Git che ha creato. In questo modo potrai salvare le personalizzazioni e monitorare eventuali modifiche future.

  1. Imposta il ramo predefinito su main:
    git config --global init.defaultBranch main
  2. Dai un'occhiata al repository Git creato dal progetto base:
    gcloud source repos clone source-repo
  3. Sposta il progetto base GitOps nel repository Git:
    mv gitops source-repo/
  4. Apri il repository Git:
    cd source-repo/
  5. Esegui il commit del progetto base in Git ed esegui il push delle modifiche:
    git add gitops/
    git commit -m "Add GitOps blueprint"
    git push

Verifica l'esito positivo

Puoi verificare che il processo di bootstrap qui sopra sia stato completato correttamente:

  • Verifica che Config Connector sia stato installato correttamente:
    kubectl wait -n cnrm-system --for=condition=Ready pod --all
  • Conferma che Cloud Source Repositories sia stato creato correttamente:
    gcloud source repos list
  • Verifica che le risorse necessarie siano state create in Config Controller:
    kubectl get gcp -n config-control -o yaml \
      | grep "^    name: \\|message"
    L'output dovrebbe essere simile al seguente:
        name: source-repo-cicd-trigger
          message: The resource is up to date
        name: allow-configsync-sa-read-csr
          message: The resource is up to date
        name: configsync-sa-workload-identity-binding
          message: The resource is up to date
        name: deployment-repo-cloudbuild-write
          message: The resource is up to date
        name: source-repo-cloudbuild-read
          message: The resource is up to date
        name: config-sync-sa
          message: The resource is up to date
        name: cloudbuild.googleapis.com
          message: The resource is up to date
        name: sourcerepo.googleapis.com
          message: The resource is up to date
        name: deployment-repo
          message: The resource is up to date
        name: source-repo
          message: The resource is up to date
    
  • Verifica che la build sia stata completata correttamente:
    gcloud builds list --project=${PROJECT_ID} \
      --filter="source.repo_source.commit_sha=$(git rev-parse HEAD)"
  • Verifica che il push dei manifest idratati sia stato eseguito nel repository del deployment:
    BUILD_ID=$(gcloud builds list --project=${PROJECT_ID} --filter="source.repo_source.commit_sha=$(git rev-parse HEAD)" --format="value(id)")
    gcloud builds log --project=${PROJECT_ID} ${BUILD_ID}
    Output di esempio:
    ...
    Step #2 - "Push Changes To Deployment Repo":  7 files changed, 297 insertions(+)
    Step #2 - "Push Changes To Deployment Repo":  create mode 100644 config/.gitkeep
    Step #2 - "Push Changes To Deployment Repo":  create mode 100644 config/gitops/cloudbuild-iam.yaml
    Step #2 - "Push Changes To Deployment Repo":  create mode 100644 config/gitops/configsync/config-management.yaml
    Step #2 - "Push Changes To Deployment Repo":  create mode 100644 config/gitops/configsync/configsync-iam.yaml
    Step #2 - "Push Changes To Deployment Repo":  create mode 100644 config/gitops/hydration-trigger.yaml
    Step #2 - "Push Changes To Deployment Repo":  create mode 100644 config/gitops/services.yaml
    Step #2 - "Push Changes To Deployment Repo":  create mode 100644 config/gitops/source-repositories.yaml
    Step #2 - "Push Changes To Deployment Repo": To https://source.developers.google.com/p/$PROJECT_ID/r/deployment-repo
    Step #2 - "Push Changes To Deployment Repo":  * [new branch]      main -> main
    Step #2 - "Push Changes To Deployment Repo":
    Step #2 - "Push Changes To Deployment Repo":
    Step #2 - "Push Changes To Deployment Repo": Latest deployment repo commit SHA: $SHA
    Finished Step #2 - "Push Changes To Deployment Repo"
    PUSH
    DONE
    

Inizializzazione della zona di destinazione

Ora che Config Controller è connesso a Git, è il momento di inizializzare il progetto base della zona di destinazione.

Questo progetto base prepara la zona di destinazione configurando la struttura complessiva della tua organizzazione, tra cui:

  • Creazione di spazi dei nomi separati in Config Controller per la gestione di hierarchy, logging, networking, projects e policies. A ogni spazio dei nomi viene assegnato un account di servizio Google Cloud con privilegi diversi.
  • L'assegnazione del ruolo Amministratore di fatturazione al gruppo degli amministratori della fatturazione e del ruolo Amministratore dell'organizzazione al gruppo degli amministratori dell'organizzazione.
  • Attivazione dei criteri dell'organizzazione relativi alle best practice nella tua organizzazione.

Esegui il deployment del progetto base

Esegui il deployment della tua zona di destinazione partendo dal repository di origine che hai clonato sopra:

  1. Scarica il progetto base della zona di destinazione e aggiungilo al tuo repository
    kpt pkg get https://github.com/GoogleCloudPlatform/blueprints.git/catalog/landing-zone@main ./landing-zone
    git add landing-zone/
    git commit -m "Add landing zone"
  2. Questo progetto include una serie di setter per la configurazione della zona di destinazione. Apri il file landing-zone/setters.yaml per modificarli:
    # Copyright 2021 Google LLC
    #
    # Licensed under the Apache License, Version 2.0 (the "License");
    # you may not use this file except in compliance with the License.
    # You may obtain a copy of the License at
    #
    #      http://www.apache.org/licenses/LICENSE-2.0
    #
    # Unless required by applicable law or agreed to in writing, software
    # distributed under the License is distributed on an "AS IS" BASIS,
    # WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
    # See the License for the specific language governing permissions and
    # limitations under the License.
    apiVersion: v1
    kind: ConfigMap
    metadata:
      name: setters
      annotations:
        config.kubernetes.io/local-config: "true"
    data:
      # Organization ID and billing account
      org-id: "123456789012"
      billing-account-id: AAAAAA-BBBBBB-CCCCCC
      # Groups to use for org-level roles
      group-org-admins: gcp-organization-admins@example.com
      group-billing-admins: gcp-billing-admins@example.com
      # The project where Config Controller is deployed
      management-project-id: management-project-id
      # This default is safe to keep
      management-namespace: config-control
    
  3. Personalizza questo progetto sostituendo i seguenti setter nel file precedente:
    • org-id: l'ID dell'organizzazione per la tua zona di destinazione
    • billing-account-id: l'account di fatturazione predefinito che vuoi utilizzare per i nuovi progetti
    • management-project-id: l'ID progetto in cui viene eseguito il deployment di Config Controller.
    • group-org-admins: l'indirizzo email del gruppo Google dell'amministratore della tua organizzazione, ad esempio gcp-organization-admins@example.com
    • group-billing-admins: l'email del gruppo Google degli amministratori della fatturazione, ad esempio gcp-billing-admins@example.com.
  4. Rivedi le personalizzazioni apportate al progetto base:
    git diff
  5. Esegui il push delle modifiche al repository, dove verranno sincronizzate automaticamente con Config Controller e applicate:
    git commit -a -m "Customize landing zone blueprint"
    git push
    

Gestire i criteri dell'organizzazione

Il progetto di zona di destinazione include una serie di vincoli dei criteri dell'organizzazione che rappresentano best practice per migliorare la sicurezza degli ambienti.

Vincolo Descrizione
compute.disableNestedVirtualization Disattiva la virtualizzazione nidificata con accelerazione hardware per tutte le VM di Compute Engine.
compute.disableSerialPortAccess Disabilita l'accesso alla porta seriale delle VM di Compute Engine.
compute.disableGuestAttributesAccess Disabilita l'accesso dell'API Compute Engine agli attributi guest delle VM.
compute.vmExternalIpAccess Limita l'insieme di istanze VM di Compute Engine che possono utilizzare indirizzi IP esterni.
compute.skipDefaultNetworkCreation Impedisce a Google Cloud di saltare la creazione della rete predefinita e delle risorse correlate durante la creazione del progetto.
compute.restrictXpnProjectLienRemoval Limita l'insieme di utenti che possono rimuovere un blocco progetto Project condiviso.
sql.restrictPublicIp Limita gli indirizzi IP pubblici sulle istanze Cloud SQL.
iam.disableServiceAccountKeyCreation Disattiva la creazione di chiavi dell'account di servizio scaricabili.
storage.uniformBucketLevelAccess I bucket devono utilizzare un accesso uniforme a livello di bucket basato su IAM.

Rimozione dei vincoli

Se uno dei vincoli predefiniti rappresenta problemi per la tua organizzazione, è sufficiente eliminare il file YAML associato dal repository di origine per ripristinare il comportamento predefinito.

Ad esempio, per rimuovere il vincolo che impedisce l'accesso alla porta seriale:

  1. Rimuovi il file:
    git rm ./landing-zone/policies/disable-serial-port.yaml
  2. Esegui il commit e il push della modifica:
    git commit -m "Remove serial port org policy"
    git push
    

Verifica l'esito positivo

Puoi verificare che la tua zona di destinazione sia stata inizializzata da:

  • Controllo dello stato della pipeline di esecuzione di Cloud Build.
  • La verifica del repository Git è sincronizzata con il tuo Config Controller:
    nomos status
  • Conferma degli spazi dei nomi hierarchy, projects, policies, logging e networking:
    kubectl get ns
  • Verifica che le risorse necessarie siano state create in Config Controller:
    kubectl get gcp --all-namespaces -o yaml \
      | grep "^    name: \|message"
  • Elenca i criteri dell'organizzazione tramite l'interfaccia a riga di comando:
    gcloud resource-manager org-policies list --organization=$ORG_ID

Configurazione della gerarchia delle risorse

In Google Cloud, le risorse sono organizzate in cartelle e progetti:

  • I progetti contengono risorse cloud come macchine virtuali, database e bucket di archiviazione.
  • Le cartelle vengono utilizzate per raggruppare i progetti e semplificare la gestione dei criteri, incluso IAM. Ad esempio, possono rappresentare i reparti principali della tua organizzazione, come finanza o vendita al dettaglio, o ambienti come quelli di produzione rispetto a quelli non di produzione. Le cartelle possono essere nidificate tra loro per formare una gerarchia di risorse.

Forniamo quattro diversi progetti di gerarchia delle risorse per soddisfare diverse strutture organizzative:

  • Semplice: si tratta di un semplice progetto base con un singolo livello di cartelle che rappresentano environments.
  • Team: questo progetto base contiene due livelli di cartelle: teams -> environments
  • Unità aziendali: questo progetto divide la tua organizzazione in tre livelli di cartelle, con particolare attenzione alle unità aziendali autonome: divisions -> teams -> environments
  • Ambienti: questo progetto base contiene tre livelli di cartelle, con un'attenzione particolare ai criteri incentrati sull'ambiente: environments -> divisions -> teams

Esegui il deployment del progetto base

Dopo aver scelto la gerarchia delle risorse preferita, segui le istruzioni appropriate per eseguirne il deployment.

Semplice

Questo progetto è adatto per le organizzazioni piatte, in cui per la gestione del cloud è necessario un semplice insieme di criteri per ogni ambiente, ma tutti i team vengono trattati in modo uniforme.

  1. Scarica il progetto base:
    kpt pkg get https://github.com/GoogleCloudPlatform/blueprints.git/catalog/hierarchy/simple@main ./landing-zone/hierarchy/
  2. Modifica il file landing-zone/hierarchy/hierarchy.yaml in modo che rifletta la struttura organizzativa desiderata.
    spec:
      config:
        - shared
        - dev
        - prod
        - qa
      parentRef:
        # This should match your organization ID
        external: '123456789012'

    Questi valori devono essere aggiornati in hierarchy.yaml:

    • spec.config: gli ambienti che ti interessano, che diventeranno cartelle di primo livello.
    • spec.parentRef.external: aggiorna questo valore in modo che corrisponda all'ID organizzazione
  3. Modifica il vincolo del criterio di denominazione incluso in landing-zone/hierarchy/policies/naming-constraint.yaml in modo che rifletta lo schema di denominazione preferito per le cartelle. Lo schema di denominazione è definito come un'espressione regolare. In particolare, devi modificare questa espressione per includere tutti gli ambienti aggiuntivi che hai definito.
    spec:
      parameters:
        naming_rules:
          - kind: Folder
            patterns:
              # Matches words like "dev", "prod" or "staging"
              - ^(dev|prod|staging|qa|shared)$
  4. Aggiungi la gerarchia ed esegui il push al repository Git:
    git add ./landing-zone/hierarchy/
    git commit -m "Add resource hierarchy and update folder naming convention."
    git push

Team

Questo progetto è adatto per le organizzazioni più semplici in cui ogni team è responsabile delle proprie operazioni cloud e ha la possibilità di impostare criteri personalizzati sulla modalità di utilizzo del cloud.

  1. Scarica il progetto base:
    kpt pkg get https://github.com/GoogleCloudPlatform/blueprints.git/catalog/hierarchy/team@main ./landing-zone/hierarchy/
  2. Modifica il file landing-zone/hierarchy/hierarchy.yaml in modo che rifletta la struttura organizzativa desiderata.
    spec:
      config:
        - retail:
            $subtree: environments
        - finance:
            $subtree: environments
      parentRef:
        # This should match your organization ID
        external: '123456789012'
      subtrees:
        environments:
          - dev
          - prod
          - qa

    Questi valori devono essere aggiornati in hierarchy.yaml:

    • spec.config: i team che preferisci, che diventeranno cartelle di primo livello.
    • spec.subtrees.environments: gli ambienti che vuoi, che diventeranno sottocartelle di ogni team
    • spec.parentRef.external: aggiorna questo valore in modo che corrisponda all'ID organizzazione
  3. Modifica il vincolo del criterio di denominazione incluso in landing-zone/hierarchy/policies/naming-constraint.yaml in modo che rifletta lo schema di denominazione preferito per le cartelle. Lo schema di denominazione è definito come un'espressione regolare. In particolare, devi modificare questa espressione per includere tutti gli ambienti aggiuntivi che hai definito.
    spec:
      parameters:
        naming_rules:
          - kind: Folder
            patterns:
              # Matches words like "dev", "prod" or "staging"
              - ^(dev|prod|staging|qa|shared)$
  4. Aggiungi la gerarchia ed esegui il push al repository Git:
    git add ./landing-zone/hierarchy/
    git commit -m "Add resource hierarchy and update folder naming convention."
    git push

Unità aziendali

Questo progetto è adatto per organizzazioni grandi e complesse, in cui ciascuna unità aziendale o divisione è in gran parte responsabile delle proprie operazioni cloud. Permette a ciascuna unità aziendale di impostare con facilità criteri che si applicano a tutti i team, mentre i singoli team sono responsabili dei propri ambienti (entro i vincoli di primo livello).

  1. Scarica il progetto base:
    kpt pkg get https://github.com/GoogleCloudPlatform/blueprints.git/catalog/hierarchy/bu@main ./landing-zone/hierarchy/
  2. Modifica il file landing-zone/hierarchy/hierarchy.yaml in modo che rifletta la struttura organizzativa desiderata.
    spec:
      config:
        - retail:
            - apps:
                $subtree: environments
            - data:
                $subtree: environments
        - finance:
            - commercial:
                $subtree: environments
      parentRef:
        # This should match your organization ID
        external: '123456789012'
      subtrees:
        environments:
          - dev
          - prod

    Questi valori devono essere aggiornati in hierarchy.yaml:

    • spec.config: la struttura organizzativa che vuoi, che può includere team nidificati nella divisione, ad esempio il progetto base inizia con una divisione vendita al dettaglio con sottocartelle app e dati.
    • spec.subtrees.environments: gli ambienti che vuoi, che diventeranno sottocartelle di ogni team
    • spec.parentRef.external: aggiorna questo valore in modo che corrisponda all'ID organizzazione
  3. Modifica il vincolo del criterio di denominazione incluso in landing-zone/hierarchy/policies/naming-constraint.yaml in modo che rifletta lo schema di denominazione preferito per le cartelle. Lo schema di denominazione è definito come un'espressione regolare. In particolare, devi modificare questa espressione per includere tutti gli ambienti aggiuntivi che hai definito.
    spec:
      parameters:
        naming_rules:
          - kind: Folder
            patterns:
              # Matches words like "dev", "prod" or "staging"
              - ^(dev|prod|staging|qa|shared)$
  4. Aggiungi la gerarchia ed esegui il push al repository Git:
    git add ./landing-zone/hierarchy/
    git commit -m "Add resource hierarchy and update folder naming convention."
    git push

Ambienti

Questo progetto è adatto per le organizzazioni più grandi che hanno bisogno di rivendicare un controllo forte e coerente sui criteri dell'ambiente (ad esempio, limitando l'accesso alle risorse di produzione) e offrendo al contempo flessibilità per criteri granulari di distribuzione e specifici del team.

  1. Scarica il progetto base:
    kpt pkg get https://github.com/GoogleCloudPlatform/blueprints.git/catalog/hierarchy/env-bu@main ./landing-zone/hierarchy/
  2. Modifica il file landing-zone/hierarchy/hierarchy.yaml in modo che rifletta la struttura organizzativa desiderata.
    spec:
      config:
        - dev:
            $subtree: environment
        - prod:
            $subtree: environment
      parentRef:
        # This should match your organization ID
        external: '123456789012'
      subtrees:
        environment:
          - retail:
              - apps
              - data
          - finance:
              - commercial

    Questi valori devono essere aggiornati in hierarchy.yaml:

    • spec.config: le cartelle di ambiente di primo livello desiderate, che includono ciascuna una copia completa della struttura secondaria dell'ambiente
    • spec.subtrees.environment: la gerarchia che vuoi divisioni e team di cui verrà eseguito il mirroring in ogni ambiente, ad esempio il progetto inizia con una divisione vendita al dettaglio con sottocartelle app e dati
    • spec.parentRef.external: aggiorna questo valore in modo che corrisponda all'ID organizzazione
  3. Aggiungi la gerarchia ed esegui il push al repository Git:
    git add ./landing-zone/hierarchy/
    git commit -m "Add resource hierarchy and update folder naming convention."
    git push

Verifica l'esito positivo

Puoi verificare che la gerarchia delle risorse sia stata creata correttamente in uno dei seguenti modi:

  • Elencare le cartelle all'interno della tua organizzazione:
    gcloud resource-manager folders list --organization=$ORG_ID
  • Recupero dello stato delle cartelle direttamente dallo spazio dei nomi della gerarchia nel cluster:
    kubectl get folders -n hierarchy -o yaml \
      | grep "^    name: \|message"

Stabilire la connettività di rete

Come parte della zona di destinazione, ti consigliamo di eseguire il deployment di un'architettura di rete VPC condivisa. Il progetto base per il networking fornito configura una rete e stabilisce una VPN Cloud per la connettività ibrida.

Crea un progetto host

Prima di eseguire il deployment di una rete, devi creare un progetto per l'hosting. Questa operazione deve essere eseguita una volta per ogni ambiente, utilizzando il progetto base di progetto del progetto incluso.

  1. Scarica il progetto di progetto nella zona di destinazione per creare un progetto host.
    export NET_PROJECT_ID="NETWORK_PROJECT_ID"
    export ENVIRONMENT="ENVIRONMENT"
    
    kpt pkg get \
      https://github.com/GoogleCloudPlatform/blueprints.git/catalog/project@main \
      ./landing-zone/projects/${NET_PROJECT_ID}
    

    Sostituisci quanto segue:

    • ENVIRONMENT: l'ambiente per cui stai configurando un VPC condiviso, ad esempio dev.
    • NETWORK_PROJECT_ID: l'ID che vuoi assegnare al progetto di networking.
  2. Apri il file landing-zone/projects/NETWORK_PROJECT_ID/setters.yaml. Personalizza questo progetto sostituendo i seguenti setter in:
    # Copyright 2021 Google LLC
    #
    # Licensed under the Apache License, Version 2.0 (the "License");
    # you may not use this file except in compliance with the License.
    # You may obtain a copy of the License at
    #
    #      http://www.apache.org/licenses/LICENSE-2.0
    #
    # Unless required by applicable law or agreed to in writing, software
    # distributed under the License is distributed on an "AS IS" BASIS,
    # WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
    # See the License for the specific language governing permissions and
    # limitations under the License.
    apiVersion: v1
    kind: ConfigMap
    metadata:
      name: setters
    data:
      folder-name: name.of.folder
      project-id: project-id
      # These defaults can be kept
      folder-namespace: hierarchy
      networking-namespace: networking
    
    Imposta i valori seguenti:
    • project-id: l'ID che hai scelto
    • folder-name l'ID della cartella che deve contenere il progetto di rete. Le cartelle sono precedute dal nome della cartella principale, ad esempio la cartella shared nell'ambiente dev avrà l'ID dev.shared.
  3. Trasforma il tuo progetto in un progetto host del VPC condiviso aggiungendo un progetto base aggiuntivo:
    kpt pkg get \
      https://github.com/GoogleCloudPlatform/blueprints.git/catalog/networking/shared-vpc@main \
      ./landing-zone/projects/${NET_PROJECT_ID}/host-project
    
  4. Esegui il commit delle modifiche per attivare la creazione di progetti:
    git add ./landing-zone/projects/${NET_PROJECT_ID}/
    git commit -m "Add networking host project"
    git push
    

Crea la rete

Ora che hai un progetto host, puoi creare un VPC condiviso utilizzando il progetto base di networking:

  1. Aggiungi il progetto base della rete alla zona di destinazione:
    kpt pkg get \
      https://github.com/GoogleCloudPlatform/blueprints.git/catalog/networking/network@main \
      ./landing-zone/network/${ENVIRONMENT}/
    
  2. Apri il file landing-zone/network/ENVIRONMENT/setters.yaml. Personalizza questo progetto sostituendo i seguenti setter:
    # Copyright 2021 Google LLC
    #
    # Licensed under the Apache License, Version 2.0 (the "License");
    # you may not use this file except in compliance with the License.
    # You may obtain a copy of the License at
    #
    #      http://www.apache.org/licenses/LICENSE-2.0
    #
    # Unless required by applicable law or agreed to in writing, software
    # distributed under the License is distributed on an "AS IS" BASIS,
    # WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
    # See the License for the specific language governing permissions and
    # limitations under the License.
    apiVersion: v1
    kind: ConfigMap
    metadata:
      name: setters
    data:
      # Required setters
      network-name: network-name
      project-id: project-id
      region: us-central1
      vpn-tunnel-peer-ip-01: "15.1.0.120"
      vpn-tunnel-peer-ip-02: "15.1.1.120"
      # Optional setters
      namespace: networking
      vpn-secret-key: vpn-shared-secret
      vpn-secret-name: vpn-shared-secret
      prefix: ""
    
    Imposta i valori seguenti:
    • network-name: il nome che vuoi utilizzare per la rete, ad esempio dev-network-shared
    • region: la regione in cui eseguire il deployment della prima subnet, ad esempio us-east4
    • project-id: l'ID progetto in cui verrà ospitata la rete. (NETWORK_PROJECT_ID)
  3. Crea un secret per la chiave precondivisa utilizzata da Cloud VPN. Questo valore è sensibile e non deve essere confermato nel tuo repository Git. Puoi inviarlo direttamente a Config Controller:
    kubectl create secret generic vpn-shared-secret \
      --from-literal=vpn-shared-secret="SECRET_VALUE" \
      -n networking
  4. Esegui il commit del progetto base personalizzato per eseguire il deployment della rete:
    git add ./landing-zone/network/
    git commit -m "Add network setup"
    git push
    

Verificare il deployment della rete

Puoi verificare che la rete sia stata creata correttamente seguendo i passaggi riportati di seguito:

  • Conferma della creazione del progetto:
    kubectl describe project ${NET_PROJECT_ID} -n projects
  • Recupero dello stato della rete direttamente dallo spazio dei nomi di rete nel cluster:
    kubectl get gcp \
      -n networking -o yaml \
      | grep "^    name: \|message"
  • Ispezione la rete tramite Cloud Console.

Esportazione dati di logging

Una delle best practice di Google Cloud per le organizzazioni aziendali è quella di monitorare e conservare con attenzione i log di controllo.

I progetti delle zone di destinazione includono diverse opzioni per la gestione dell'esportazione e della conservazione dei log.

Segui i passaggi riportati di seguito per eseguire il deployment di un progetto che esporta tutti i log della tua organizzazione in BigQuery per la conservazione e l'analisi a lungo termine.

Crea un progetto host

Se vuoi esportare i log in BigQuery, hai bisogno di un progetto per ospitare i log. Poiché esporterai i log per l'intera organizzazione, devi collocare questo progetto nell'ambiente di produzione. Può essere creato utilizzando un progetto base.

  1. Scarica il progetto di progetto nella zona di destinazione per creare un progetto host.
    export LOGGING_PROJECT_ID="LOGGING_PROJECT_ID"
    
    kpt pkg get \
      https://github.com/GoogleCloudPlatform/blueprints.git/catalog/project@main \
      ./landing-zone/projects/${LOGGING_PROJECT_ID}
    

    Sostituisci quanto segue:

    • LOGGING_PROJECT_ID: l'ID che vuoi assegnare al progetto di networking.
  2. Apri il file landing-zone/projects/LOGGING_PROJECT_ID/setters.yaml. Personalizza questo progetto sostituendo i seguenti setter:
    # Copyright 2021 Google LLC
    #
    # Licensed under the Apache License, Version 2.0 (the "License");
    # you may not use this file except in compliance with the License.
    # You may obtain a copy of the License at
    #
    #      http://www.apache.org/licenses/LICENSE-2.0
    #
    # Unless required by applicable law or agreed to in writing, software
    # distributed under the License is distributed on an "AS IS" BASIS,
    # WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
    # See the License for the specific language governing permissions and
    # limitations under the License.
    apiVersion: v1
    kind: ConfigMap
    metadata:
      name: setters
    data:
      folder-name: name.of.folder
      project-id: project-id
      # These defaults can be kept
      folder-namespace: hierarchy
      networking-namespace: networking
    
    Imposta i valori seguenti:
    • project-id: l'ID progetto che hai scelto per archiviare le esportazioni del log (LOGGING_PROJECT_ID)
    • folder-name l'ID della cartella che deve contenere il progetto di logging. Le cartelle sono precedute dal nome della cartella principale, ad esempio la cartella shared nell'ambiente dev avrà l'ID dev.shared.
  3. Esegui il commit delle modifiche per attivare la creazione di progetti:
    git add ./landing-zone/projects/${LOGGING_PROJECT_ID}/
    git commit -m "Add logging project"
    git push
    

Esporta i log in BigQuery

Esportando i log in BigQuery, puoi conservarli per un'analisi successiva. Questo progetto include la creazione di un set di dati BigQuery per archiviare i log e la configurazione dell'esportazione in quel set di dati.

  1. Aggiungi il progetto base per il logging alla zona di destinazione:
    kpt pkg get https://github.com/GoogleCloudPlatform/blueprints.git/catalog/log-export/org/bigquery-export@main ./landing-zone/logging/bigquery-export
  2. Apri il file landing-zone/logging/bigquery-export/setters.yaml. Personalizza questo progetto sostituendo l'ID progetto:
    # Copyright 2021 Google LLC
    #
    # Licensed under the Apache License, Version 2.0 (the "License");
    # you may not use this file except in compliance with the License.
    # You may obtain a copy of the License at
    #
    #      http://www.apache.org/licenses/LICENSE-2.0
    #
    # Unless required by applicable law or agreed to in writing, software
    # distributed under the License is distributed on an "AS IS" BASIS,
    # WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
    # See the License for the specific language governing permissions and
    # limitations under the License.
    apiVersion: v1
    kind: ConfigMap
    metadata:
      name: setters
      annotations:
        config.kubernetes.io/local-config: "true"
    data:
      # This is required
      project-id: my-project-id
      # These defaults can be left unchanged
      namespace: logging
      dataset-description: BigQuery audit logs for organization
      dataset-location: US
      dataset-name: audit-logs
      default-table-expiration-ms: "3600000"
      delete-contents-on-destroy: "false"
      filter: ""
    
    Imposta i valori seguenti:
    • project-id: l'ID progetto che hai scelto per l'archiviazione dei log (LOGGING_PROJECT_ID)
  3. Esegui il commit del progetto base per creare l'esportazione del log.
    git add ./landing-zone/logging/
    git commit -m "Add log export to BigQuery"
    git push

Verificare l'esportazione dei log

Puoi verificare che l'esportazione del log sia stata configurata correttamente come segue:

  • Conferma della creazione del progetto:
    kubectl describe project ${LOGGING_PROJECT} -n projects
    gcloud projects describe ${LOGGING_PROJECT_ID}
    
  • Recupero dello stato delle risorse nello spazio dei nomi logging:
    kubectl get bigquerydatasets,iampolicymembers,logginglogsinks -n logging -o yaml \
      | grep "^    name: \|message"
  • Recupero dello stato dell'esportazione dei log tramite l'interfaccia a riga di comando gcloud (il nuovo sink dovrebbe essere visualizzato nell'elenco):
    gcloud logging sinks list --organization=${ORG_ID}
  • Dopo aver configurato il sink per un po' di tempo, verifica che i log stiano confluendo in BigQuery:

    # List tables
    bq ls --project_id ${LOGGING_PROJECT_ID} bqlogexportdataset
    
    # Query a table
    # Change this to a result of "bq ls" above so that the name matches one of your tables
    TABLE_OF_INTEREST=git_sync_20201130
    bq query --project_id ${LOGGING_PROJECT_ID} "SELECT * FROM bqlogexportdataset.${TABLE_OF_INTEREST} LIMIT 2"
    

Risolvere i problemi

Rete predefinita

Quando crei il controller di configurazione, potresti ricevere un errore che indica che la rete predefinita non è disponibile:

Error 400: Project "" has no network named "default"., badRequest\n\n  on main.tf line 35, in resource "google_container_cluster" "acp_cluster"

Questo errore si verifica perché Config Controller dipende dalla rete predefinita. Per risolvere il problema, devi creare una nuova rete predefinita:

gcloud compute networks create default --subnet-mode=auto

Idratazione e Cloud Build

Come parte del progetto base GitOps, hai creato un trigger di Cloud Build che monitora il repository di origine per individuare eventuali modifiche e:

  1. Convalida i contenuti di queste modifiche utilizzando le funzioni kpt
  2. Genera la configurazione "idratata" finale, che viene salvata in un repository di deployment e applicata al tuo cluster tramite Config Sync.

Questa pipeline di Cloud Build può essere monitorata dalla console o tramite gcloud. Questo comando gcloud può essere usato per recuperare lo stato di build più recente:

FILTER="source.repo_source.commit_sha=$(git rev-parse HEAD)"
# You can poll on this command until status is either SUCCESS or FAILURE
gcloud builds list --project=${PROJECT_ID} --filter=${FILTER}

BUILD_ID=$(gcloud builds list --project=${PROJECT_ID} --filter=${FILTER} --format='get(id)' | head -n 1)
# View logs for your run. You can use this to debug errors
gcloud builds log --project=${PROJECT_ID} $BUILD_ID

Ramo principale Git non creato

A seconda del client git utilizzato e della configurazione locale del client, è possibile che non venga creato un ramo principale quando provi per la prima volta a salvare il progetto base gitops in git. Per risolvere il problema, puoi creare un ramo principale nel tuo repository Git oppure specificare il nome del ramo alternativo che vuoi utilizzare nel campo syncBranch nell'oggetto ConfigManagement, seguito dalla riapplicazione del progetto base.

Esecuzione locale

Se vuoi un feedback più rapido sui problemi di quello fornito dalla pipeline di Cloud Build, puoi usare kpt per eseguire la pipeline in locale con questo comando (eseguito dalla radice del repository di origine):

kpt fn render ./landing-zone/

Campi e risorse immutabili

Alcuni campi delle risorse Google Cloud sottostanti sono immutabili, ad esempio gli ID progetto o il nome della rete VPC. Config Connector bloccherà le modifiche in questi campi e non sarà in grado di applicarle. Se vuoi modificare uno di questi campi immutabili, devi prima eliminare la risorsa originale (tramite Git) prima di riaggiungerla con i nuovi valori preferiti.

Deployment e Config Sync

Il repository "deployment" contiene risorse completamente idratate che definiscono la tua zona di destinazione. Queste risorse vengono sincronizzate con Config Controller utilizzando Config Sync. Puoi verificare la presenza di errori in questo processo di sincronizzazione utilizzando il comando a riga di comando nomos:

nomos status

Fatturazione

Il progetto della zona di destinazione configurerà automaticamente le autorizzazioni di fatturazione corrette per la gestione della fatturazione all'interno della tua organizzazione. Se i tuoi progetti non possono essere associati al tuo account di fatturazione, è possibile che l'account di fatturazione esista al di fuori della tua organizzazione. Di conseguenza, dovrai concedere direttamente all'account di servizio projects le autorizzazioni per gestire l'account di fatturazione:

export PROJECTS_SA="$(kubectl get ConfigConnectorContext -n projects -o jsonpath='{.items[0].spec.googleServiceAccount}')"
gcloud alpha billing accounts add-iam-policy-binding $BILLING_ACCOUNT \
  --role=roles/billing.admin \
  --member="serviceAccount:${PROJECTS_SA}"

Esegui la pulizia

Se decidi di non usare più la zona di destinazione, devi rimuovere tutte le risorse create. È necessario rimuovere le risorse da Config Controller prima di eliminare lo stesso Config Controller.

In alternativa, se vuoi conservare le risorse della zona di destinazione abbandonando il flusso di lavoro dichiarativo, puoi facoltativamente passare direttamente all'eliminazione di Config Controller (anche se non è consigliabile).

Rimozione delle risorse in corso...

Puoi eliminare le risorse semplicemente rimuovendo i relativi file associati dal repository Git delle zone di destinazione. Questa opzione funziona per singole risorse o per interi pacchetti.

Tuttavia, non puoi eliminare l'intera zona di destinazione in una sola volta (per evitare eliminazioni accidentali). Dovrai in dettaglio le risorse della zona di destinazione in pochi passaggi:

# Delete downstream resources
git rm -rf ./landing-zone/logging/
git rm -rf ./landing-zone/network/
git commit -m "Delete downstream resources"
git push
# Confirm Config Sync successfully applies

# Delete projects
git rm -rf ./landing-zone/projects/
git commit -m "Delete projects"
git push
# Confirm Config Sync successfully applies

# Delete folders and organization policies, but leave the policy template (see below for why)
git rm -rf ./landing-zone/hierarchy/
find ./landing-zone/policies/ -type f -not \( -name 'folder-naming-constraint-template.yaml' \) -delete
git add ./landing-zone/
git commit -m "Delete hierarchy and organization policies"
git push
# Confirm Config Sync successfully applies

# Delete landing zone except for 1 cluster-scoped resource
# (folder-naming-constraint-template.yaml) and 1 empty namespace (projects.yaml).
# See /anthos-config-management/docs/reference/errors#knv2006
find ./landing-zone/ -type f -not \( -name 'folder-naming-constraint-template.yaml' -or -name 'projects.yaml' \) -delete
cat <<EOF > ./landing-zone/namespaces/projects.yaml
apiVersion: v1
kind: Namespace
metadata:
  name: projects
EOF
git add ./landing-zone/
git commit -m "Delete all landing zone resources except 1 cluster-scoped resource and 1 namespace"
git push
# Confirm Config Sync successfully applies

# Delete remaining resources
git rm -rf ./landing-zone/
git commit -m "Delete remaining resources"
git push

Eliminazione di Config Controller

gcloud anthos config controller delete --location=us-central1 ${CONFIG_CONTROLLER_NAME}