Gestione dell'infrastruttura come codice con Terraform, Cloud Build e GitOps

Questo tutorial spiega come gestire l'infrastruttura come codice con Terraform e Cloud Build utilizzando la popolare metodologia GitOps. Il termine GitOps è stato coniato per la prima volta da Weaveworks e il suo concetto chiave è l'utilizzo di un repository Git per archiviare lo stato dell'ambiente che desideri. Terraform è uno strumento HashiCorp che consente di creare, modificare e migliorare in modo prevedibile l'infrastruttura cloud utilizzando il codice. In questo tutorial utilizzerai Cloud Build (un servizio di integrazione continua) per applicare automaticamente i manifest Terraform al tuo ambiente. Trusted Cloud by S3NS

Questo tutorial è rivolto a sviluppatori e operatori che cercano una strategia elegante per apportare modifiche prevedibili all'infrastruttura. L'articolo presuppone che tu abbia dimestichezza con Trusted Cloud, Linux e GitHub.

I report State of DevOps hanno identificato le funzionalità che migliorano le prestazioni di distribuzione del software. Questo tutorial ti aiuterà a utilizzare le seguenti funzionalità:

Architettura

Per dimostrare in che modo questo tutorial applica le pratiche GitOps per la gestione delle esecuzioni di Terraform, considera il seguente diagramma dell'architettura. Tieni presente che utilizza i rami GitHub dev e prod per rappresentare gli ambienti effettivi. Questi ambienti sono definiti dalle reti Virtual Private Cloud (VPC) dev e prod, rispettivamente, in un progetto Trusted Cloud .

Infrastruttura con ambienti di sviluppo e produzione.

Il processo inizia quando esegui il push del codice Terraform nel ramo dev o prod. In questo scenario, Cloud Build attiva e poi applica i manifest Terraform per raggiungere lo stato desiderato nel rispettivo ambiente. D'altra parte, quando esegui il push del codice Terraform su un altro ramo, ad esempio su un ramo delle funzionalità, Cloud Build viene eseguito per eseguire terraform plan, ma non viene applicato nulla a nessun ambiente.

Idealmente, gli sviluppatori o gli operatori devono presentare proposte di infrastruttura ai rami non protetti e poi inviarle tramite richieste pull. L'app GitHub di Cloud Build, descritta più avanti in questo tutorial, attiva automaticamente i job di build e collega i report terraform plan a queste richieste di pull. In questo modo, puoi discutere e rivedere le potenziali modifiche con i collaboratori e aggiungere commit di follow-up prima che le modifiche vengano unite al ramo di base.

Se non vengono sollevati problemi, devi prima unire le modifiche al ramo dev. Questa unione attiva un deployment dell'infrastruttura nell'ambiente dev, consentendoti di testarlo. Dopo aver testato e aver verificato il deployment, devi unire il ramo dev al ramo prod per attivare l'installazione dell'infrastruttura nell'ambiente di produzione.

Obiettivi

  • Configura il repository GitHub.
  • Configura Terraform in modo da archiviare lo stato in un bucket Cloud Storage.
  • Concedi le autorizzazioni al account di servizio Cloud Build.
  • Connetti Cloud Build al tuo repository GitHub.
  • Modifica la configurazione dell'ambiente in un ramo delle funzionalità.
  • Promuovi le modifiche nell'ambiente di sviluppo.
  • Promuovi le modifiche all'ambiente di produzione.

Costi

In questo documento utilizzi i seguenti componenti fatturabili di Trusted Cloud by S3NS:

Per generare una stima dei costi in base all'utilizzo previsto, utilizza il calcolatore prezzi.

I nuovi utenti di Trusted Cloud potrebbero avere diritto a una prova gratuita.

Al termine delle attività descritte in questo documento, puoi evitare l'addebito di ulteriori costi eliminando le risorse che hai creato. Per ulteriori informazioni, vedi Pulizia.

Prerequisiti

  1. In the Trusted Cloud console, on the project selector page, select or create a Trusted Cloud project.

    Go to project selector

  2. Verify that billing is enabled for your Trusted Cloud project.

  3. Recupera l'ID del progetto appena selezionato: 
    gcloud config get-value project
     Se questo comando non restituisce l'ID progetto, configura la shell locale in modo che utilizzi il tuo progetto. Sostituisci PROJECT_ID con l'ID progetto. 
    gcloud config set project PROJECT_ID
  4. Abilita le API richieste: 
    gcloud services enable cloudbuild.googleapis.com compute.googleapis.com
     Il completamento di questo passaggio potrebbe richiedere alcuni minuti.
  5. Configura le tue credenziali Git con il tuo nome e indirizzo email: 
    git config --global user.email "YOUR_EMAIL_ADDRESS"
git config --global user.name "YOUR_NAME"
    Git utilizza queste informazioni per identificarti come autore dei commit che crei nella shell locale.

    6. Configurazione del repository GitHub

    In questo tutorial utilizzi un singolo repository Git per definire la tua infrastruttura cloud. Orchestri questa infrastruttura con rami diversi corrispondenti a diversi ambienti:

    • Il ramo dev contiene le ultime modifiche applicate all'ambiente di sviluppo.
    • Il ramo prod contiene le ultime modifiche applicate all'ambiente di produzione.

    Con questa infrastruttura, puoi sempre fare riferimento al repository per sapere quale configurazione è prevista in ogni ambiente e per proporre nuove modifiche unendole prima all'ambiente dev. Quindi promuovi le modifiche unendo il ramo dev nel ramo prod successivo.

    Per iniziare, esegui il fork del repository solutions-terraform-cloudbuild-gitops.

    1. Su GitHub, vai a https://github.com/GoogleCloudPlatform/solutions-terraform-cloudbuild-gitops.git.

    2. Nell'angolo in alto a destra della pagina, fai clic su Fork.

      Creazione di un fork di un repository.

      Ora hai una copia del repository solutions-terraform-cloudbuild-gitops con i file di origine.

    1. Clona il repository creato mediante fork, sostituendo YOUR_GITHUB_USERNAME con il tuo nome utente GitHub:

      cd ~
git clone https://github.com/YOUR_GITHUB_USERNAME/solutions-terraform-cloudbuild-gitops.git
cd ~/solutions-terraform-cloudbuild-gitops

    Il codice in questo repository è strutturato nel seguente modo:

    • La cartella environments/ contiene sottocartelle che rappresentano ambienti, come dev e prod, che forniscono una separazione logica tra i carichi di lavoro in diverse fasi di maturità, sviluppo e produzione, rispettivamente. Sebbene sia consigliabile che questi ambienti siano il più simili possibile, ogni sottocartella ha una propria configurazione Terraform per garantire che possano avere impostazioni uniche, se necessario.

    • La cartella modules/ contiene moduli Terraform incorporati. Questi moduli rappresentano raggruppamenti logici di risorse correlate e vengono utilizzati per condividere il codice in ambienti diversi.

    • Il file cloudbuild.yaml è un file di configurazione di compilazione che contiene istruzioni per Cloud Build, ad esempio come eseguire attività in base a una serie di passaggi. Questo file specifica un'esecuzione condizionale a seconda del ramo da cui Cloud Build recupera il codice, ad esempio:

      • Per i rami dev e prod, vengono eseguiti i seguenti passaggi:

        1. terraform init
        2. terraform plan
        3. terraform apply

      • Per qualsiasi altro ramo, vengono eseguiti i seguenti passaggi:

        1. terraform init per tutte le sottocartelle di environments
        2. terraform plan per tutte le sottocartelle di environments

    Per garantire che le modifiche proposte siano appropriate per ogni ambiente, terraform init e terraform plan vengono eseguiti per tutte le sottocartelle environments. Prima di unire la richiesta pull, puoi esaminare i piani per assicurarti, ad esempio, che l'accesso non venga concesso a un'entità non autorizzata.

    Configurazione di Terraform per archiviare lo stato in un bucket Cloud Storage

    Per impostazione predefinita, Terraform archivia lo stato localmente in un file denominato terraform.tfstate. Questa configurazione predefinita può rendere difficile l'utilizzo di Terraform per i team, soprattutto quando molti utenti eseguono Terraform contemporaneamente e ogni macchina ha la propria interpretazione dell'infrastruttura attuale.

    Per aiutarti a evitare questi problemi, questa sezione configura uno stato remoto che punta a un bucket Cloud Storage. Lo stato remoto è una funzionalità dei backend e, in questo tutorial, è configurato nei file backend.tf, ad esempio:

    # Copyright 2019 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
#
#     https://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.


terraform {
  backend "gcs" {
    bucket = "PROJECT_ID-tfstate"
    prefix = "env/dev"
  }
}

    Nei passaggi successivi, creerai un bucket Cloud Storage e modificherai alcuni file in modo che puntino al nuovo bucket e al tuo progetto. Trusted Cloud

  6. Crea il bucket Cloud Storage:

    PROJECT_ID=$(gcloud config get-value project)
gcloud storage buckets create gs://${PROJECT_ID}-tfstate
1. Attiva il controllo delle versioni degli oggetti per conservare la cronologia dei tuoi deployment:

```sh
gcloud storage buckets update gs://${PROJECT_ID}-tfstate --versioning
```

Enabling Object Versioning increases
[storage costs](/storage/pricing){: track-type="tutorial" track-name="internalLink" track-metadata-position="body" },
which you can mitigate by configuring
[Object Lifecycle Management](/storage/docs/lifecycle){: track-type="tutorial" track-name="internalLink" track-metadata-position="body" } 
to delete old state versions.

  1. Sostituisci il segnaposto PROJECT_ID con l'ID progetto sia nel file terraform.tfvars che in quello backend.tf:

    cd ~/solutions-terraform-cloudbuild-gitops
sed -i s/PROJECT_ID/$PROJECT_ID/g environments/*/terraform.tfvars
sed -i s/PROJECT_ID/$PROJECT_ID/g environments/*/backend.tf

    Su OS X/macOS, potresti dover aggiungere due virgolette ("") dopo sed -i, come segue:

    cd ~/solutions-terraform-cloudbuild-gitops
sed -i "" s/PROJECT_ID/$PROJECT_ID/g environments/*/terraform.tfvars
sed -i "" s/PROJECT_ID/$PROJECT_ID/g environments/*/backend.tf

  2. Controlla se tutti i file sono stati aggiornati:

    git status

    L'output ha il seguente aspetto:

    On branch dev
Your branch is up-to-date with 'origin/dev'.
Changes not staged for commit:
 (use "git add <file>..." to update what will be committed)
 (use "git checkout -- <file>..." to discard changes in working directory)
       modified:   environments/dev/backend.tf
       modified:   environments/dev/terraform.tfvars
       modified:   environments/prod/backend.tf
       modified:   environments/prod/terraform.tfvars
no changes added to commit (use "git add" and/or "git commit -a")

  3. Esegui il commit e il push delle modifiche:

    git add --all
git commit -m "Update project IDs and buckets"
git push origin dev

    A seconda della configurazione di GitHub, dovrai autenticarti per eseguire il push delle modifiche precedenti.

Concessione delle autorizzazioni al account di servizio Cloud Build

Per consentire al service account Cloud Build di eseguire script Terraform con lo scopo di gestire le risorse Trusted Cloud , devi concedergli l'accesso appropriato al tuo progetto. Per semplicità, in questo tutorial viene concesso l'accesso editor del progetto. Tuttavia, quando il ruolo Editor progetto dispone di un'autorizzazione ad ampio raggio, negli ambienti di produzione devi seguire le best practice di sicurezza IT della tua azienda, che in genere prevedono l'accesso con privilegi minimi. Per le best practice di sicurezza, vedi Verifica esplicita di ogni tentativo di accesso.

  1. Nella shell locale, recupera l'email dell'account di servizio Cloud Build del progetto:

    CLOUDBUILD_SA="$(gcloud projects describe $PROJECT_ID \
    --format 'value(projectNumber)')@cloudbuild.s3ns-system.iam.gserviceaccount.com"

  2. Concedi l'accesso richiesto al account di servizio Cloud Build:

    gcloud projects add-iam-policy-binding $PROJECT_ID \
    --member serviceAccount:$CLOUDBUILD_SA --role roles/editor

Connessione diretta di Cloud Build al repository GitHub

Questa sezione mostra come installare l'app GitHub di Cloud Build. Questa installazione ti consente di connettere il repository GitHub al tuo progettoTrusted Cloud in modo che Cloud Build possa applicare automaticamente i manifest Terraform ogni volta che crei un nuovo ramo o esegui il push del codice su GitHub.

I passaggi riportati di seguito forniscono istruzioni per installare l'app solo per il repository solutions-terraform-cloudbuild-gitops, ma puoi scegliere di installarla per più repository o per tutti.

  1. Vai alla pagina GitHub Marketplace dell'app Cloud Build:

    Apri la pagina dell'app Cloud Build

    • Se è la prima volta che configuri un'app in GitHub, fai clic su Configura con Google Cloud Build in fondo alla pagina. Poi fai clic su Concedi a questa app l'accesso al tuo account GitHub.
    • Se non è la prima volta che configuri un'app in GitHub, fai clic su Configura l'accesso. Si apre la pagina Applicazioni del tuo account personale.

  2. Fai clic su Configura nella riga Cloud Build.

  3. Seleziona Solo repository selezionati, quindi seleziona solutions-terraform-cloudbuild-gitops per connetterti al repository.

  4. Fai clic su Salva o Installa. L'etichetta del pulsante cambia a seconda del tuo flusso di lavoro. Vieni reindirizzato a Trusted Cloud by S3NS per continuare l'installazione.

  5. Accedi con il tuo account Trusted Cloud by S3NS . Se richiesto, autorizza l'integrazione di Cloud Build con GitHub.

  6. Nella pagina Cloud Build, seleziona il tuo progetto. Viene visualizzata una procedura guidata.

  7. Nella sezione Seleziona repository, seleziona il tuo account GitHub e il repository solutions-terraform-cloudbuild-gitops.

  8. Se accetti i termini e le condizioni, seleziona la casella di controllo, quindi fai clic su Connetti.

  9. Nella sezione Crea un trigger, fai clic su Crea un trigger:

    1. Aggiungi un nome per l'attivatore, ad esempio push-to-branch. Prendi nota del nome di questo trigger perché ti servirà in seguito.
    2. Nella sezione Evento, seleziona Push al ramo.
    3. Nella sezione Origine, seleziona .* nel campo Branch.
    4. Fai clic su Crea.

L'app GitHub di Cloud Build è ora configurata e il tuo repository GitHub è collegato al tuo progetto Trusted Cloud . D'ora in poi, le modifiche al repository GitHub attivano le esecuzioni di Cloud Build, che riportano i risultati a GitHub utilizzando GitHub Checks.

Modifica della configurazione dell'ambiente in un ramo della nuova funzionalità

A questo punto, la maggior parte dell'ambiente è configurata. È quindi il momento di apportare alcune modifiche al codice nel tuo ambiente di sviluppo.

  1. Su GitHub, vai alla pagina principale del repository creato mediante fork.

    https://github.com/YOUR_GITHUB_USERNAME/solutions-terraform-cloudbuild-gitops

  2. Assicurati di trovarti nel ramo dev.

  3. Per aprire il file per la modifica, vai al file modules/firewall/main.tf e fai clic sull'icona a forma di matita.

  4. Alla riga 30, correggi l'errore ortografico "http-server2" nel campo target_tags.

    Il valore deve essere "http-server".

  5. Aggiungi un messaggio di commit in fondo alla pagina, ad esempio "Fixing http firewall target", e seleziona Crea un nuovo ramo per questo commit e avvia una richiesta di pull.

  6. Fai clic su Proponi modifiche.

  7. Nella pagina seguente, fai clic su Crea richiesta di pull per aprire una nuova richiesta di pull con la tua modifica.

    Dopo l'apertura della richiesta pull, viene avviato automaticamente un job Cloud Build.

  8. Fai clic su Mostra tutti i controlli e attendi che il controllo diventi verde.

    Mostra tutti i controlli in una richiesta pull.

  9. Fai clic su Dettagli per visualizzare ulteriori informazioni, incluso l'output di terraform plan nel link Visualizza ulteriori dettagli su Google Cloud Build.

Non unire ancora la tua richiesta di pull.

Tieni presente che il job Cloud Build ha eseguito la pipeline definita nel file cloudbuild.yaml. Come discusso in precedenza, questa pipeline ha comportamenti diversi a seconda del ramo recuperato. La build controlla se la variabile $BRANCH_NAME corrisponde a una cartella di ambiente. In questo caso, Cloud Build esegue terraform plan per quell'ambiente. In caso contrario, Cloud Build esegue terraform plan per tutti gli ambienti per assicurarsi che la modifica proposta sia appropriata per tutti. Se l'esecuzione di uno di questi piani non va a buon fine, la build non riesce.

- id: 'tf plan'
  name: 'hashicorp/terraform:1.0.0'
  entrypoint: 'sh'
  args: 
  - '-c'
  - | 
      if [ -d "environments/$BRANCH_NAME/" ]; then
        cd environments/$BRANCH_NAME
        terraform plan
      else
        for dir in environments/*/
        do 
          cd ${dir}   
          env=${dir%*/}
          env=${env#*/}  
          echo ""
          echo "*************** TERRAFORM PLAN ******************"
          echo "******* At environment: ${env} ********"
          echo "*************************************************"
          terraform plan || exit 1
          cd ../../
        done
      fi

Analogamente, il comando terraform apply viene eseguito per i rami dell'ambiente, ma viene completamente ignorato in tutti gli altri casi. In questa sezione hai inviato una modifica del codice a un nuovo ramo, quindi non sono stati applicati deployment dell'infrastruttura al tuo Trusted Cloud progetto.

- id: 'tf apply'
  name: 'hashicorp/terraform:1.0.0'
  entrypoint: 'sh'
  args: 
  - '-c'
  - | 
      if [ -d "environments/$BRANCH_NAME/" ]; then
        cd environments/$BRANCH_NAME      
        terraform apply -auto-approve
      else
        echo "***************************** SKIPPING APPLYING *******************************"
        echo "Branch '$BRANCH_NAME' does not represent an official environment."
        echo "*******************************************************************************"
      fi

Imposizione dell'esecuzione riuscita di Cloud Build prima dell'unione dei rami

Per assicurarti che le unioni possano essere applicate solo quando le rispettive esecuzioni di Cloud Build hanno esito positivo, procedi nel seguente modo:

  1. Su GitHub, vai alla pagina principale del repository creato mediante fork.

    https://github.com/YOUR_GITHUB_USERNAME/solutions-terraform-cloudbuild-gitops

  2. Sotto il nome del repository, fai clic su Impostazioni.

  3. Nel menu a sinistra, fai clic su Rami.

  4. In Regole di protezione dei rami, fai clic su Aggiungi regola.

  5. In Pattern nome ramo, digita dev.

  6. Nella sezione Proteggi rami corrispondenti, seleziona Richiedi superamento dei controlli di stato prima dell'unione.

  7. Cerca il nome del trigger di Cloud Build creato in precedenza.

  8. Fai clic su Crea.

  9. Ripeti i passaggi da 3 a 7, impostando Pattern nome ramo su prod.

Questa configurazione è importante per proteggere sia i rami dev che prod. Ciò significa che i commit devono prima essere inviati a un altro ramo e solo dopo possono essere uniti al ramo protetto. In questo tutorial, la protezione richiede che l'esecuzione di Cloud Build vada a buon fine per consentire l'unione.

Promuovere le modifiche all'ambiente di sviluppo

Hai una richiesta di pull in attesa di essere unita. È il momento di applicare lo stato che vuoi al tuo ambiente dev.

  1. Su GitHub, vai alla pagina principale del repository creato mediante fork.

    https://github.com/YOUR_GITHUB_USERNAME/solutions-terraform-cloudbuild-gitops

  2. Sotto il nome del repository, fai clic su Pull request.

  3. Fai clic sulla richiesta di pull appena creata.

  4. Fai clic su Unisci richiesta di pull e poi su Conferma unione.

    Conferma l&#39;unione.

  5. Verifica che sia stata attivata una nuova build di Cloud Build:

    Vai alla pagina Cloud Build

  6. Apri la build e controlla i log.

    Al termine della build, visualizzerai un risultato simile al seguente:

    Step #3 - "tf apply": external_ip = EXTERNAL_IP_VALUE
Step #3 - "tf apply": firewall_rule = dev-allow-http
Step #3 - "tf apply": instance_name = dev-apache2-instance
Step #3 - "tf apply": network = dev
Step #3 - "tf apply": subnet = dev-subnet-01

  7. Copia EXTERNAL_IP_VALUE e apri l'indirizzo in un browser web.

    http://EXTERNAL_IP_VALUE

    Il provisioning potrebbe richiedere alcuni secondi per l'avvio della VM e la propagazione della regola firewall. Alla fine, nel browser web vedrai Environment: dev.

  8. Vai al file di stato di Terraform nel bucket Cloud Storage.

    https://storage.cloud.google.com/PROJECT_ID-tfstate/env/dev/default.tfstate

Promozione delle modifiche all'ambiente di produzione

Ora che hai testato completamente l'ambiente di sviluppo, puoi promuovere il codice dell'infrastruttura in produzione.

  1. Su GitHub, vai alla pagina principale del repository creato mediante fork.

    https://github.com/YOUR_GITHUB_USERNAME/solutions-terraform-cloudbuild-gitops

  2. Sotto il nome del repository, fai clic su Pull request.

  3. Fai clic su Nuova richiesta pull.

  4. Per il repository di base, seleziona il repository appena creato.

  5. Per base, seleziona prod dal tuo repository di base. Per confrontare, seleziona dev.

    Confronta le modifiche.

  6. Fai clic su Crea richiesta di pull.

  7. Per il titolo, inserisci un titolo come Promoting networking changes e poi fai clic su Crea richiesta di pull.

  8. Esamina le modifiche proposte, inclusi i dettagli terraform plan di Cloud Build, poi fai clic su Unisci richiesta di pull.

  9. Fai clic su Conferma unione.

  10. Nella console Trusted Cloud , apri la pagina Cronologia build per vedere le modifiche applicate all'ambiente di produzione:

    Vai alla pagina Cloud Build

  11. Attendi il completamento della build, quindi controlla i log.

    Alla fine dei log, vedrai un messaggio simile a questo:

    Step #3 - "tf apply": external_ip = EXTERNAL_IP_VALUE
Step #3 - "tf apply": firewall_rule = prod-allow-http
Step #3 - "tf apply": instance_name = prod-apache2-instance
Step #3 - "tf apply": network = prod
Step #3 - "tf apply": subnet = prod-subnet-01

  12. Copia EXTERNAL_IP_VALUE e apri l'indirizzo in un browser web.

    http://EXTERNAL_IP_VALUE

    Il provisioning potrebbe richiedere alcuni secondi per l'avvio della VM e la propagazione della regola firewall. Alla fine, nel browser web viene visualizzato Environment: prod.

  13. Vai al file di stato di Terraform nel bucket Cloud Storage.

    https://storage.cloud.google.com/PROJECT_ID-tfstate/env/prod/default.tfstate

Hai configurato correttamente una pipeline di infrastruttura come codice serverless in Cloud Build. In futuro, potresti provare a:

  • Aggiungi implementazioni per casi d'uso separati.
  • Crea altri ambienti per soddisfare le tue esigenze.
  • Utilizza un progetto per ambiente anziché un VPC per ambiente.

Esegui la pulizia

Al termine del tutorial, esegui la pulizia delle risorse create suTrusted Cloud in modo che non vengano addebitate in futuro.

Elimina il progetto

  1. In the Trusted Cloud console, go to the Manage resources page.

    Go to Manage resources

  2. In the project list, select the project that you want to delete, and then click Delete.
  3. In the dialog, type the project ID, and then click Shut down to delete the project.

Eliminazione del repository GitHub

Per evitare di bloccare nuove richieste di pull nel repository GitHub, puoi eliminare le regole di protezione dei rami:

  1. In GitHub, vai alla pagina principale del repository di cui hai creato un fork.
  2. Sotto il nome del repository, fai clic su Impostazioni.
  3. Nel menu a sinistra, fai clic su Rami.
  4. Nella sezione Regole di protezione dei rami, fai clic sul pulsante Elimina per le righe dev e prod.

Se vuoi, puoi disinstallare completamente l'app Cloud Build da GitHub:

  1. Vai alle impostazioni delle applicazioni di GitHub.

    Vai alla pagina delle applicazioni GitHub

  2. Nella scheda App GitHub installate, fai clic su Configura nella riga Cloud Build. Quindi, nella sezione Zona di pericolo, fai clic sul pulsante Disinstalla nella riga Disinstalla Google Cloud Builder.

    Nella parte superiore della pagina viene visualizzato il messaggio "Tutto è pronto. È stato messo in coda un job per disinstallare Google Cloud Build."

  3. Nella scheda App GitHub autorizzate, fai clic sul pulsante Revoca nella riga Google Cloud Build, quindi su Ho capito, revoca l'accesso nel popup.

Se non vuoi conservare il repository GitHub:

  1. In GitHub, vai alla pagina principale del repository di cui hai creato un fork.
  2. Sotto il nome del repository, fai clic su Impostazioni.
  3. Scorri verso il basso fino alla Zona pericolosa.
  4. Fai clic su Elimina questo repository e segui i passaggi per la conferma.

Passaggi successivi