Onboarding dell'app

1. Prima di iniziare

Configurazione dell'ambiente autonomo

1. Accedi alla console Google Cloud e crea un nuovo progetto o riutilizzane uno esistente. Se non hai ancora un account Gmail o Google Workspace, devi crearne uno.

• Il nome del progetto è il nome visualizzato per i partecipanti a questo progetto. È una stringa di caratteri non utilizzata dalle API di Google e puoi aggiornarla in qualsiasi momento.
• L'ID progetto deve essere univoco in tutti i progetti Google Cloud ed è immutabile (non può essere modificato dopo essere stato impostato). Cloud Console genera automaticamente una stringa univoca, di solito non ti interessa di cosa si tratta. Nella maggior parte dei codelab, devi fare riferimento all'ID progetto (che in genere è identificato come PROJECT_ID), quindi, se non ti piace, generane un altro casuale oppure puoi provare il tuo e vedere se è disponibile. Viene "congelato" dopo la creazione del progetto.
• Esiste un terzo valore, un numero di progetto, utilizzato da alcune API. Scopri di più su tutti e tre questi valori nella documentazione.

Attenzione:un ID progetto deve essere univoco a livello globale e non può essere utilizzato da altri dopo che lo hai selezionato. Sei l'unico utente di questo ID. Se un progetto viene eliminato, il relativo ID non potrà mai più essere utilizzato.

Nota:se utilizzi un account Gmail, puoi lasciare la posizione predefinita impostata su Nessuna organizzazione. Se utilizzi un account Google Workspace, scegli una posizione adatta alla tua organizzazione.

2. Successivamente, devi abilitare la fatturazione in Cloud Console per utilizzare le risorse/API Cloud. L'esecuzione di questo codelab non dovrebbe costare molto, se non nulla. Per arrestare le risorse in modo da non incorrere in costi di fatturazione al termine di questo tutorial, segui le istruzioni di "pulizia" riportate alla fine del codelab. I nuovi utenti di Google Cloud possono beneficiare del programma prova senza costi di 300$.

2. Preparare il workspace

1. Apri l'editor di Cloud Shell visitando il seguente URL

https://ide.cloud.google.com

2. Assicurati che il nome del progetto sia impostato nella CLI

gcloud config set project {{project-id}}

export PROJECT_ID=$(gcloud config get-value project)

export PROJECT_NUMBER=$(gcloud projects describe $PROJECT_ID --format='value(projectNumber)')

3. Abilita API

gcloud services enable \

cloudbuild.googleapis.com \

secretmanager.googleapis.com

4. Fornire diritti a CloudDeploy

gcloud projects add-iam-policy-binding --member="serviceAccount:${PROJECT_NUMBER}@cloudbuild.gserviceaccount.com" --role roles/clouddeploy.admin ${PROJECT_ID}

gcloud projects add-iam-policy-binding --member="serviceAccount:${PROJECT_NUMBER}@cloudbuild.gserviceaccount.com" --role roles/container.developer ${PROJECT_ID}

gcloud projects add-iam-policy-binding --member="serviceAccount:${PROJECT_NUMBER}@cloudbuild.gserviceaccount.com" --role roles/iam.serviceAccountUser ${PROJECT_ID}

gcloud projects add-iam-policy-binding --member="serviceAccount:${PROJECT_NUMBER}@cloudbuild.gserviceaccount.com" --role roles/clouddeploy.jobRunner ${PROJECT_ID}

5. Nella finestra del terminale, clona l'origine dell'applicazione con il comando seguente:

git clone https://github.com/GoogleCloudPlatform/software-delivery-workshop.git

6. Passa alla directory e imposta l'area di lavoro dell'IDE sulla root del repository

cd software-delivery-workshop && rm -rf .git

cd delivery-platform && cloudshell workspace .

3. Utilizzo di modelli di app predefiniti e personalizzati

Gli sviluppatori devono poter scegliere tra una serie di modelli comunemente utilizzati all'interno dell'organizzazione. La procedura di onboarding creerà un insieme centralizzato di repository di modelli archiviati nel tuo account GitHub. Nei passaggi successivi, questi repository di modelli verranno copiati e modificati per essere utilizzati come base per le nuove applicazioni. Per questo lab, inizializzerai il repository dei modelli con una struttura di esempio fornita qui. Puoi aggiungere i tuoi modelli aggiungendo altre cartelle modellate in base all'esempio.

In questo passaggio creerai il tuo repository per contenere i modelli di app, a partire dai file di esempio forniti. Viene fornito uno script helper per semplificare le interazioni con GitHub.

Questi sono passaggi una tantum utilizzati per popolare i repository dei modelli. I passaggi futuri riutilizzeranno questi repository.

Configurare l'accesso a GitHub

I passaggi di questo tutorial chiamano l'API GitHub per creare e configurare i repository. Il tuo nome utente GitHub e un token di accesso personale sono necessari in vari punti successivi. Lo script riportato di seguito ti aiuterà ad acquisire i valori e a memorizzarli come variabili locali per un utilizzo successivo.

source ./onboard-env.sh

echo Git Username: $GIT_USERNAME

echo Git Base URL: $GIT_BASE_URL

Crea il repository dei modelli di app

In questo lab vengono forniti modelli di applicazioni di esempio per mostrare come integrare i tuoi modelli di base. In questo passaggio crei una tua copia di questi file in un repository chiamato mcd-app-templates nel tuo account GitHub.

1. Copia il modello nella directory di lavoro

cp -R $BASE_DIR/resources/repos/app-templates $WORK_DIR

cd $WORK_DIR/app-templates

2. Crea un repository remoto vuoto nel tuo account GitHub

$BASE_DIR/scripts/git/gh.sh create mcd-app-templates

3. Esegui il push del repository di modelli nel repository remoto

git init && git symbolic-ref HEAD refs/heads/main && git add . && git commit -m "initial commit"

git remote add origin $GIT_BASE_URL/mcd-app-templates

git push origin main

4. Pulisci la directory di lavoro

cd $BASE_DIR

rm -rf $WORK_DIR/app-templates

Crea il repository delle configurazioni di base condivise

Questo tutorial utilizza uno strumento chiamato Kustomize che utilizza file di configurazione di base condivisi da più team, quindi sovrappone le configurazioni specifiche dell'applicazione. Ciò consente ai team della piattaforma di scalare in più team e ambienti.

In questo passaggio, crea il repository di configurazione condiviso denominato mcd-shared_kustomize dagli esempi forniti.

1. Copia il modello nella directory di lavoro

cp -R $BASE_DIR/resources/repos/shared-kustomize $WORK_DIR

cd $WORK_DIR/shared-kustomize

2. Crea un repository remoto vuoto nel tuo account GitHub

$BASE_DIR/scripts/git/gh.sh create mcd-shared_kustomize

3. Esegui il push del repository di modelli nel repository remoto

git init && git symbolic-ref HEAD refs/heads/main && git add . && git commit -m "initial commit"

git remote add origin $GIT_BASE_URL/mcd-shared_kustomize

git push origin main

4. Pulisci la directory di lavoro

cd $BASE_DIR

rm -rf $WORK_DIR/shared-kustomize

Ora che hai creato i repository dei modelli, puoi utilizzarli per creare un'istanza dell'app.

4. Creazione di una nuova istanza di un'applicazione

La creazione di una nuova applicazione da un modello spesso richiede la sostituzione delle variabili segnaposto con valori reali in più file nella struttura del modello. Una volta completata la sostituzione, viene creato un nuovo repository per la nuova istanza dell'app. È questo repository dell'istanza dell'app che gli sviluppatori cloneranno e utilizzeranno nello sviluppo quotidiano.

In questo passaggio, sostituirai i valori in un modello di app e pubblicherai i file risultanti in un nuovo repository.

Definisci un nome per la nuova applicazione

export APP_NAME=my-app

Recupera il repository di modelli Golang

cd $WORK_DIR/

git clone -b main $GIT_BASE_URL/mcd-app-templates app-templates

rm -rf app-templates/.git

cd app-templates/golang

Sostituisci i valori segnaposto

Una delle esigenze più comuni per l'onboarding è la sostituzione delle variabili nei modelli con le istanze effettive utilizzate nell'applicazione. Ad esempio, fornendo il nome dell'applicazione. Il comando seguente crea istanze di tutti i file .tmpl con i valori archiviati nelle variabili di ambiente.

for template in $(find . -name '*.tmpl'); do envsubst < ${template} > ${template%.*}; done

Crea un nuovo repository e archivia i file aggiornati

1. Crea un repository remoto vuoto nel tuo account GitHub

$BASE_DIR/scripts/git/gh.sh create ${APP_NAME}

2. Esegui il push del repository di modelli nel repository remoto

git init && git symbolic-ref HEAD refs/heads/main && git add . && git commit -m "initial commit"

git remote add origin $GIT_BASE_URL/${APP_NAME}

git push origin main

Ora che l'istanza dell'app è stata creata, è il momento di implementare le build continue.

5. Configurazione dell'esecuzione automatizzata della pipeline

La parte centrale di un sistema di integrazione continua è la capacità di eseguire la logica della pipeline in base agli eventi provenienti dal sistema di controllo della versione. Quando uno sviluppatore esegue il commit del codice nel repository, vengono attivati eventi che possono essere configurati per attivare processi in altri sistemi.

In questo passaggio configurerai GitHub per chiamare Google Cloud Build ed eseguire la pipeline ogni volta che gli utenti eseguono il commit o taggano il codice nel repository.

Attiva accesso sicuro

Per configurare l'accesso sicuro alla pipeline dell'applicazione, avrai bisogno di due elementi. Una chiave API e un secret univoco per la pipeline.

Chiave API

La chiave API viene utilizzata per identificare il client che chiama una determinata API. In questo caso, il client sarà GitHub. Una best practice non trattata qui consiste nel limitare l'ambito della chiave API solo alle API specifiche a cui accederà il client. Hai creato la chiave in un passaggio precedente.

1. Puoi esaminare la chiave facendo clic su questo link.
2. Puoi assicurarti che il valore sia impostato eseguendo questo comando

echo $API_KEY_VALUE

Pipeline Secret

I secret vengono utilizzati per autorizzare un chiamante e assicurarsi che disponga dei diritti per il job di destinazione di Cloud Build specifico. Potresti avere due repository diversi in GitHub che dovrebbero avere accesso solo alle proprie pipeline. Mentre API_KEY limita le API che possono essere utilizzate da GitHub (in questo caso viene chiamata l'API Cloud Build), il secret limita il job nell'API Cloud Build che può essere eseguito dal client.

1. Definisci il nome, la posizione e il valore del secret

SECRET_NAME=${APP_NAME}-webhook-trigger-cd-secret

SECRET_PATH=projects/${PROJECT_NUMBER}/secrets/${SECRET_NAME}/versions/1

SECRET_VALUE=$(sed "s/[^a-zA-Z0-9]//g" <<< $(openssl rand -base64 15))

2. Crea il secret

printf ${SECRET_VALUE} | gcloud secrets create ${SECRET_NAME} --data-file=-

3. Consenti a Cloud Build di leggere il secret

gcloud secrets add-iam-policy-binding ${SECRET_NAME} \

--member=serviceAccount:service-${PROJECT_NUMBER}@gcp-sa-cloudbuild.iam.gserviceaccount.com \

--role='roles/secretmanager.secretAccessor'

Crea trigger di Cloud Build

Il trigger di Cloud Build è la configurazione che eseguirà effettivamente i processi CICD.

Per configurare correttamente il trigger, è necessario fornire alcuni valori chiave al momento della creazione del job.

4. Definisci il nome del trigger e la posizione del file di configurazione

export TRIGGER_NAME=${APP_NAME}-clouddeploy-webhook-trigger

export BUILD_YAML_PATH=$WORK_DIR/app-templates/golang/build/cloudbuild-cd.yaml

5. Definisci la posizione del repository di configurazione di base condiviso.

export KUSTOMIZE_REPO=${GIT_BASE_URL}/mcd-shared_kustomize

6. Nello script onboard-env.sh è stata impostata una variabile che definisce il registro dei container del progetto. Controlla il valore con il comando riportato di seguito.

echo $IMAGE_REPO

7. Crea il trigger webhook di Cloud Build utilizzando le variabili create in precedenza. La posizione del repository dell'applicazione viene estratta dal corpo della richiesta da GitHub. Un valore di seguito fa riferimento al percorso nel corpo della richiesta in cui si trovagcloud alpha builds triggers create webhook \

    `--name=${TRIGGER_NAME} \`
   
    `--substitutions='_APP_NAME='${APP_NAME}',_APP_REPO=$(body.repository.git_url),_CONFIG_REPO='${GIT_BASE_URL}'/'${CLUSTER_CONFIG_REPO}',_DEFAULT_IMAGE_REPO='${IMAGE_REPO}',_KUSTOMIZE_REPO='${GIT_BASE_URL}'/'${SHARED_KUSTOMIZE_REPO}',_REF=$(body.ref)' \`
   
    `--inline-config=$BUILD_YAML_PATH \`
   
    `--secret=${SECRET_PATH}`
   

8. Esamina il trigger Cloud Build appena creato nella console visitando questo link.
9. Definisci una variabile per l'URL dell'endpoint, che verrà utilizzata da GitHub nel passaggio successivo.

WEBHOOK_URL="https://cloudbuild.googleapis.com/v1/projects/${PROJECT_ID}/triggers/${TRIGGER_NAME}:webhook?key=${API_KEY_VALUE}&secret=${SECRET_VALUE}"

Configura il webhook GitHub

1. Configurare il webhook in GitHub

$BASE_DIR/scripts/git/gh.sh create_webhook ${APP_NAME} $WEBHOOK_URL

2. Vai al repository dell'applicazione e controlla il webhook appena configurato

REPO_URL=${GIT_BASE_URL}/${APP_NAME}/settings/hooks

echo $REPO_URL

Ora che hai eseguito manualmente tutti i passaggi necessari per creare una nuova applicazione, è il momento di automatizzarla in uno script.

6. Automatizzare tutti i passaggi di onboarding

In pratica, non è fattibile eseguire ciascuno dei passaggi precedenti per ogni nuova applicazione. La logica deve invece essere incorporata in uno script per una facile esecuzione. I passaggi precedenti sono già stati inclusi in uno script per il tuo utilizzo.

In questo passaggio utilizzerai lo script fornito per creare una nuova applicazione

Crea una nuova applicazione

1. Assicurati di trovarti nella directory corretta.

cd $BASE_DIR

2. Crea una nuova applicazione

export APP_NAME=demo-app

./app.sh create ${APP_NAME}

Tutti i passaggi vengono eseguiti automaticamente.

Esamina il repository GitHub

A questo punto potrai esaminare il nuovo repository in GitHub.

1. Recupera l'URL del repository GitHub eseguendo il seguente comando

echo ${GIT_BASE_URL}/demo-app

2. Apri l'URL con il browser web per esaminare la nuova applicazione
3. Prendi nota degli esempi in cui le variabili del modello sono state sostituite con i valori dell'istanza, come mostrato nell'URL riportato di seguito.

echo ${GIT_BASE_URL}/demo-app/blob/main/k8s/prod/deployment.yaml#L24

4. Controlla il webhook configurato all'URL riportato di seguito

echo ${GIT_BASE_URL}/demo-app/settings/hooks

Esamina il trigger di Cloud Build

Il trigger è stato configurato automaticamente dallo script

1. Esamina il trigger Cloud Build nella console visitando questo link.
2. Esamina la cronologia delle build in questa pagina.