Panoramica
Google Cloud Policy Intelligence aiuta le aziende a comprendere e gestire i propri criteri al fine di ridurre i rischi. Di offrendo più visibilità e automazione, i clienti possono aumentare la sicurezza senza aumentare il carico di lavoro.
Motore per suggerimenti consente di recuperare suggerimenti per le risorse Google Cloud, migliorare la sicurezza del cloud, risparmiare sui costi e altro ancora. Per un elenco dei consigli supportati, consulta la documentazione del motore per suggerimenti. Questo tutorial descrive l'uso suggerimenti sul dimensionamento delle istanze VM Suggerimenti per Identity and Access Management (IAM). Il motore per suggerimenti utilizza il machine learning per fornire agli amministratori Suggerimenti per la rimozione degli accessi non necessari alle risorse Google Cloud e del ridimensionamento delle istanze di 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 e altre considerazioni specifiche per il tuo ambiente, puoi selezionare i consigli da applicare. Puoi applicare i suggerimenti manualmente dalla console Google Cloud oppure in modo programmatico integrandoli nel tuo Pipeline Infrastructure as Code (IaC).
La IaC ti consente di automatizzare la creazione delle risorse Google Cloud. Devi mantenere aggiornato il tuo repository IaC e inoltrarvi le modifiche apportate all'organizzazione Google Cloud. Le strategie IaC nelle organizzazioni generalmente si dimostrano utili quando vengono implementate con rigore e fungono da singola versione attendibile per l'infrastruttura cloud. Mantenere il repository IaC l'aggiornamento è fondamentale per evitare deviazioni tra la versione dell'infrastruttura che il repository IaC riflette e ciò che è dell'organizzazione.
Suggerimenti IAM
Tra le altre best practice, una comune è il principio di sicurezza del privilegio minimo e un'attenta considerazione di come le modifiche all'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 il ridimensionamento del tipo di macchina delle tue istanze in modo da utilizzare in modo più efficiente le risorse delle istanze.
Questo tutorial descrive come progettare e creare un'automazione per applicare un suggerimento di Policy Intelligence in modo programmatico. Nell'ambito di questa pipeline di automazione, scoprirai come mantenere aggiornato il tuo repository IaC con le modifiche che decidi di apportare alla tua organizzazione Google Cloud, in base alle dimensioni delle VM e ai consigli di associazione dei criteri IAM che Recommender mette a disposizione.
Questo tutorial utilizza Hashicorp Terraform come strumento IaC, tuttavia i pattern e i componenti di architettura utilizzati nella pipeline di automazione descritta possono essere sfruttati anche se utilizzi un altro strumento di gestione IaC come Deployment Manager. Dovrai modificare la base di codice open source resa disponibile con questo tutorial in base alla tua specifica implementazione IaC.
Questa guida è rivolta ad architetti, proprietari di prodotti e sviluppatori che potrebbero essere responsabili dell'amministrazione, della sicurezza e della pianificazione dell'infrastruttura del proprio servizio Google Cloud.
Architettura della pipeline di Automation
Il seguente diagramma mostra i componenti che utilizzi in questa automazione una pipeline o un blocco note personalizzato.
Un job Cloud Scheduler pianificato esegue il motore per suggerimenti Servizio parser. Il servizio chiama l'API Recommender per recuperare i consigli di Recommender per i progetti specificati. Analizza quindi questi consigli per le dimensioni delle VM e per IAM per mapparli alla configurazione presente nei manifest di Terraform. Il servizio aggiorna i manifest IaC di conseguenza personalizzati. Genera una richiesta di pull con le modifiche per consentirti rivedi gli aggiornamenti. Una volta esaminata e unita la richiesta di pull, verrà eseguita una Il job Cloud Build implementa le modifiche nell'infrastruttura dell'organizzazione Google Cloud.
Nella pipeline vengono utilizzati diversi servizi Google Cloud ausiliari per monitorare i consigli elaborati, generare notifiche al completamento della compilazione e archiviare lo stato di Terraform. Approfondirai questi servizi nel di questo tutorial.
Nell'elenco seguente sono descritti lo scopo del componente e i requisiti di controllo dell'accesso:
- Platform Intelligence Recommenders
- Finalità: generare consigli per la sicurezza e il dimensionamento delle VM
Controllo dell'accesso: l'account di servizio Google Cloud deve disporre della autorizzazioni IAM necessarie per recuperare i suggerimenti utilizzando API Recommender.
Esamina i ruoli e le autorizzazioni del motore per suggerimenti per selezionare quello più appropriato applicabile all'account di servizio che utilizzi per eseguire del motore per suggerimenti e analisi.
- Cloud Scheduler
Finalità: Cloud Scheduler attiva il servizio Recommender Parser. Cloud Scheduler consente di configurare più job che richiamano quanti le istanze del servizio di parser di cui hai bisogno. Ogni chiamata deve passare i seguenti input
- Elenco di progetti per i quali devono essere elaborati i suggerimenti
- Tipo di consiglio
- Nome del repository IaC
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 all'account di servizio il ruolo Agente di servizio Cloud Scheduler in modo da poter eseguire job Cloud Scheduler. Inoltre, concedi all'account di servizio il ruolo Invoker di Cloud Run, poiché questo account richiama un servizio Cloud Run.
Consulta la documentazione sulla configurazione di autenticazioni per i job dello scheduler.
- Servizio Cloud Run
Finalità: il servizio di analisi del recommender è la sede di tutta la logica di elaborazione. Ha più route, ognuna delle quali ha uno scopo specifico:
- Suggerimenti di analisi 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, si garantisce che solo il servizio sia in grado di invocare altri servizi come Firestore.
- HashiCorp Terraform
Scopo: Terraform 0.12 è lo strumento IaC.
Viene utilizzato un builder Cloud Build per Terraform per richiamare i comandi Terraform e l'account di servizio Cloud Build viene usato a questo scopo.
- Cloud Build
Scopo: Google Cloud Build automatizza il deployment dell'infrastruttura in base alle modifiche apportate ai manifest IaC per policy intelligence personalizzati.
Controllo dell'accesso: l'account di servizio Cloud Build deve disporre del giusto insieme di autorizzazioni per interagire con le risorse nel progetto di test.
Consulta la documentazione per la configurazione un account di servizio Cloud Build.
- GitHub
Scopo: il repository IaC utilizza GitHub per il controllo del codice sorgente. Il repository IaC su GitHub è integrato con Cloud Build. Quando vengono eseguiti commit nel ramo principale, viene attivato un job Cloud Build per eseguire un insieme di attività predefinite.
Controllo dell'accesso: dovrai generare chiavi SSH per abilitare l'accesso a del repository IaC.
Inoltre, devi generare un token di accesso personale per eseguire il push dei commit su GitHub.
- Firestore
Firestore è un database di documenti NoSQL completamente gestito e scalabile, viene usato in questa architettura per conservare informazioni relative ID suggerimento che vengono analizzati dal parser del motore per suggerimenti e i dettagli corrispondenti relativi ai commit Git.
I dettagli persistenti in Firestore svolgono un ruolo fondamentale in il ciclo di feedback che fa parte della pipeline end-to-end. Dopo aver recuperato un consiglio generato dall'API Recommender e prima di elaborarlo, il servizio ne contrassegna lo stato come
CLAIMED
. Dopo aver applicato il consiglio, il servizio esegue query sul database per recuperare gli ID consiglio che sono stati applicati correttamente dal job Cloud Build e modifica lo stato del consiglio inSUCCEEDED
. Se il job Cloud Build non va a buon fine, lo stato del consiglio viene modificato inFAILED
.Controllo dell'accesso: per maggiori dettagli, consulta la sezione Ruoli Firestore. Il servizio recommender-parser legge i dati da Firestore e per farlo ha bisogno del ruolo roles/datastore.user.
- Pub/Sub
Finalità: Cloud Build pubblica messaggi in un argomento Pub/Sub quando lo stato della compilazione cambia, ad esempio quando viene creata, quando passa a uno stato di funzionamento e quando viene completata.
Viene chiamato l'argomento Pub/Sub a cui Cloud Build pubblica i messaggi di Cloud Build, che viene creato automaticamente quando si abilita l'API Cloud Build nel tuo progetto.
Controllo dell'accesso: le iscrizioni push possono essere configurate per fornire un'intestazione di autenticazione che consenta al servizio di autorizzare la richiesta. Consulta Utilizzo delle sottoscrizioni push per ulteriori dettagli.
Obiettivi
- Crea una pipeline di automazione
- Monitora in modo proattivo i suggerimenti di Policy Intelligence della piattaforma
- Analizza i consigli e applica gli aggiornamenti a un repository IaC esistente
- Scopri come utilizzare una suite di servizi Google Cloud Terraform di hashicorp e GitHub per creare questa pipeline.
- Scopri le ipotesi e le best practice da tenere presenti per creare questa pipeline
- Testa la pipeline
Costi
In questo documento utilizzi 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 basata sull'utilizzo previsto,
utilizza il Calcolatore prezzi.
Prima di iniziare
Questo tutorial presuppone che tu abbia un account GitHub e che tu abbia dimestichezza con Git, Node.js, Terraform e Docker.
Note di rilascio e presupposti
Esistono molte variabili 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 necessarie.
- Questa pipeline utilizza Terraform ver. 0,12. Cambiamenti significativi in HCL sintassi di configurazione o modifiche alla struttura dello stato di Terraform potrebbe 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, argomenti della riga di comando non sono supportate. Il prototipo presuppone che delle variabili Terraform in un file tfvars.
- Il motore per suggerimenti genera suggerimenti IAM quando un sottoinsieme di autorizzazioni per un ruolo non viene utilizzato per 60 giorni e i suggerimenti per le dimensioni delle VM seguono un modello simile. Ai fini del presente documento tutorial, sono stati forniti payload di esempio che possono essere utilizzata 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 si presume che l'utente apporterà le modifiche specifiche necessarie ai di analisi in base alla struttura della directory e all'utilizzo dei moduli.
La versione attuale del servizio di parser open source per suggerimenti è allineata a le seguenti limitazioni note Suggerimenti IAM:
- I suggerimenti possono essere forniti solo per le associazioni di criteri IAM che sono:
- A livello di progetto
- Associati a account utente e account di servizio gestiti dall'utente
- I consigli IAM supportano solo ruoli di base e ruoli predefiniti. Ruoli personalizzati e associazioni condizionali non possono essere valutati o consigliati.
- I ruoli consigliati contengono solo un sottoinsieme delle autorizzazioni del ruolo corrente. Un ruolo consigliato non introduce nuove autorizzazioni.
Prerequisiti
- Seleziona o crea due progetti Google Cloud.
Vai alla pagina del selettore dei progetti
- Un progetto di compilazione che ospita ed esegue la pipeline di automazione.
- Un progetto di test che ospita le risorse Google Cloud impiegate per testare la pipeline di automazione.
-
Make sure that billing is enabled for your Google Cloud project.
- Nel progetto test, abilita il motore per suggerimenti e l'API Compute Engine.
- Nel progetto build, abilita Cloud Run, Firestore
Pub/Sub, Cloud Scheduler, IAM e
API CloudResourceManager.
Al termine di questo tutorial, puoi evitare la fatturazione continua eliminando le risorse che hai creato. Consulta la sezione Pulizia. per ulteriori dettagli.
Configura l'ambiente
- Nella console Google Cloud, seleziona il progetto
build
. Nella console Google Cloud, 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 in cui è già installato Google Cloud CLI e sono già impostati i valori per il progetto corrente. L'inizializzazione della sessione può richiedere alcuni secondi.
usa Cloud Shell per tutti i comandi del terminale durante il tutorial.
Crea una variabile di ambiente che contenga il numero di progetto per
build
utilizzando il comando seguente:export BUILD_PROJECT_ID=$DEVSHELL_PROJECT_ID
Crea una variabile di ambiente per contenere il numero del progetto
test
. Copia manualmente l'ID progetto di test e sostituiscilo PROJECT-ID con questa app,export TEST_PROJECT_ID=PROJECT-ID
Si assegnano impostazioni predefinite per i valori utilizzati in come region and zone. In questo tutorial utilizzi us-central1 come regione predefinita e us-central1-b come zona predefinita.
Imposta la regione e la zona predefinite per questo tutorial eseguendo il seguente comando:
gcloud config set compute/zone us-central1-b --project $BUILD_PROJECT_ID gcloud config set compute/zone us-central1-b --project $TEST_PROJECT_ID
Imposta il progetto
build
come progetto predefinito:gcloud config set project $BUILD_PROJECT_ID
Crea una variabile di ambiente denominata
BUILD_PROJECT_NUMBER
per ilbuild
numero di progettoexport BUILD_PROJECT_NUMBER=$(gcloud projects describe $DEVSHELL_PROJECT_ID --format='value(projectNumber)')
Clona il repository GitHub per questo tutorial:
Crea un bucket per lo stato di Terraform
Crea un bucket Cloud Storage nel progetto di build per archiviare Terraform file di stato.
gcloud storage buckets create gs://recommender-tf-state-$BUILD_PROJECT_ID \
--project=${BUILD_PROJECT_ID} --location=us-central1
Crea un repository GitHub
Crea un repository GitHub da utilizzare come repository IaC di esempio
Crea un nuovo repository GitHub privato. Questo IAC-REPO-NAME il repository funge da repository IaC ai fini di questo tutorial
Nei setps seguenti, eseguirai il push dei file nell'
sample-iac
secondaria del repository clonato nel tuo account GitHub.In Cloud Shell, copia la directory
sample-iac
nella tua home page . Utilizzerai questa directory per creare un nuovo repository locale ed esegui il push su GitHub.cp -r recommender-iac-pipeline-nodejs-tutorial/sample-iac $HOME
Vai alla nuova directory
cd $HOME/sample-iac
Inizializza il repository nella tua macchina locale.
git init
Aggiungi IAC-REPO-NAME come repository remoto, sostituisci IAC-REPO-NAME e GITHUB-ACCOUNT con i valori appropriati
git remote add origin https://github.com/GITHUB-ACCOUNT/IAC-REPO-NAME
Sostituisci i segnaposto nei file del repository con l'ID
test
del tuo progetto e il nome del bucket Terraform Cloud Storage.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
Aggiungi, esegui il commit e il push su GitHub.
git add . git commit -m "First Commit" git push origin master
Accedi al tuo account GitHub quando richiesto.
Generare chiavi SSH per il repository
Configura l'autenticazione delle chiavi SSH con il tuo repository IaC su GitHub e carica le chiavi su Cloud Storage.
Genera le chiavi SSH per il tuo repository GitHub.
Genera una coppia di chiavi SSH. Sostituisci your_email@example.com con il tuo indirizzo email GitHub. In Cloud Shell:
ssh-keygen -t rsa -b 4096 -m PEM -C "your_email@example.com"
Quando ti viene chiesto di "inserire un file in cui salvare la chiave", premi Invio. Viene accettata la posizione predefinita del file.
Quando ti viene chiesto di inserire una passphrase, premi Invio.
Prendi nota della directory SSH-KEYS-DIR in cui salvi le chiavi SSH scaricate. Per impostazione predefinita, la posizione è
$HOME/.ssh/
Copia la chiave pubblica SSH che hai generato nel repository GitHub come Esegui il deployment della chiave.
Copia la chiave pubblica SSH generata in Cloud Shell. Sostituisci SSH-KEYS-DIR con il percorso della tua directory.
cat SSH-KEYS-DIR/id_rsa.pub
Nel tuo account GitHub, vai al repository IAC-REPO-NAME
Fai clic su Impostazioni > Chiavi di deployment.
Fai clic su Aggiungi chiave di deployment e incolla la chiave pubblica SSH che hai copiato. Scegli un Titolo per la chiave.
Seleziona la casella di controllo "Consenti accesso in scrittura".
Fai clic su Salva.
Torna alla sessione di Cloud Shell
Crea il file
known_hosts
per GitHub. Nella sessione di Cloud Shell, esegui il comando:ssh-keyscan github.com >> ~/.ssh/known_hosts
Crea un bucket Cloud Storage nel tuo progetto
build
e caricalo chiavi SSH eknown_hosts
file. 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
Genera un token di accesso personale per GitHub. Questo token viene utilizzato eseguendo operazioni Git utilizzando chiamate API che il motore per suggerimenti per generare richieste di pull, controlla i manifest IaC aggiornati.
Nel tuo account GitHub, nell'angolo in alto a destra di qualsiasi pagina, fai clic sulla tua foto del profilo, quindi su Impostazioni.
Nella barra laterale a sinistra, fai clic su Impostazioni sviluppatore.
Nella barra laterale a sinistra, fai clic su Token di accesso personale.
Fai clic su Genera nuovo token.
Assegna al token un nome descrittivo.
Seleziona gli ambiti come repository.
Fai clic su Genera token.
Copia il token negli appunti.
Nella sessione di Cloud Shell, crea una variabile di ambiente.
export GITHUB_PAT=personal-access-token-you-copied
Configura Cloud Build
Connetti il tuo repository Git di IAC-REPO-NAME per l'integrazione in Cloud Build.
- Vai alla pagina dell'app Cloud Build in GitHub Marketplace.
- Scorri verso il basso e fai clic su Configura con Google Cloud Build in in fondo alla pagina.
- Se richiesto, accedi a GitHub.
- Seleziona Seleziona solo i repository. Usa il pulsante Seleziona repository per abilitare solo l'accesso IAC-REPO-NAME nell'app Cloud Build.
- Fai clic su Installa.
Accedi a Google Cloud.
Viene visualizzata la pagina Autorizzazione in cui ti viene chiesto di autorizzare l'app Google Cloud Build per connetterti a Google Cloud.
Fai clic su Autorizza Google Cloud Build di GoogleCloudBuild. Viene visualizzata la console Google Cloud.
Selezionare il tuo progetto Google Cloud.
Attiva la casella di controllo per il consenso e fai clic su Avanti.
Nella pagina Seleziona repository visualizzata, seleziona IAC-REPO-NAME repository GitHub
Fai clic su Connetti repository.
Fai clic su Crea un attivatore. In questo modo viene creata una definizione dell'attivatore.
Fai clic su Crea per salvare il trigger di build.
Per maggiori informazioni, vedi Esecuzione di build su GitHub.
La directory copiata contiene un file
cloudbuild.yaml
. Questo di configurazione del deployment delinea i passaggi eseguiti da un job Cloud Build attivata.steps: - name: hashicorp/terraform:0.12.0 args: ['init'] - name: hashicorp/terraform:0.12.0 args: ['apply', '-auto-approve']
Aggiungi autorizzazioni all'account di servizio Cloud Build per consentirgli di creare account di servizio, associare ruoli e macchine virtuali (istanze Compute Engine) nel progetto di test
gcloud projects add-iam-policy-binding $TEST_PROJECT_ID \ --member serviceAccount:$BUILD_PROJECT_NUMBER@cloudbuild.gserviceaccount.com \ --role roles/compute.admin \ --project $TEST_PROJECT_ID gcloud projects add-iam-policy-binding $TEST_PROJECT_ID \ --member serviceAccount:$BUILD_PROJECT_NUMBER@cloudbuild.gserviceaccount.com \ --role roles/iam.serviceAccountAdmin \ --project $TEST_PROJECT_ID gcloud projects add-iam-policy-binding $TEST_PROJECT_ID \ --member serviceAccount:$BUILD_PROJECT_NUMBER@cloudbuild.gserviceaccount.com \ --role roles/iam.securityAdmin \ --project $TEST_PROJECT_ID
Apri la pagina Trigger di build nella nella console Google Cloud.
Seleziona il progetto
build
e fai clic su Apri.Aggiorna la definizione dell'attivatore:
- Fai clic sul menu e poi su Modifica.
- Per Configurazione, seleziona l'opzione File di configurazione di Cloud Build (yaml o json) e digita
cloudbuild.yaml
nel campo di testo. - Fai clic su Salva.
Per testare manualmente il trigger di build, fai clic su Esegui sul la voce del trigger nell'elenco dei trigger.
Verifica che un'istanza Compute Engine denominata
tf-compute-1
e un account di servizio chiamatoTerraform Recommender Test
siano stati creati nel progetto di test dal job Cloud Build eseguito nel passaggio precedente
Esegui il deployment del servizio Cloud Run del parser per suggerimenti
In Cloud Shell, passa alla directory creata clonando il repository
cd $HOME/recommender-iac-pipeline-nodejs-tutorial/parser-service
Configura Google Cloud in modo da utilizzare una regione predefinita per i servizi Cloud Run. In questo tutorial utilizzi la regione us-central1, ma se preferisci puoi scegliere un'altra regione supportata.
gcloud config set run/region us-central1
La directory
parser-service
ha una sottodirectory stub che ha alcune JSON di payload di esempio con cui testare il servizio di analisi dei suggerimenti. Esegui i seguenti comandi sed per sostituire i segnaposto PROJECT_ID in questi JSON con l'ID 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
Esegui questo comando per creare una variabile di ambiente per l'immagine Docker.
export IMAGE=gcr.io/$BUILD_PROJECT_ID/recommender-parser:1.0
Crea l'immagine e caricala su Container Registry
gcloud builds submit --tag $IMAGE .
Crea un account di servizio per interagire con il servizio per suggerimenti con altri servizi Google Cloud nella pipeline. È buona prassi concedere autorizzazioni granulari ai servizi Cloud Run. Per ulteriori dettagli, consulta la sezione 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
Il servizio recommender-parser deve accedere alle chiavi SSH di GitHub e allo stato Terraform che hai caricato nei bucket Cloud Storage creati in precedenza. Aggiungi l'account di servizio come membro del 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
Concedi all'account di servizio del servizio di analisi del recommender 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
Esegui il deployment del servizio Cloud Run, chiamato recommender-parser. eseguendo il comando. Sostituisci GITHUB-ACCOUNT con il nome utente del tuo account GitHub, non con l'indirizzo email. Accettare 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
- Nella console Google Cloud, nel progetto
build
, accedi alla Pagina Firestore. - Quando ti viene chiesto di selezionare la modalità, fai clic su Seleziona modalità nativa.
- Seleziona
us-east1
come località predefinita. - Fai clic su Crea database.
Il serviziorecommender-parser
scrive documenti in questo database per le seguenti finalità:
- Per tenere traccia dei suggerimenti che ha recuperato dal API Recommender
- Chiama l'API Recommender dopo l'elaborazione dei consigli per
aggiornare lo stato di ogni consiglio elaborato su
SUCCEEDED
oFAILED
, a seconda dei casi. Si tratta di un passaggio chiave che rende la pipeline immutabile garantendo che i consigli non vengano elaborati in modo incompleto o più volte.
Configurare un job Cloud Scheduler
Crea un account di servizio utilizzato dai job di Cloud Scheduler per eseguire del motore per suggerimenti e analisi.
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
Assegna al service account il ruolo di esecuzione/richiamatore 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
Ottieni l'URL del servizio di consigli:
gcloud beta run services list --platform managed --project $BUILD_PROJECT_ID
Il job Cloud Scheduler richiama il /recommendation/iam per analizzare i suggerimenti IAM e /recommendationer/vm per analizzare i suggerimenti sul dimensionamento delle VM.
Crea una variabile per l'endpoint richiamato dai job di Cloud Scheduler. Sostituisci RECOMMENDER-SERVICE-URL con l'URL del servizio di consigli che hai copiato nel passaggio precedente.
export RECOMMENDER_ROUTE_TO_INVOKE_IAM=RECOMMENDER-SERVICE-URL/recommendation/iam
Dopo aver aggiunto le informazioni sul percorso, l'URL dovrebbe avere il seguente aspetto:
RECOMMENDER-SERVICE-URL/recommendation/iam
Crea un job Cloud Scheduler denominato
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 accetta tre input e devi crearlo come indicato di seguito:
repo
: il nome del repository GitHubIAC-REPO-NAME che hai creato in Creare un repository GitHub.projects
: un elenco / array di ID dei progetti Google Cloud che questo IaC GitHub di archiviazione a cui è mappato il repository. In questo tutorial, è il tuo progettotest
.stub
: il motore per suggerimenti genera suggerimenti IAM quando un sottoinsieme di autorizzazioni per un ruolo non viene utilizzato da 60 giorni e i suggerimenti per le dimensioni delle VM seguono un modello simile. Ai fini di: testando questa pipeline on demand,stub
può essere passato cometrue
in modo che la pipeline viene testata utilizzando i payload del motore per suggerimenti di esempio fornito 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 }"
Passaggi aggiuntivi
Cloud Build pubblica informazioni sulla build in un argomento Pub/Sub chiamato build-build create automaticamente quando hai abilitato l'API Cloud Build nel tuo progetto di build.
Esegui il seguente comando per verificare che l'argomento cloud-builds esista nel tuo progetto
build
:gcloud pubsub topics describe cloud-builds
Se l'argomento esiste, viene visualizzato il seguente output, dove BUILD-PROJECT-ID è l'ID progetto di compilazione:
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 eseguire l'iscrizione alle notifiche sulle build per creare manualmente l'argomento.
Crea un account di servizio utilizzato da Pub/Sub 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
L'account di servizio Pub/Sub deve essere associato ai ruoli necessari per poter pubblicare messaggi e invocare 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
Aggiungi l'
recommender-ci-subscription-sa
account di servizio che hai creato il servizio per suggerimenti sull'analisi del motore come membro con il ruoloinvoker
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
Vai a Pub/Sub nella console Google Cloud.
Fai clic sull'argomento Cloud Build.
Fai clic su Crea sottoscrizione.
In ID abbonamento, digita
recommender-service-build-events
.Per Tipo di pubblicazione, seleziona Push.
In Endpoint, digita l'URL del servizio di consigli a cui è stato aggiunto
/ci
.Seleziona Attiva l'autenticazione.
- Seleziona l'account di servizio
recommender-ci-subscription-sa
che hai creato. - Fai clic su Concedi in risposta al messaggio di richiesta.
- Seleziona l'account di servizio
Seleziona Scadenza conferma 60 secondi.
Mantieni le restanti impostazioni predefinite.
Fai clic su Crea.
Testa la pipeline
Il motore per suggerimenti genera suggerimenti IAM quando un insieme di autorizzazioni per un ruolo non viene utilizzato per 60 giorni. Dimensionamento delle VM
i consigli seguono uno schema simile. Ai fini del test di questa
pipeline on demand, utilizzerai i payload JSON dei consigli di esempio
forniti nella sottodirectory stub
del repository che hai clonato per
questo tutorial. In questo modo puoi testare la pipeline, escludendo le chiamate API che il recommender-parser effettua all'endpoint dell'API Recommender per aggiornare lo stato dei consigli 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 gli 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 invariati.
Nella console Google Cloud, accedi al progetto di test ed esamina risorsa creata. Dovresti avere quanto segue:
- Un'istanza Compute Engine denominata
tf-compute-1
con tipo di macchinag1-small
. - Un account di servizio denominato
Terraform Recommender Test
con il ruoloeditor
per il progetto di test.
- Un'istanza Compute Engine denominata
Nella Cloud Scheduler nel tuo progetto
build
, fai clic su Esegui ora per job Recommendationser-iam-scheduler.Fai clic sul job per visualizzare i log. Puoi anche visualizzare log del servizio di analisi del motore per suggerimenti per avere una visione dettagliata dei passaggi eseguite dal servizio.
Al termine dell'esecuzione del servizio, vai al tuo GitHub Repository IAC-REPO-NAME. Il servizio
recommender-parser
avrebbe generato una richiesta pull per te. Esamina i manifest IaC modificati che fanno parte di questa richiesta di pull e fai clic su Unisci richiesta di pull se le modifiche ai manifest IaC ti soddisfano.Quando unisci la richiesta di pull, viene creato un nuovo commit nel ramo principale. Questo attiva 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 controllare il relativo stato nella console Google Cloud.Al termine del job, vai al progetto di test. I payload di esempio forniti apportano le seguenti modifiche alle risorse del progetto di test.
- L'account di servizio di test Terraform, che in precedenza aveva il ruolo
editor
al momento del deployment, viene modificato inviewer
.
- L'account di servizio di test Terraform, che in precedenza aveva il ruolo
Esegui la pulizia
Per evitare che al tuo account Google Cloud vengano addebitati costi relativi alle risorse utilizzato in questo tutorial, elimina entrambi i progetti che hai creato.
Il modo più semplice per eliminare la fatturazione creato per il tutorial.
Per eliminare il progetto:
- In the Google Cloud console, go to the Manage resources page.
- In the project list, select the project that you want to delete, and then click Delete.
- In the dialog, type the project ID, and then click Shut down to delete the project.
Passaggi successivi
- Esplora le architetture di riferimento, i diagrammi e le best practice su Google Cloud. Consulta il nostro Cloud Architecture Center.
- Scopri di più su Google Cloud Policy Intelligence nel documentazione.