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 preferisci. Terraform è uno strumento di 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 di Google Cloud) per applicare automaticamente i manifest di Terraform al tuo ambiente.

Questo tutorial è rivolto a sviluppatori e operatori che cercano una strategia elegante per apportare modifiche prevedibili all'infrastruttura. L'articolo presuppone che tu abbia familiarità con Google 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 come questo tutorial applica le pratiche GitOps per la gestione delle esecuzioni di Terraform, considera il seguente diagramma di architettura. Tieni presente che utilizza i branch di GitHub, dev e prod, per rappresentare gli ambienti effettivi. Questi ambienti sono definiti da reti Virtual Private Cloud (VPC), dev e prod, in un progetto Google 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 in un altro ramo, ad esempio in un ramo di 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 pull request. L'app GitHub Cloud Build, discussa più avanti in questo tutorial, attiva automaticamente i job di compilazione 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 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 eseguito il test e avere verificato l'integrità di quanto è stato implementato, devi unire il ramo dev al ramo prod per attivare l'installazione dell'infrastruttura nell'ambiente di produzione.

Obiettivi

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

Costi

In questo documento utilizzi 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 potrebbero essere idonei per una prova gratuita.

Al termine delle attività descritte in questo documento, puoi evitare la fatturazione continua eliminando le risorse che hai creato. Per ulteriori informazioni, consulta la sezione Pulizia.

Prerequisiti

  1. Sign in to your Google Cloud account. If you're new to Google Cloud, create an account to evaluate how our products perform in real-world scenarios. New customers also get $300 in free credits to run, test, and deploy workloads.

  2. In the Google Cloud console, on the project selector page, select or create a Google Cloud project.

    Go to project selector

  3. Make sure that billing is enabled for your Google Cloud project.

  4. In the Google Cloud console, on the project selector page, select or create a Google Cloud project.

    Go to project selector

  5. Make sure that billing is enabled for your Google Cloud project.

  6. In the Google Cloud console, activate Cloud Shell.

    Activate Cloud Shell

    At the bottom of the Google Cloud console, a Cloud Shell session starts and displays a command-line prompt. Cloud Shell is a shell environment with the Google Cloud CLI already installed and with values already set for your current project. It can take a few seconds for the session to initialize.

  7. In Cloud Shell, recupera l'ID del progetto appena selezionato: 
    gcloud config get-value project
     Se questo comando non restituisce l'ID progetto, configura Cloud Shell per utilizzare il tuo progetto. Sostituisci PROJECT_ID con l'ID del tuo progetto. 
    gcloud config set project PROJECT_ID
  8. Abilita le API richieste: 
    gcloud services enable cloudbuild.googleapis.com compute.googleapis.com
     Il completamento di questo passaggio potrebbe richiedere alcuni minuti.
  9. Se non hai mai utilizzato Git in Cloud Shell, configuralo 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 in Cloud Shell.

Configurazione del repository GitHub

In questo tutorial utilizzerai un singolo repository Git per definire la tua infrastruttura cloud. Puoi orchestrare questa infrastruttura disponendo di diversi rami corrispondenti a diversi ambienti:

  • Il ramo dev contiene le modifiche più recenti 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 proporre nuove modifiche combinndole prima nell'ambiente dev. Poi promuovi le modifiche con la fusione del 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.

    Creare un fork di un repository.

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

  1. In Cloud Shell, clona questo 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 come segue:

  • 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à, rispettivamente sviluppo e produzione. Sebbene sia buona norma avere ambienti il più simili possibile, ogni sottocartella ha la propria configurazione Terraform per garantire che possano avere impostazioni univoche, se necessario.

  • La cartella modules/ contiene moduli Terraform in linea. 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 in base al 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 environments
      2. terraform plan per tutte le sottocartelle environments

Per assicurarti 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 di pull, puoi esaminare i piani per assicurarti, ad esempio, che l'accesso non venga concesso a una persona non autorizzata.

Configurare 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ò complicare l'utilizzo di Terraform per i team, soprattutto quando molti utenti eseguono Terraform contemporaneamente e ogni macchina ha la propria comprensione dell' infrastruttura attuale.

Per aiutarti a evitare questi problemi, questa sezione configura un stato remoto che rimanda 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 che seguono, creerai un bucket Cloud Storage e modificherai alcuni file in modo che rimandino al nuovo bucket e al progetto Google Cloud.

  1. In Cloud Shell, crea il bucket Cloud Storage:

    PROJECT_ID=$(gcloud config get-value project)
gsutil mb gs://${PROJECT_ID}-tfstate
    1. Abilita 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 nei file terraform.tfvars che 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, potrebbe essere necessario 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 è il seguente:

      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 spingere le modifiche precedenti.

    Concedere le autorizzazioni all'account di servizio Cloud Build

    Per consentire all'account di servizio Cloud Build di eseguire script Terraform allo scopo di gestire le risorse Google Cloud, devi concedergli l'accesso appropriato al tuo progetto. Per semplicità, in questo tutorial viene concesso l'accesso come editor del progetto. Tuttavia, se il ruolo di editor del progetto dispone di un'autorizzazione di ampio raggio, negli ambienti di produzione devi seguire le best practice per la sicurezza IT della tua azienda, in genere fornendo un accesso con privilegi minimi.

    1. In Cloud Shell, recupera l'indirizzo email del account di servizio Cloud Build del tuo progetto:

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

    2. Concedi l'accesso richiesto al tuo 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 illustra come installare l'app GitHub di Cloud Build. Questa installazione ti consente di collegare il tuo repository GitHub al tuo progetto Google Cloud in modo che Cloud Build possa applicare automaticamente i tuoi 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 uno o più dei tuoi repository.

    1. Vai alla pagina di GitHub Marketplace per l'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. Quindi, fai clic su Concede 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 Applications (Applicazioni) del tuo account personale.

    2. Fai clic su Configura nella riga Cloud Build.

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

    4. Fai clic su Salva o Installa. L'etichetta del pulsante cambia in base al tuo flusso di lavoro. Verrà eseguito il reindirizzamento a Google Cloud per continuare l'installazione.

    5. Accedi con il tuo account Google Cloud. 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 solutions-terraform-cloudbuild-gitops repository.

    8. Se accetti i termini e le condizioni, seleziona la casella di controllo e poi 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 dell'attivatore, perché ti servirà in seguito.
      2. Nella sezione Evento, seleziona Push al ramo.
      3. Nella sezione Origine, seleziona .* nel campo Filiale.
      4. Fai clic su Crea.

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

    Modificare la configurazione dell'ambiente in un nuovo ramo della funzionalità

    A questo punto, la maggior parte dell'ambiente è configurata. È quindi il momento di apportare alcune modifiche al codice nell'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 essere 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. Nella riga 30, correggi l'errore ortografico "http-server2" nel campo target_tags.

      Il valore deve essere "http-server".

    5. Aggiungi un messaggio di commit nella parte inferiore della pagina, ad esempio "Correzione del target del firewall http", e seleziona Crea un nuovo ramo per questo commit e avvia una pull request.

    6. Fai clic su Proponi modifiche.

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

      Una volta aperta la richiesta di 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 al link Visualizza ulteriori dettagli su Google Cloud Build.

    Non unire ancora la richiesta pull.

    Tieni presente che il job Cloud Build ha eseguito la pipeline definita nel cloudbuild.yaml file. Come discusso in precedenza, questa pipeline ha comportamenti diversi a seconda del ramo recuperato. La compilazione verifica se la variabile $BRANCH_NAME corrisponde a una cartella dell'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 compilazione non va a buon fine.

    - 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 branch dell'ambiente, ma viene completamente ignorato in qualsiasi altro caso. In questa sezione hai inviato una modifica al codice in un nuovo ramo, pertanto non sono stati applicati deployment dell'infrastruttura al tuo progetto Google Cloud.

    - 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

    Impostare l'esecuzione di Cloud Build come obbligatoria prima dell'unione dei rami

    Per assicurarti che le unioni possano essere applicate solo quando le rispettive esecuzioni di Cloud Build sono riuscite, 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 Filiale.

    4. In Regole di protezione del ramo, fai clic su Aggiungi regola.

    5. In Pattern del nome del ramo, digita dev.

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

    7. Cerca il nome dell'attivatore Cloud Build creato in precedenza.

    8. Fai clic su Crea.

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

    Questa configurazione è importante per proteggere entrambi i rami dev e 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 sia andata a buon fine per consentire l'unione.

    Promozione delle modifiche all'ambiente di sviluppo

    Hai una richiesta di pull in attesa di essere unita. È il momento di applicare lo stato che preferisci 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 pull e poi su Conferma unione.

      Conferma l&#39;unione.

    5. Verifica che sia stato attivato un nuovo Cloud Build:

      Vai alla pagina Cloud Build

    6. Apri la compilazione e controlla i log.

      Al termine della compilazione, viene visualizzato un messaggio 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

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

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

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

    Promozione delle modifiche nell'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 sottoposto a fork.

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

      Confronta le modifiche.

    6. Fai clic su Crea richiesta pull.

    7. In title, inserisci un titolo, ad esempio Promoting networking changes, quindi fai clic su Crea pull request.

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

    9. Fai clic su Conferma unione.

    10. Nella console Google 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 viene visualizzato un messaggio simile al seguente:

      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

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

    13. Vai al file di stato 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 su Cloud Build. In futuro, ti consigliamo di provare quanto segue:

    • Aggiungi implementazioni per casi d'uso separati.
    • Crea ambienti aggiuntivi in base alle tue esigenze.
    • Utilizza un progetto per ambiente anziché un VPC per ambiente.

    Esegui la pulizia

    Al termine del tutorial, elimina le risorse che hai creato su Google Cloud in modo che non ti vengano addebitate in futuro.

    Elimina il progetto

    1. In the Google 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 le nuove richieste di pull nel tuo 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 Filiale.
    4. Nella sezione Regole per la protezione dei rami, fai clic sul pulsante Elimina sia per le righe dev sia per quelle prod.

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

    1. Vai alle impostazioni delle app 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 pericolosa, 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 la disinstallazione di 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 tuo 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 sezione Zona pericolosa.
    4. Fai clic su Elimina questo repository e segui i passaggi per la conferma.

    Passaggi successivi