Onboarding dell'app

1. Prima di iniziare

Configurazione dell'ambiente a tuo ritmo

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 al progetto. Si tratta di 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 è importante quale sia. Nella maggior parte dei codelab, dovrai fare riferimento all'ID progetto (in genere identificato come PROJECT_ID), quindi se non ti piace, generane un altro casuale oppure puoi provare il tuo e vedere se è disponibile. Dopo la creazione del progetto, viene "congelato".
• Esiste un terzo valore, un Numero 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 la selezione. Sei l'unico utente di quell'ID. Se un progetto viene eliminato, l'ID non può essere riutilizzato.

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

2. Successivamente, dovrai abilitare la fatturazione nella console Cloud per utilizzare le API/risorse Cloud. Eseguire questo codelab non dovrebbe costare molto. Per arrestare le risorse in modo da non incorrere in fatturazione oltre questo tutorial, segui le istruzioni di "pulizia" riportate alla fine del codelab. I nuovi utenti di Google Cloud possono partecipare al programma Prova senza costi di 300$.

2. Preparazione dell'area di lavoro

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 nell'interfaccia a riga di comando

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 i 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 il codice sorgente dell'applicazione con il seguente comando:

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

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

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

cd delivery-platform && cloudshell workspace .

3. Utilizzare modelli di app predefiniti e personalizzati

Gli sviluppatori devono poter scegliere tra una serie di modelli comunemente utilizzati all'interno dell'organizzazione. Il processo 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, seminerai 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 dai file di esempio forniti. Viene fornito uno script di supporto per semplificare le interazioni con GitHub.

Si tratta di passaggi una tantum utilizzati per compilare i repository di modelli. I passaggi futuri riutilizzeranno questi repository.

Configurare l'accesso a GitHub

I passaggi di questo tutorial richiamano l'API GitHub per creare e configurare i repository. Il tuo nome utente GitHub e un token di accesso personale sono obbligatori in vari punti che seguono. Lo script riportato di seguito ti aiuterà ad acquisire i valori e a memorizzarli come variabili locali per utilizzarli in un secondo momento.

source ./onboard-env.sh

echo Git Username: $GIT_USERNAME

echo Git Base URL: $GIT_BASE_URL

Crea repository del modello di app

I modelli di applicazione di esempio sono forniti insieme a questo lab come esempio di come integrare i tuoi modelli di base. In questo passaggio crei una tua copia di questi file in un repository denominato 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. Creare 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 un repository di configurazioni di base condivise

Questo tutorial utilizza uno strumento chiamato Kustomize che utilizza file di configurazione di base condivisi da più team e sovrappone configurazioni specifiche dell'applicazione. Ciò consente ai team delle piattaforme di scalare tra molti team e ambienti.

In questo passaggio crei 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. Creare 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

Dopo aver creato i repository di 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 della struttura del modello. Una volta completata la sostituzione, viene creato un nuovo repository per la nuova istanza dell'app. È questo repository di istanze dell'app che gli sviluppatori cloneranno e utilizzeranno nel loro lavoro quotidiano di sviluppo.

In questo passaggio devi sostituire i valori in un modello di app e pubblicare 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

Sostituire i valori segnaposto

Una delle esigenze più comuni per l'onboarding è sostituire le 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 memorizzati 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. Creare un repository remoto vuoto nel tuo account GitHub

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

2. Esegui il push del repository dei 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 della pipeline automatica

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

In questo passaggio configurerai GitHub in modo che chiami Google Cloud Build ed esegua la pipeline ogni volta che gli utenti eseguono commit o taggano il codice nel proprio repository.

Abilita accesso sicuro

Per configurare l'accesso sicuro alla pipeline di applicazioni, sono necessari due elementi. Una chiave API e un segreto 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 è 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

Secret della pipeline

I secret vengono utilizzati per autorizzare un chiamante e assicurarsi che disponga dei diritti per il job target di Cloud Build specifico. Potresti avere due repository diversi su 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 segreto limita i job nell'API Cloud Build che possono essere eseguiti 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.

Il job richiede che vengano forniti alcuni valori chiave al momento della creazione per configurare correttamente l'attivatore.

4. Definisci il nome dell'attivatore 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 registry dei container del progetto. Rivedi il valore con il comando seguente.

echo $IMAGE_REPO

7. Crea il trigger webhook di CloudBuild 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 l'attivatore Cloud Build appena creato nella console visitando questo link
9. Definisci una variabile per l'URL dell'endpoint, che verrà utilizzato 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 di GitHub

1. Configura il webhook in GitHub

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

2. Vai al repository dell'applicazione ed esamina 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. Automatizzazione di tutti i passaggi di onboarding

In pratica non è possibile 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 a tua disposizione.

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 su 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. Osserva gli esempi in cui le variabili del modello sono state sostituite con valori di istanza, come mostrato nell'URL di seguito

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

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

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

rivedi il trigger di Cloud Build

L'attivatore è stato configurato automaticamente dallo script

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