Utilizzo dei suggerimenti per Infrastructure as Code

---

Panoramica

Google Cloud Policy Intelligence aiuta le aziende a comprendere e gestire i propri criteri al fine di ridurre i rischi. Con più visibilità e automazione, i clienti possono avere più sicurezza senza aumentare il carico di lavoro.

Recommender ti consente di recuperare i suggerimenti per le risorse Google Cloud , aiutandoti a migliorare la sicurezza del cloud, risparmiare sui costi e altro ancora. Per un elenco dei suggerimenti supportati, consulta la documentazione del motore per suggerimenti. Questo tutorial descrive l'utilizzo dei suggerimenti sul dimensionamento delle istanze VM e dei suggerimenti di Identity and Access Management (IAM). Recommender utilizza il machine learning per fornire agli amministratori suggerimenti per rimuovere l'accesso non necessario alle risorse Google Cloud e ridimensionare le istanze Compute Engine per un utilizzo più efficiente delle risorse.

Ogni consiglio include un'azione suggerita e il relativo impatto. Dopo aver esaminato i consigli per gli impatti identificati, nonché altre considerazioni specifiche per il tuo ambiente, puoi selezionare i consigli che vuoi applicare. Puoi applicare i suggerimenti manualmente dalla console Google Cloud oppure in modo programmatico integrandoli nella pipeline Infrastructure as Code (IaC).

L'IaC ti consente di automatizzare la creazione delle risorse Google Cloud .Devi mantenere aggiornato il repository IaC e instradare le modifiche apportate all'organizzazioneGoogle Cloud . Le strategie IaC nelle organizzazioni si rivelano generalmente vantaggiose se implementate con rigore e fungono da unica versione attendibile per l'infrastruttura cloud. Mantenere aggiornato il repository IaC è fondamentale per evitare discrepanze tra la versione dell'infrastruttura riflessa nel repository IaC e quella presente nell'organizzazione.

Suggerimenti IAM

Tra le altre pratiche principali, una comune è il principio di sicurezza del privilegio minimo e un'attenta valutazione di come le modifiche alla tua organizzazione vengono implementate e sincronizzate con il repository IaC.

Suggerimento per il dimensionamento delle VM

I suggerimenti per il dimensionamento ti aiutano a ridurre i costi fornendo suggerimenti per ridimensionare il tipo di macchina delle tue istanze per utilizzare in modo più efficiente le risorse dell'istanza.

Questo tutorial descrive come progettare e creare una pipeline di automazione per applicare un programma di consigli di Policy Intelligence in modo programmatico. Nell'ambito di questa pipeline di automazione, imparerai a mantenere aggiornato il repository IaC con le modifiche che decidi di apportare alla tua organizzazione Google Cloud , in base al dimensionamento delle VM e al suggerimento di binding delle policy IAM reso disponibile da Recommender.

Questo tutorial utilizza Hashicorp Terraform come strumento IaC, ma i pattern architetturali e i componenti utilizzati nella pipeline di automazione descritta possono essere sfruttati anche se utilizzi uno strumento di gestione IaC diverso, ad esempio Deployment Manager. Dovrai modificare il codebase open source reso disponibile con questo tutorial per adattarlo alla tua implementazione IaC specifica.

Questa guida è rivolta ad architetti, product owner e sviluppatori che potrebbero essere responsabili dell'amministrazione, della sicurezza e della pianificazione dell'infrastruttura del proprio Google Cloud.

Architettura della pipeline di Automation

Il seguente diagramma mostra i componenti utilizzati in questa pipeline di automazione.

Un job Cloud Scheduler pianificato esegue il servizio Recommender Parser. Il servizio chiama l'API Recommender per recuperare i consigli di Recommender per i progetti che specifichi. Analizza quindi queste raccomandazioni relative al dimensionamento delle VM e a IAM per mapparle alla configurazione presente nei manifest Terraform. Il servizio aggiorna i manifest IaC in modo che riflettano questi suggerimenti. Genera una richiesta di pull con le modifiche in modo che tu possa esaminare gli aggiornamenti. Una volta esaminata e unita la richiesta di pull, un job Cloud Build implementa le modifiche all'infrastruttura nella tua organizzazioneGoogle Cloud .

Nella pipeline vengono utilizzati diversi servizi Google Cloud ausiliari per monitorare i suggerimenti elaborati, generare notifiche al termine della build e archiviare lo stato di Terraform. Scoprirai di più su questi servizi nel corso di questo tutorial.

Il seguente elenco descrive lo scopo del componente e i requisiti di controllo dell'accesso:

Platform Intelligence Recommenders

Scopo: generare consigli per la sicurezza e il dimensionamento delle VM

Controllo dell'accesso: il service account Google Cloud deve disporre delle autorizzazioni IAM richieste per recuperare i consigli utilizzando l'API Recommender.

Esamina i ruoli e le autorizzazioni di Recommender per selezionare il ruolo più appropriato applicabile all'account di servizio che utilizzi per eseguire il servizio recommender-parser.

• Autorizzazioni per il motore per suggerimenti IAM
• Autorizzazioni per il dimensionamento delle istanze Compute Engine

Cloud Scheduler

Scopo: Cloud Scheduler attiva il servizio Recommender Parser. Cloud Scheduler ti consente di configurare più job che richiamano tutte le istanze del servizio di analisi di cui hai bisogno. Ogni chiamata deve passare i seguenti input

• Elenco dei progetti per i quali devono essere elaborati i consigli
• Tipo di consiglio
• Nome del repository IaC

Nota: ti consigliamo di configurare più job di pianificazione se hai più di un repository IaC nella tua azienda. In genere, questo è un modello comune nelle grandi aziende.

Controllo dell'accesso: crea o identifica un account di servizio Google Cloud da utilizzare per le chiamate da Cloud Scheduler al servizio Recommender Parser.

Concedi al account di servizio il ruolo Agente di servizio Cloud Scheduler in modo che possa eseguire i job Cloud Scheduler. Inoltre, concedi al service account il ruolo Invoker di Cloud Run, poiché questo account richiama un servizio Cloud Run.

Per maggiori dettagli, consulta la documentazione sulla configurazione dell'accesso autenticato per i job dello scheduler.

Servizio Cloud Run

Scopo: il servizio di analisi e raccomandazione è il luogo in cui risiede tutta la logica di elaborazione. Ha più percorsi, ognuno dei quali ha uno scopo specifico:

• Analisi dei consigli per ogni tipo di consiglio.
• Aggiornamento dello stato dei suggerimenti in fase di elaborazione

Controllo dell'accesso: utilizza IAM per gestire l'accesso a questo servizio

Inoltre, assegna il servizio a un account di servizio dedicato. In questo modo solo il servizio può richiamare altri servizi come Firestore.

Hashicorp Terraform

Scopo: Terraform 0.12 è lo strumento IaC.

Un builder Cloud Build per Terraform viene utilizzato per richiamare i comandi Terraform e a questo scopo viene utilizzato ilaccount di serviziot Cloud Build.

Cloud Build

Scopo: Google Cloud Build automatizza il deployment dell'infrastruttura in base alle modifiche apportate ai manifest IaC in base ai suggerimenti dell'intelligence delle policy.

Controllo dell'accesso: il account di servizio Cloud Build deve disporre del giusto insieme di autorizzazioni per interagire con le risorse nel tuo progetto di test.

Consulta la documentazione per configurare un service account Cloud Build.

GitHub

Scopo: il repository IaC utilizza GitHub per il controllo del codice sorgente. Il repository IaC in GitHub è integrato con Cloud Build. Quando vengono eseguiti commit al ramo master, viene attivato un job Cloud Build per eseguire un insieme di attività preconfigurate.

Controllo dell'accesso:devi generare chiavi SSH per consentire l'accesso al tuo repository IaC.

Inoltre, devi generare un token di accesso personale per eseguire il push dei commit su GitHub.

Nota: sono necessarie chiavi SSH e un token di accesso personale quando interagisci con repository privati ospitati su GitHub. Se il tuo repository è pubblico (non consigliato), questo passaggio non ti riguarda.

Firestore

Firestore è un database di documenti NoSQL scalabile e completamente gestito che viene utilizzato in questa architettura per archiviare le informazioni relative agli ID suggerimento analizzati dal servizio Recommender Parser, insieme ai dettagli corrispondenti pertinenti ai commit Git.

I dettagli persistenti in Firestore svolgono un ruolo fondamentale nel ciclo di feedback che fa parte della pipeline end-to-end. Dopo aver selezionato un suggerimento generato dall'API Recommender e prima di elaborarlo, il servizio contrassegna lo stato del suggerimento come CLAIMED. Dopo l'applicazione del suggerimento, il servizio esegue query sul database per recuperare gli ID dei suggerimenti applicati correttamente dal job Cloud Build e modifica lo stato del suggerimento in SUCCEEDED. Se il job Cloud Build non va a buon fine, lo stato del consiglio viene modificato in FAILED.

Controllo dell'accesso:per maggiori dettagli, consulta la sezione Ruoli Firestore. Il servizio di analisi e raccomandazione legge i dati da Firestore e per farlo ha bisogno del ruolo roles/datastore.user.

Pub/Sub

Scopo: Cloud Build pubblica messaggi in un argomento Pub/Sub quando lo stato della build cambia, ad esempio quando viene creata, quando passa a uno stato di lavoro e quando viene completata.

L'argomento Pub/Sub a cui Cloud Build pubblica i messaggi si chiama cloud-builds e viene creato automaticamente quando abiliti l'API Cloud Build nel tuo progetto.

Controllo dell'accesso: le sottoscrizioni push possono essere configurate per fornire un'intestazione di autenticazione per consentire al servizio di autorizzare la richiesta. Per ulteriori dettagli, consulta la sezione Utilizzo delle sottoscrizioni push.

Obiettivi

• Crea una pipeline di automazione per
  • Monitorare in modo proattivo i suggerimenti di Policy Intelligence della piattaforma
  • Analizzare i suggerimenti e applicare gli aggiornamenti a un repository IaC esistente
• Scopri come utilizzare una suite di servizi Google Cloud , Hashicorp Terraform e GitHub per creare questa pipeline.
• Comprendere i presupposti e le best practice da tenere presenti per creare questa pipeline
• Testa la pipeline

Costi

In questo documento vengono utilizzati i seguenti componenti fatturabili di Google Cloud:

• Cloud Run
• Cloud Build
• Compute Engine
• Cloud Storage
• Firestore
• Pub/Sub
• Cloud Scheduler
• Recommender

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

I nuovi utenti di Google Cloud potrebbero avere diritto a una prova senza costi.

Prima di iniziare

Questo tutorial presuppone che tu abbia un account GitHub e che tu abbia familiarità con Git, Node.js, Terraform e Docker.

Note di rilascio e ipotesi

Esiste una grande variabilità nel modo in cui vengono utilizzati gli strumenti e i manifest IaC.

Esamina le seguenti informazioni per determinare in che modo questo tutorial può adattarsi alla tua pipeline IaC e quali tipi di modifiche potrebbero essere necessari.

• Questa pipeline utilizza Terraform ver. 0.12. Modifiche significative alla sintassi di configurazione HCL o alla struttura del file di stato Terraform potrebbero introdurre problemi di interruzione.
• Questa pipeline presuppone che le strutture di directory IaC non siano nidificate e che un repository IaC gestisca le risorse in uno o più progetti Google Cloud .
• Le variabili Terraform passate come variabili di ambiente e argomenti della riga di comando non sono supportate. Il prototipo presuppone la configurazione dichiarativa delle variabili Terraform in un file tfvars.
• Il motore per suggerimenti genera suggerimenti IAM quando un sottoinsieme di autorizzazioni per un ruolo non è stato utilizzato per 60 giorni e i suggerimenti per il dimensionamento delle VM seguono un pattern simile. Ai fini di questo tutorial, sono stati forniti payload di consigli di esempio che possono essere utilizzati per testare la pipeline.
• I loop all'interno di Terraform non sono supportati in questa release
• I moduli Terraform non sono supportati. Il codebase è open source e si presume che tu apporti i miglioramenti specifici necessari al flusso di analisi per adattarlo alla struttura delle directory e all'utilizzo dei moduli.

La versione attuale del servizio di analisi dei consigli open source è allineata alle seguenti limitazioni note dei consigli IAM:

• I suggerimenti possono essere creati solo per le associazioni di criteri IAM che:
  • A livello di progetto
  • Associato a account utente e service account gestiti dall'utente
• I suggerimenti IAM supportano ruoli di base e ruoli predefiniti soltanto. Ruoli personalizzati e binding condizionali non possono essere valutati o consigliati.
• I ruoli consigliati contengono solo un sottoinsieme delle autorizzazioni del ruolo attuale. Nessuna nuova autorizzazione viene introdotta da un ruolo consigliato.

Prerequisiti

1. Seleziona o crea due Google Cloud progetti.

   Vai alla pagina di selezione del progetto

   • Un progetto build che ospita ed esegue la pipeline di automazione.
   • Un progetto test che ospita Google Cloud risorse utilizzate per testare la pipeline di automazione.

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

3. Nel progetto test, abilita l'API Recommender e Compute Engine.

   Enable the APIs

4. Nel progetto build, abilita le API Cloud Run, Firestore, Pub/Sub, Cloud Scheduler, IAM e CloudResourceManager.

   Enable the APIs

Al termine di questo tutorial, puoi evitare l'addebito di ulteriori costi eliminando le risorse create. Per maggiori dettagli, vedi Esegui la pulizia.

Configura l'ambiente

1. Nella console Google Cloud , seleziona il progetto build.

2. Nella console Google Cloud , vai a Cloud Shell.

   Vai a Cloud Shell

   Nella parte inferiore della console Google Cloud si apre una sessione di Cloud Shell e viene visualizzato un prompt della riga di comando. Cloud Shell è un ambiente shell con Google Cloud CLI già installato e con valori già impostati per il progetto corrente. L'inizializzazione della sessione può richiedere alcuni secondi.

   Utilizza Cloud Shell per tutti i comandi del terminale in questo tutorial.

3. Crea una variabile di ambiente per contenere il numero di progetto del tuo progetto build utilizzando il comando riportato di seguito:

   export BUILD_PROJECT_ID=$DEVSHELL_PROJECT_ID
   

4. Crea una variabile di ambiente in cui inserire il numero di progetto per il tuo progetto test . Copia manualmente l'ID progetto di test e sostituiscilo a PROJECT-ID.

   export TEST_PROJECT_ID=PROJECT-ID

5. Assegni le impostazioni predefinite per i valori utilizzati in tutto il tutorial, ad esempio regione e zona. In questo tutorial, utilizzi us-central1 come regione predefinita e us-central1-b come zona predefinita.

6. Imposta la regione e la zona predefinite per questo tutorial eseguendo il comando seguente:

   gcloud config set compute/zone us-central1-b --project $BUILD_PROJECT_ID
   gcloud config set compute/zone us-central1-b --project $TEST_PROJECT_ID
   

7. Imposta il progetto build come progetto predefinito:

   gcloud config set project $BUILD_PROJECT_ID
   

8. Crea una variabile di ambiente denominataBUILD_PROJECT_NUMBER per il tuobuildnumero di progetto

   export BUILD_PROJECT_NUMBER=$(gcloud projects describe $DEVSHELL_PROJECT_ID --format='value(projectNumber)')
   

9. Clona il repository GitHub per questo tutorial:

   Nota: esegui tutti i comandi di questo tutorial in Cloud Shell, se non diversamente specificato.

Crea un bucket per lo stato di Terraform

Crea un bucket Cloud Storage nel progetto di build per archiviare il file di stato di Terraform.

gcloud storage buckets create gs://recommender-tf-state-$BUILD_PROJECT_ID \
  --project=${BUILD_PROJECT_ID} --location=us-central1

Creare un repository GitHub

Crea un repository GitHub che funga da repository IaC di esempio

1. Crea un nuovo repository GitHub privato. Questo repository IAC-REPO-NAME funge da repository IaC ai fini di questo tutorial

2. Nei passaggi successivi, eseguirai il push dei file nella sottodirectory sample-iac del repository clonato nel tuo account GitHub.

   1. In Cloud Shell, copia la directory sample-iac nella tua home directory. Utilizzerai questa directory per creare un nuovo repository locale e inviarlo a GitHub.

      cp -r recommender-iac-pipeline-nodejs-tutorial/sample-iac $HOME
      

   2. Vai alla nuova directory

      cd $HOME/sample-iac
      

   3. Inizializza il repository nella tua macchina locale.

      git init
      

   4. Aggiungi IAC-REPO-NAME come repository remoto, sostituendo IAC-REPO-NAME e GITHUB-ACCOUNT con i valori appropriati

      git remote add origin https://github.com/GITHUB-ACCOUNT/IAC-REPO-NAME

   5. Sostituisci i segnaposto nei file di questo repository con il tuo ID progettotest e il nome del bucket Cloud Storage di Terraform.

      sed -i "s|__PROJECT_ID__|${TEST_PROJECT_ID}|g" ./terraform.tfvars
      
      sed -i "s|__STATE_BUCKET_NAME__|recommender-tf-state-$BUILD_PROJECT_ID|g" ./backend.tf
      

   6. Aggiungi, esegui il commit e il push su GitHub.

      git add .
      git commit -m "First Commit"
      git push origin master
      

   7. Quando richiesto, accedi al tuo account GitHub.

Generare chiavi SSH per il repository

Configura l'autenticazione con chiave SSH con il repository IaC in GitHub e carica le chiavi in Cloud Storage.

1. Genera chiavi SSH per il repository GitHub.

   1. Genera una coppia di chiavi SSH. Sostituisci [e-mail] con il tuo indirizzo email GitHub. In Cloud Shell:

      ssh-keygen -t rsa -b 4096 -m PEM -C "[e-mail]"

   2. Quando ti viene chiesto di "Inserire un file in cui salvare la chiave", premi Invio. In questo modo viene accettata la posizione predefinita del file.

   3. Quando ti viene chiesto di inserire una passphrase, premi Invio.

2. Prendi nota della directory SSH-KEYS-DIR in cui salvi le chiavi SSH scaricate. Per impostazione predefinita, la posizione è$HOME/.ssh/

3. Copia la chiave pubblica SSH che hai generato nel tuo repository GitHub come chiave di distribuzione.

   1. Copia la chiave pubblica SSH generata in Cloud Shell. Sostituisci SSH-KEYS-DIR con il percorso della directory.

      cat SSH-KEYS-DIR/id_rsa.pub

   2. Nel tuo account GitHub, vai al repository IAC-REPO-NAME.

   3. Fai clic su Impostazioni > Deploy Keys.

   4. Fai clic su Aggiungi chiave di deployment e incolla la chiave SSH pubblica che hai copiato. Scegli un titolo per la chiave.

   5. Seleziona la casella di controllo "Consenti accesso in scrittura".

   6. Fai clic su Salva.

4. Torna alla sessione di Cloud Shell.

5. Crea il file known_hosts per GitHub. Nella sessione di Cloud Shell, esegui il comando:

   ssh-keyscan github.com >> ~/.ssh/known_hosts
   

6. Crea un bucket Cloud Storage nel tuobuild progetto e caricarvi le chiavi SSH e il file known_hosts. Sostituisci SSH-KEYS-DIR con il percorso della directory in cui hai generato le chiavi SSH.

   gcloud storage buckets create gs://github-keys-$BUILD_PROJECT_ID --project=${BUILD_PROJECT_ID} --location=us-central1
   
   gcloud storage cp SSH-KEYS-DIR/id_rsa* gs://github-keys-$BUILD_PROJECT_ID
   gcloud storage cp SSH-KEYS-DIR/known_hosts gs://github-keys-$BUILD_PROJECT_ID

7. Genera un token di accesso personale per GitHub. Questo token viene utilizzato quando vengono eseguite operazioni Git utilizzando chiamate API che il servizio recommender-parser effettua per generare richieste di pull e archiviare i manifest IaC aggiornati.

   1. Nel tuo account GitHub, nell'angolo in alto a destra di qualsiasi pagina, fai clic sulla tua foto del profilo, quindi fai clic su Impostazioni.

   2. Nella barra laterale a sinistra, fai clic su Impostazioni sviluppatore.

   3. Nella barra laterale a sinistra, fai clic su Token di accesso personale.

   4. Fai clic su Genera nuovo token.

   5. Assegna un nome descrittivo al token.

   6. Seleziona gli ambiti come repo.

   7. Fai clic su Genera token.

   8. Copia il token negli appunti.

   9. Nella sessione di Cloud Shell, crea una variabile di ambiente.

      export GITHUB_PAT=personal-access-token-you-copied

Configura Cloud Build

1. Connetti il tuo repository Git IAC-REPO-NAME per l'integrazione con Cloud Build.

   1. Vai alla pagina dell'app Cloud Build in GitHub Marketplace.
   2. Scorri verso il basso e fai clic su Configura con Google Cloud Build in fondo alla pagina.
   3. Se richiesto, accedi a GitHub.
   4. Seleziona Solo repository selezionati. Utilizza l'elenco a discesa Seleziona repository per attivare l'accesso solo al tuo IAC-REPO-NAME nell'app Cloud Build.
   5. Fai clic su Installa.

   6. Accedi a Google Cloud.

      Viene visualizzata la pagina Autorizzazione in cui ti viene chiesto di autorizzare l'app Google Cloud Build a connettersi a Google Cloud.

   7. Fai clic su Autorizza Google Cloud Build di GoogleCloudBuild. Viene visualizzata la console Google Cloud .

   8. Selezionare il tuo progetto Google Cloud .

   9. Attiva la casella di controllo del consenso e fai clic su Avanti.

   10. Nella pagina Seleziona repository visualizzata, seleziona il repository GitHub IAC-REPO-NAME.

   11. Fai clic su Connetti repository.

   12. Fai clic su Crea un trigger. Viene creata una definizione di trigger.

   13. Fai clic su Crea per salvare il trigger di build.

   Per maggiori informazioni, vedi Esecuzione di build su GitHub.

2. La directory che hai copiato contiene un file cloudbuild.yaml. Questo file di configurazione descrive i passaggi che un job Cloud Build esegue quando viene attivato.

   steps:
   - name: hashicorp/terraform:0.12.0
     args: ['init']
   - name: hashicorp/terraform:0.12.0
     args: ['apply', '-auto-approve']
   

3. Aggiungi autorizzazioni al account di servizio Cloud Build per consentirgli di creare service account, associare ruoli e macchine virtuali (istanze Compute Engine) nel progetto di test

   gcloud projects add-iam-policy-binding $TEST_PROJECT_ID \
     --member serviceAccount:$[e-mail] \
     --role roles/compute.admin \
     --project $TEST_PROJECT_ID
   
   gcloud projects add-iam-policy-binding $TEST_PROJECT_ID \
     --member serviceAccount:$[e-mail] \
     --role roles/iam.serviceAccountAdmin \
     --project $TEST_PROJECT_ID
   
   gcloud projects add-iam-policy-binding $TEST_PROJECT_ID \
   --member serviceAccount:$[e-mail] \
   --role roles/iam.securityAdmin \
   --project $TEST_PROJECT_ID
   

4. Apri la pagina Trigger di build nella consoleGoogle Cloud .

5. Seleziona il progetto build e fai clic su Apri.

6. Aggiorna la definizione dell'attivatore:

   1. Fai clic sul menu e poi su Modifica.
   2. Per Configurazione, seleziona l'opzione File di configurazione di Cloud Build (yaml o json) e digita cloudbuild.yaml nel campo di testo.
   3. Fai clic su Salva.

7. Per testare manualmente il trigger di build, fai clic su Esegui nella voce del trigger nell'elenco dei trigger.

8. Verifica che nel progetto di test siano state create un'istanza Compute Engine denominata tf-compute-1 e un account di servizio denominato Terraform Recommender Test dal job Cloud Build eseguito nel passaggio precedente.

Nota: potrebbe essere necessario attendere alcuni istanti per il completamento del job Cloud Build prima di verificare la creazione delle risorse nel progetto di test.

Esegui il deployment del servizio Cloud Run recommender-parser

1. In Cloud Shell, cambia directory con quella creata clonando il repository

   cd $HOME/recommender-iac-pipeline-nodejs-tutorial/parser-service
   

2. Configura Google Cloud per utilizzare una regione predefinita per i servizi Cloud Run. In questo tutorial, utilizzi la regione us-central1, ma puoi scegliere un'altra regione supportata, se preferisci.

   gcloud config set run/region us-central1
   

3. La directory parser-service ha una sottodirectory stub con alcuni JSON di payload di esempio per testare il servizio di analisi dei consigli. Esegui i seguenti comandi sed per sostituire i segnaposto PROJECT_ID in questi file JSON con l'ID del tuo progetto di test.

   sed -i "s|__PROJECT_ID__|${TEST_PROJECT_ID}|g" ./stub/iam.json
   sed -i "s|__PROJECT_ID__|${TEST_PROJECT_ID}|g" ./stub/vm.json
   

4. Esegui questo comando per creare una variabile di ambiente per la tua immagine Docker.

   export IMAGE=gcr.io/$BUILD_PROJECT_ID/recommender-parser:1.0
   

5. Crea l'immagine e caricala su Container Registry

   gcloud builds submit --tag $IMAGE .
   

6. Crea un account di servizio per il servizio recommender-parser per interagire con altri Google Cloud servizi nella pipeline. È una buona pratica concedere autorizzazioni granulari ai tuoi servizi Cloud Run. Per maggiori dettagli, consulta Identità del servizio Cloud Run.

   gcloud beta iam service-accounts create recommender-parser-sa \
     --description "Service account that the recommender-parser service uses to invoke other Google Cloud services" \
     --display-name "recommender-parser-sa" \
     --project $BUILD_PROJECT_ID
   

7. Il servizio recommender-parser deve accedere alle chiavi SSH di GitHub e allo stato di Terraform che hai caricato nei bucket Cloud Storage creati in precedenza. Aggiungi ilaccount di serviziot come membro al bucket Cloud Storage.

   gcloud storage buckets add-iam-policy-binding gs://github-keys-$BUILD_PROJECT_ID \
     --member=serviceAccount:recommender-parser-sa@$BUILD_PROJECT_ID.iam.gserviceaccount.com \
     --role=roles/storage.objectUser
   
   gcloud storage buckets add-iam-policy-binding gs://recommender-tf-state-$BUILD_PROJECT_ID \
     --member=serviceAccount:recommender-parser-sa@$BUILD_PROJECT_ID.iam.gserviceaccount.com \
     --role=roles/storage.objectUser
   

8. Concedi all'account di servizio del servizio di analisi dei consigli l'accesso a Firestore, Recommender e all'API Service Usage.

   gcloud projects add-iam-policy-binding $BUILD_PROJECT_ID \
     --member serviceAccount:recommender-parser-sa@$BUILD_PROJECT_ID.iam.gserviceaccount.com \
     --role roles/datastore.user
   
   gcloud projects add-iam-policy-binding $TEST_PROJECT_ID \
     --member serviceAccount:recommender-parser-sa@$BUILD_PROJECT_ID.iam.gserviceaccount.com \
     --role roles/recommender.iamAdmin
   
   gcloud projects add-iam-policy-binding $TEST_PROJECT_ID \
     --member serviceAccount:recommender-parser-sa@$BUILD_PROJECT_ID.iam.gserviceaccount.com \
     --role roles/recommender.iamViewer
   
   gcloud projects add-iam-policy-binding $TEST_PROJECT_ID \
     --member serviceAccount:recommender-parser-sa@$BUILD_PROJECT_ID.iam.gserviceaccount.com \
     --role roles/recommender.computeAdmin
   
   gcloud projects add-iam-policy-binding $TEST_PROJECT_ID \
     --member serviceAccount:recommender-parser-sa@$BUILD_PROJECT_ID.iam.gserviceaccount.com \
     --role roles/serviceusage.serviceUsageConsumer
   

9. Esegui il deployment del servizio Cloud Run, denominato recommender-parser, eseguendo il comando. Sostituisci GITHUB-ACCOUNT con il nome utente del tuo account GitHub, non con l'email. Accetta tutti i prompt di sistema.

   gcloud run deploy \
    --image=${IMAGE} \
    --no-allow-unauthenticated \
    --region us-central1 \
    --platform managed \
    --service-account recommender-parser-sa@$BUILD_PROJECT_ID.iam.gserviceaccount.com \
    --set-env-vars="GITHUB_ACCOUNT=github.com:GITHUB-ACCOUNT,GITHUB_PAT=${GITHUB_PAT},SSH_KEYS_BUCKET=github-keys-${BUILD_PROJECT_ID},TERRAFORM_STATE_BUCKET=recommender-tf-state-$BUILD_PROJECT_ID" \
    --project $BUILD_PROJECT_ID \
    recommender-parser

Configura Firestore

1. Nella console Google Cloud , nel tuo progetto build, vai alla pagina Firestore.
2. Quando ti viene chiesto di selezionare la modalità, fai clic su Seleziona modalità nativa.
3. Selezionaus-east1 come posizione predefinita.
4. Fai clic su Crea database.

Il serviziorecommender-parser scrive documenti in questo database per le seguenti finalità:

• Per tenere traccia dei suggerimenti recuperati dall'API Recommender
• Chiama l'API Recommender una volta elaborati i suggerimenti per aggiornare lo stato di ogni suggerimento elaborato a SUCCEEDED o FAILED, a seconda dei casi. Si tratta di un passaggio fondamentale che rende la pipeline idempotente, garantendo che i consigli non vengano elaborati in modo incompleto o più volte.

Configura un job Cloud Scheduler

1. Crea un account di servizio che i job Cloud Scheduler utilizzano per eseguire il servizio recommender-parser.

   gcloud beta iam service-accounts create recommender-scheduler-sa \
     --description "Service Account used by Cloud Scheduler to invoke the recommender-parser service" \
     --display-name "recommender-scheduler-sa" \
     --project $BUILD_PROJECT_ID
   

2. Assegna al account di servizio il ruolo di esecuzione/invoker per poter richiamare il servizio Cloud Run.

   gcloud beta run services add-iam-policy-binding recommender-parser \
   --member=serviceAccount:recommender-scheduler-sa@$BUILD_PROJECT_ID.iam.gserviceaccount.com \
   --role=roles/run.invoker \
   --region=us-central1
   

3. Recupera l'URL del servizio di raccomandazione:

   gcloud beta run services list --platform managed --project $BUILD_PROJECT_ID
   

   Il job Cloud Scheduler richiama il servizio recommender-parser /recommendation/iam per analizzare i suggerimenti IAM e /recommender/vm per analizzare i suggerimenti di dimensionamento delle VM.

4. Crea una variabile per l'endpoint richiamato dai job Cloud Scheduler. Sostituisci RECOMMENDER-SERVICE-URL con l'URL del servizio di raccomandazione che hai copiato nel passaggio precedente.

   export RECOMMENDER_ROUTE_TO_INVOKE_IAM=RECOMMENDER-SERVICE-URL/recommendation/iam

   Dopo aver aggiunto le informazioni sull'itinerario, l'URL dovrebbe essere simile a questo URL di esempio:

   RECOMMENDER-SERVICE-URL/recommendation/iam
   

5. Crea un job Cloud Scheduler chiamato recommender-iam-scheduler.

   • Modifica il fuso orario selezionato in base alla tua posizione.
   • Sostituisci IAC-REPO-NAME con il nome del repository GitHub che hai creato.

   Il corpo del messaggio richiede tre input e deve essere strutturato come descritto di seguito:

   • repo: il nome del repository GitHub IAC-REPO-NAME che hai creato in Creare un repository GitHub.

   • projects: Un elenco / array di ID progetto a cui è mappato questo repository GitHub IaC. Google Cloud In questo tutorial, è il tuo progetto test.

   • stub: il motore per suggerimenti genera suggerimenti IAM quando un sottoinsieme di autorizzazioni per un ruolo non è stato utilizzato per 60 giorni e i suggerimenti per il dimensionamento delle VM seguono un pattern simile. Ai fini del test di questa pipeline on demand, stub può essere passato come true in modo che la pipeline venga testata utilizzando i payload di esempio di Recommender forniti nel repository che hai clonato per questo tutorial.

   gcloud beta scheduler jobs create http recommender-iam-scheduler \
     --project $BUILD_PROJECT_ID \
     --time-zone "America/Los_Angeles" \
     --schedule="0 */3 * * *" \
     --uri=$RECOMMENDER_ROUTE_TO_INVOKE_IAM \
     --description="Scheduler job to invoke recommendation pipeline" \
     --oidc-service-account-email="recommender-scheduler-sa@$BUILD_PROJECT_ID.iam.gserviceaccount.com" \
     --headers="Content-Type=application/json" \
     --http-method="POST" \
     --message-body="{ \"repo\": \"IAC-REPO-NAME\", \"projects\": [\"$TEST_PROJECT_ID\"], \"location\": \"global\", \"stub\": true }"

Nota: --schedule="0 */3 * * *" esegue il job Scheduler ogni 3 ore. Modificalo in base alle tue esigenze. Inoltre, se devi creare un job di pianificazione per analizzare i consigli sul dimensionamento delle VM, devi aggiungere l'URL del servizio your-recommender-parser con /recommendation/vm e impostare l'attributo location nel parametro --message-body su una zona valida.

Passaggi aggiuntivi

Cloud Build pubblica le informazioni sulla build in un argomento Pub/Sub chiamato cloud-builds, creato automaticamente quando hai abilitato l'API Cloud Build nel progetto di build.

1. Esegui questo comando per verificare che l'argomento cloud-builds esista nel tuo progetto build:

   gcloud pubsub topics describe cloud-builds
   

   Se l'argomento esiste, vedrai il seguente output, dove BUILD-PROJECT-ID è l'ID progetto di build:

   name: projects/BUILD-PROJECT-ID/topics/cloud-builds
   

   Se ricevi un messaggio di errore che indica che la risorsa non è stata trovata, segui le istruzioni per iscriverti alle notifiche di build per creare l'argomento manualmente.

2. Crea un account di servizio che Pub/Sub utilizza per richiamare l'endpoint del servizio recommender-parser.

   gcloud beta iam service-accounts create recommender-ci-subscription-sa \
     --description "Service Account used by Cloud Pub/Sub to push Cloud Build events to the recommender-parser service" \
     --display-name "recommender-ci-subscription-sa" \
     --project $BUILD_PROJECT_ID
   

3. Il account di servizio Pub/Sub deve essere associato ai ruoli necessari per pubblicare messaggi e richiamare il servizio recommender-parser.

   gcloud projects add-iam-policy-binding $BUILD_PROJECT_ID \
     --member serviceAccount:recommender-ci-subscription-sa@$BUILD_PROJECT_ID.iam.gserviceaccount.com \
     --role roles/pubsub.publisher \
     --project $BUILD_PROJECT_ID
   
   gcloud projects add-iam-policy-binding $BUILD_PROJECT_ID \
     --member serviceAccount:recommender-ci-subscription-sa@$BUILD_PROJECT_ID.iam.gserviceaccount.com \
     --role roles/pubsub.subscriber \
     --project $BUILD_PROJECT_ID
   
   gcloud projects add-iam-policy-binding $BUILD_PROJECT_ID \
     --member serviceAccount:recommender-ci-subscription-sa@$BUILD_PROJECT_ID.iam.gserviceaccount.com \
     --role roles/run.invoker \
     --project $BUILD_PROJECT_ID
   

4. Aggiungi l'account di servizio recommender-ci-subscription-sa che hai creato al servizio recommender-parser come membro con il ruolo invoker.

   gcloud beta run services add-iam-policy-binding recommender-parser \
     --member=serviceAccount:recommender-ci-subscription-sa@$BUILD_PROJECT_ID.iam.gserviceaccount.com \
     --role=roles/run.invoker --region=us-central1
   

5. Vai a Pub/Sub nella console Google Cloud .

6. Fai clic sull'argomento cloud-builds.

7. Fai clic su Crea sottoscrizione.

8. In ID abbonamento, digita recommender-service-build-events.

9. In Tipo di consegna, seleziona Push.

10. In Endpoint, digita l'URL del servizio di raccomandazione seguito da /ci.

11. Seleziona Enable Authentication (Attiva autenticazione).

    1. Seleziona l'account di servizio recommender-ci-subscription-sa che hai creato.
    2. Fai clic su Concedi in risposta al messaggio di richiesta.

12. Seleziona Scadenza conferma di 60 secondi.

13. Mantieni i valori predefiniti per le altre impostazioni.

14. Fai clic su Crea.

Testa la pipeline

Il motore per suggerimenti genera suggerimenti IAM quando un sottoinsieme di autorizzazioni per un ruolo non è stato utilizzato per 60 giorni. I suggerimenti per il dimensionamento delle VM seguono un pattern simile. Ai fini del test di questa pipeline on demand, utilizzerai i payload JSON di esempio per i consigli forniti nella sottodirectory stub del repository clonato per questo tutorial. In questo modo puoi testare la pipeline, escluse le chiamate API che il parser di Recommender effettua all'endpoint API Recommender per aggiornare lo stato dei suggerimenti che ha applicato correttamente.

In alternativa, se hai consigli attivi nei tuoi progetti Google Cloud, puoi testare la pipeline end-to-end senza dover utilizzare stub. Il risultato descritto di seguito è pertinente quando utilizzi i payload di esempio per testare la pipeline. Tuttavia, i passaggi per testare questa pipeline senza campioni rimangono gli stessi.

1. Nella console Google Cloud , vai al progetto di test e controlla le risorse create. Devi disporre di quanto segue:

   1. Un'istanza di Compute Engine denominata tf-compute-1 con tipo di macchina g1-small.
   2. Un account di servizio denominato Terraform Recommender Test con il ruolo di editor per il tuo progetto di test.

2. Nella pagina della console Cloud Scheduler nel tuo progetto build, fai clic su Esegui ora per il job recommender-iam-scheduler.

3. Fai clic sul job per visualizzare i log. Puoi anche visualizzare i log del servizio recommender-parser per ottenere una visualizzazione dettagliata dei passaggi eseguiti dal servizio.

4. Una volta completata l'esecuzione del servizio, vai al repository GitHub IAC-REPO-NAME. Il servizio recommender-parser avrebbe generato una richiesta di pull per te. Esamina i manifest IaC modificati che compongono questa richiesta pull e fai clic su Unisci richiesta pull se sei soddisfatto delle modifiche ai manifest IaC.

   Avviso: negli ambienti di produzione, ti consigliamo di applicare un flusso di lavoro di approvazione solido che includa la revisione umana delle richieste pull prima dell'unione delle modifiche. I revisori devono avere le conoscenze necessarie per valutare gli impatti identificati nei consigli, nonché gli impatti specifici per la tua infrastruttura e la tua attività. L'applicazione dei consigli senza un'adeguata valutazione potrebbe comportare modifiche impreviste, ad esempio problemi di prestazioni del sistema, scarsa affidabilità o perdita delle autorizzazioni richieste. Consulta la documentazione di GitHub per istruzioni su come configurare una procedura di revisione.

5. Quando unisci la richiesta di pull, viene creato un nuovo commit nel ramo master. Viene attivato un job Cloud Build che implementa le modifiche alle risorse Google Cloud nel tuo progetto test. Attendi qualche istante per il completamento del job Cloud Build. Puoi esaminarne lo stato nella console Google Cloud .

   Nota :assicurarsi di disporre di una strategia di rollback funzionale è una best practice quando configuri le pipeline DevOps. Ad esempio, le modifiche all'infrastruttura implementate dalla pipeline di automazione che hai creato in questo tutorial possono essere annullate ripristinando un commit Git precedente. Puoi scoprire di più sui comandi https://git-scm.com/docs/git-reset e git revert in questa documentazione di Git.

6. Una volta completato il job, vai al progetto di test. I payload di esempio forniti apportano le seguenti modifiche alle risorse nel progetto di test.

   • Il account di servizio di test Terraform, che in precedenza aveva il ruolo editor al momento del deployment, viene modificato in viewer.
   Nota: quando esegui il servizio Cloud Scheduler per richiamare l'analisi dei suggerimenti per il dimensionamento delle VM all'endpoint /recommendation/vm, l'istanza Compute Engine tf-compute-1 che originariamente ha un tipo di macchina g1-small viene modificata in f1-micro.

Esegui la pulizia

Per evitare che al tuo account Google Cloud vengano addebitati costi relativi alle risorse utilizzate in questo tutorial, elimina entrambi i progetti che hai creato.

Il modo più semplice per eliminare la fatturazione è eliminare il progetto creato per il tutorial.

Per eliminare il progetto:

Attenzione: l'eliminazione di un progetto ha i seguenti effetti:

• L'intero contenuto del progetto viene eliminato. Se hai utilizzato un progetto esistente per le attività descritte in questo documento, quando lo elimini, elimini anche tutto il lavoro che hai svolto nel progetto.
• Gli ID progetto personalizzati non sono più disponibili. Quando hai creato questo progetto, potresti aver creato un ID progetto personalizzato che vuoi utilizzare in futuro. Per conservare gli URL che utilizzano l'ID progetto, ad esempio un URL appspot.com, elimina le risorse selezionate all'interno del progetto anziché eliminare l'intero progetto.

Se intendi esplorare più architetture, tutorial o guide rapide, puoi riutilizzare i progetti ed evitare così di superare i limiti di quota.

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.

Passaggi successivi

• Esplora architetture di riferimento, diagrammi e best practice su Google Cloud. Consulta il nostro Cloud Architecture Center.
• Scopri di più su Google Cloud Policy Intelligence nella documentazione.