Automatizzare le ricompilazioni delle immagini container per sincronizzare gli aggiornamenti delle immagini di base

Cloud Workstations ti consente di creare e utilizzare immagini personalizzate per le tue workstation. Dopo che un'immagine personalizzata è in uso, è utile automatizzare una ricompilazione dell'immagine personalizzata per includere correzioni e aggiornamenti disponibili nelle immagini di base.

In questo tutorial imparerai a creare una pipeline automatizzata per assicurarti di includere aggiornamenti della sicurezza e patch nelle immagini delle workstation personalizzate.

Obiettivi

Seguendo questo tutorial, creerai una pipeline automatica per l'immagine di base con questi passaggi:

  1. Crea un repository Artifact Registry per archiviare ed eseguire la scansione dell'immagine personalizzata.
  2. Configura GitHub con Google Cloud per archiviare le configurazioni delle immagini.
  3. Crea un trigger di Cloud Build per automatizzare la creazione e il deployment di immagini personalizzate in Artifact Registry.
  4. Configura Cloud Scheduler per avviare le build a intervalli regolari.
  5. Esamina i risultati dei processi automatizzati.

Costi

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

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

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

Al termine delle attività descritte in questo documento, puoi evitare l'addebito di ulteriori costi eliminando le risorse che hai creato. Per saperne di più, consulta Esegui la pulizia.

Prima di iniziare

  1. Accedi al tuo Google Cloud account. Se non conosci Google Cloud, crea un account per valutare le prestazioni dei nostri prodotti in scenari reali. I nuovi clienti ricevono anche 300 $di crediti senza costi per l'esecuzione, il test e il deployment dei carichi di lavoro.
  2. In the Google Cloud console, on the project selector page, select or create a Google Cloud project.

    Roles required to select or create a project

    • Select a project: Selecting a project doesn't require a specific IAM role—you can select any project that you've been granted a role on.
    • Create a project: To create a project, you need the Project Creator role (roles/resourcemanager.projectCreator), which contains the resourcemanager.projects.create permission. Learn how to grant roles.

    Go to project selector

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

  4. Enable the Artifact Registry, Container Scanning API, Cloud Build, and Cloud Scheduler APIs, if any are not already enabled.

    Roles required to enable APIs

    To enable APIs, you need the serviceusage.services.enable permission. If you created the project, then you likely already have this permission through the Owner role (roles/owner). Otherwise, you can get this permission through the Service Usage Admin role (roles/serviceusage.serviceUsageAdmin). Learn how to grant roles.

    Enable the APIs

  5. Install the Google Cloud CLI.

  6. If you're using an external identity provider (IdP), you must first sign in to the gcloud CLI with your federated identity.

  7. To initialize the gcloud CLI, run the following command:

    gcloud init
  8. In the Google Cloud console, on the project selector page, select or create a Google Cloud project.

    Roles required to select or create a project

    • Select a project: Selecting a project doesn't require a specific IAM role—you can select any project that you've been granted a role on.
    • Create a project: To create a project, you need the Project Creator role (roles/resourcemanager.projectCreator), which contains the resourcemanager.projects.create permission. Learn how to grant roles.

    Go to project selector

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

  10. Enable the Artifact Registry, Container Scanning API, Cloud Build, and Cloud Scheduler APIs, if any are not already enabled.

    Roles required to enable APIs

    To enable APIs, you need the serviceusage.services.enable permission. If you created the project, then you likely already have this permission through the Owner role (roles/owner). Otherwise, you can get this permission through the Service Usage Admin role (roles/serviceusage.serviceUsageAdmin). Learn how to grant roles.

    Enable the APIs

  11. Install the Google Cloud CLI.

  12. If you're using an external identity provider (IdP), you must first sign in to the gcloud CLI with your federated identity.

  13. To initialize the gcloud CLI, run the following command:

    gcloud init

Prepara l'ambiente

Prima di procedere, assicurati di impostare le seguenti variabili di ambiente.

  1. Imposta l'ID progetto per il progetto cloud che intendi utilizzare:

    PROJECT_ID=$PROJECT_ID
    
  2. Imposta il nome utente GitHub in cui intendi archiviare il repository:

    GITHUB_USER=$GITHUB_ID
    
  3. Imposta le variabili PROJECT_NUMBER e REGION da utilizzare durante la procedura:

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

    Nell'esempio precedente, sostituisci $REGION con il nome della regione che intendi utilizzare, ad esempio us-central1.

    Per ulteriori informazioni sulle regioni disponibili, consulta Località di Cloud Workstations.

Crea un repository Artifact Registry

In questo tutorial utilizzerai Artifact Registry per archiviare ed eseguire la scansione delle immagini.

  1. Crea un repository con il seguente comando:

    gcloud artifacts repositories create custom-images \
          --repository-format=docker \
          --location=$REGION \
          --description="Docker repository"
    

    Sostituisci $REGION con il nome della regione che intendi utilizzare.

  2. Configura Docker in modo che utilizzi le credenziali gcloud CLI quando accedi ad Artifact Registry.

    gcloud auth configure-docker $REGION-docker.pkg.dev
    

    Per disattivare Artifact Analysis, esegui questo comando:

    gcloud services disable containerscanning.googleapis.com
    

Configura il repository GitHub

In pratica, il Dockerfile per le immagini personalizzate viene conservato in un repository Git. Il processo automatizzato accede a questo repository durante il processo di compilazione per eseguire il pull delle configurazioni e del Dockerfile pertinenti.

Crea un fork del repository di esempio

Per creare un fork di un repository di esempio che fornisce definizioni di container:

  1. Fai clic su questo link per creare un nuovo fork. del repository software-delivery-workshop.
  2. Se richiesto, accedi a GitHub.
  3. Seleziona il tuo nome utente GitHub come proprietario. Il nome del repository viene visualizzato come software-delivery-workshop.
  4. Fai clic su Crea fork e attendi alcuni secondi per il completamento della procedura.

Connetti Cloud Build a GitHub

Poi, connetti il repository a Cloud Build utilizzando la funzionalità di connessione GitHub integrata. Fai clic sul link al repository GitHub e segui le istruzioni per completare la procedura. Non devi creare il trigger nell'ultimo passaggio della procedura guidata e puoi saltare gli ultimi passaggi perché puoi farlo in un secondo momento dalla riga di comando.

Se utilizzi una soluzione di repository Git diversa, puoi anche seguire le istruzioni per connettere Cloud Build a GitLab o Bitbucket.

Crea un trigger di Cloud Build

Il repository di esempio contiene una definizione di container e una configurazione di Cloud Build utilizzata per creare l'immagine container. In questo passaggio creerai un trigger di Cloud Build che esegue le istruzioni nel cloudbuild.yaml file che puoi trovare nella labs/cloudbuild-scheduled-jobs/code-oss-java labs/cloudbuild-scheduled-jobs/code-oss-java.

gcloud builds triggers create manual \
    --name=custom-image-trigger \
    --repo=$GITHUB_USER/software-delivery-workshop \
    --repo-type=GITHUB \
    --branch=main \
    --build-config=labs/cloudbuild-scheduled-jobs/code-oss-java/cloudbuild.yaml \
    --substitutions=_REGION=$REGION,_AR_REPO_NAME=custom-images,_AR_IMAGE_NAME=code-oss-java,_IMAGE_DIR=labs/cloudbuild-scheduled-jobs/code-oss-java

TRIGGER_ID=$(gcloud builds triggers list \
    --filter=name="custom-image-trigger" --format="value(id)")

Questa configurazione di esempio configura quanto segue:

  • Il comando gcloud CLI crea un trigger manuale in Cloud Build denominato custom-image-trigger come indicato da il flag name nella seconda riga.
  • Le tre righe successive contengono flag relativi al repository GitHub di origine:
  • Il flag build-config indica il percorso del file Cloud Build nel repository Git.
  • Per rendere dinamico il job, utilizza il flag substitutions. Per questo job, il comando passa le seguenti variabili:

    • Regione, $_REGION
    • Nome del repository Artifact Registry, $_AR_REPO_NAME
    • Nome dell'immagine container, $_AR_IMAGE_NAME
    • Posizione del Dockerfile da creare, $_IMAGE_DIR

    Visualizza il cloudbuild.yaml file per vedere come vengono utilizzate queste variabili nella procedura.

  • Dopo aver creato il trigger, viene recuperato il nome univoco del trigger e memorizzato nella variabile di ambiente $TRIGGER_ID per un utilizzo successivo.

Configura Cloud Scheduler

Per assicurarti che le immagini siano aggiornate con gli aggiornamenti e le patch più recenti, utilizza Cloud Scheduler per eseguire il trigger di Cloud Build con una frequenza impostata. Per questo tutorial, il job viene eseguito ogni giorno. In pratica, imposta questa frequenza in base alle esigenze della tua organizzazione per assicurarti che gli aggiornamenti più recenti siano sempre inclusi.

  1. Concedi un ruolo obbligatorio al account di servizio predefinito per richiamare il trigger di Cloud Build:

    gcloud projects add-iam-policy-binding $PROJECT_ID \
        --member="serviceAccount:$PROJECT_NUMBER-compute@developer.gserviceaccount.com" \
        --role="roles/cloudbuild.builds.editor"
    
  2. Concedi un ruolo obbligatorio al account di servizio Cloud Build per caricare le immagini in Artifact Registry:

    gcloud projects add-iam-policy-binding $PROJECT_ID \
        --member=serviceAccount:$PROJECT_NUMBER@cloudbuild.gserviceaccount.com \
        --role="roles/artifactregistry.admin"
    
  3. Crea il job Cloud Scheduler con il seguente comando:

    gcloud scheduler jobs create http run-build \
        --schedule='0 1 * * *' \
        --uri=https://cloudbuild.googleapis.com/v1/projects/$PROJECT_ID/locations/global/triggers/$TRIGGER_ID:run \
        --location=us-central1 \
        --oauth-service-account-email=$PROJECT_NUMBER-compute@developer.gserviceaccount.com \
        --oauth-token-scope=https://www.googleapis.com/auth/cloud-platform
    
  4. Il job è impostato per essere eseguito una volta al giorno. Tuttavia, per testare immediatamente la funzionalità, esegui il job manualmente da Cloud Scheduler:

    Vai a Cloud Scheduler

    1. Nella pagina Cloud Scheduler, trova la voce appena creata denominata run-build.
    2. Nella colonna Azioni, fai clic sul menu more_vertAltre opzioni per quella riga.
    3. Fai clic su Forza l'esecuzione di un job per testare manualmente il sistema.
    4. Dopo che il comando è stato eseguito correttamente, passa alla pagina della cronologia di Cloud Build per esaminare l'avanzamento:

      Vai alla cronologia di Cloud Build

Esamina i risultati

Poiché hai abilitato l'API Container Scanning nell'ambito della procedura di configurazione, Artifact Registry esegue automaticamente la scansione delle immagini per rilevare eventuali vulnerabilità di sicurezza.

Per esaminare le vulnerabilità:

  1. Apri la pagina Repository di Artifact Registry:

    Vai ai repository di Artifact Registry

  2. Nell'elenco dei repository, fai clic su un repository.

  3. Fai clic sul nome di un'immagine. I totali delle vulnerabilità per ogni digest dell'immagine vengono visualizzati nella colonna Vulnerabilità.

    Pagina dei repository Artifact Registry che mostra un nome immagine di esempio

  4. Per visualizzare l'elenco delle vulnerabilità di un'immagine, fai clic sul link nella colonna Vulnerabilità. L'elenco delle vulnerabilità mostra la gravità, la disponibilità di una correzione e il nome del pacchetto che contiene la vulnerabilità.

    Pagina Vulnerabilità di Artifact Registry che mostra un elenco di vulnerabilità di esempio

Esegui la pulizia

Per evitare che al tuo account Google Cloud vengano addebitati costi relativi alle risorse utilizzate in questo tutorial, elimina il progetto che contiene le risorse oppure mantieni il progetto ed elimina le singole risorse.

Per evitare che al tuo Google Cloud account vengano addebitati costi relativi alle risorse utilizzate in questa pagina, assicurati di eliminare le risorse di cui non hai più bisogno.

Per eliminare un Google Cloud progetto dalla Google Cloud console o da gcloud CLI:

Console

  1. Nella Google Cloud console, vai alla pagina Gestisci risorse.

    Vai a Gestisci risorse

  2. Nell'elenco dei progetti, seleziona il progetto che vuoi eliminare, quindi fai clic su Elimina.
  3. Nella finestra di dialogo, digita l'ID progetto, quindi fai clic su Chiudi per eliminare il progetto.

gcloud

    Elimina un Google Cloud progetto:

    gcloud projects delete PROJECT_ID

Per ulteriori informazioni sull'eliminazione di altre risorse, come cluster di workstation, configurazioni di workstation e workstation, consulta Eliminare le risorse.

Passaggi successivi