Panoramica di Cloud Build

Cloud Build è un servizio che esegue le tue build su Google Cloud.

Cloud Build può importare codice sorgente da una varietà di repository o spazi di spazio di archiviazione sul cloud, eseguire una build in base alle tue specifiche e produrre artefatti come container Docker o archivi Java.

Puoi anche utilizzare Cloud Build per proteggere la catena di fornitura del software. Le funzionalità di Cloud Build soddisfano i requisiti del livello 3 della catena di fornitura per Software Artifacts (SLSA). Per indicazioni sulla protezione dei processi di build, consulta l'articolo Salvaguardia delle build.

Configurazione e passi di build

Puoi scrivere una configurazione di compilazione per fornire istruzioni a Cloud Build su quali attività eseguire. Puoi configurare le build per recuperare le dipendenze, eseguire test delle unità, analisi statiche e test di integrazione e creare artefatti con strumenti di creazione come docker, gradle, maven, bazel e gulp.

Cloud Build esegue la build come una serie di passi di build, in cui ogni passaggio viene eseguito in un container Docker. L'esecuzione dei passaggi di build è simile all'esecuzione di comandi in uno script.

Puoi utilizzare i passi di build forniti da Cloud Build e dalla community di Cloud Build oppure scrivere passi di build personalizzati:

Ogni passaggio di build viene eseguito con il container collegato a una rete Docker locale denominata cloudbuild. Ciò consente ai passi di build di comunicare tra loro e condividere dati. Per maggiori informazioni sulla rete cloudbuild, consulta Rete Cloud Build.

Puoi utilizzare immagini Docker Hub standard in Cloud Build, ad esempio Ubuntu e Gradle.

Avvio delle build

Puoi avviare manualmente le build in Cloud Build utilizzando Google Cloud CLI o l'API Cloud Build oppure utilizzare gli attivatori di build di Cloud Build per creare un flusso di lavoro automatizzato di integrazione continua/distribuzione continua (CI/CD) che avvii nuove build in risposta alle modifiche al codice.

Puoi integrare trigger di build con molti repository di codice, tra cui Cloud Source Repositories, GitHub e Bitbucket.

Visualizzazione dei risultati della build

Puoi visualizzare i risultati delle build utilizzando gcloud CLI, l'API Cloud Build o utilizzare la pagina Cronologia build nella sezione Cloud Build della console Google Cloud, in cui vengono visualizzati dettagli e log per ogni build eseguita da Cloud Build. Per istruzioni, vedi Visualizzare i risultati della build.

Come funzionano le build

I passaggi seguenti descrivono, in generale, il ciclo di vita di una build di Cloud Build:

  1. Prepara il codice dell'applicazione e tutti gli asset necessari.
  2. Creare un file di configurazione di compilazione in formato YAML o JSON, contenente istruzioni per Cloud Build.
  3. Invia la build a Cloud Build.
  4. Cloud Build esegue la build in base alla configurazione della build che hai fornito.
  5. Se applicabile, viene eseguito il push di tutti gli artefatti creati in Artifact Registry.

Docker

Cloud Build utilizza Docker per eseguire le build. Per ogni passaggio di build, Cloud Build esegue un container Docker come istanza di docker run. Attualmente Cloud Build esegue il motore Docker versione 20.10.17.

Interfacce di Cloud Build

Puoi utilizzare Cloud Build con la console Google Cloud, lo strumento a riga di comando gcloud o l'API REST di Cloud Build.

Nella console Google Cloud, puoi visualizzare i risultati delle build di Cloud Build nella pagina Cronologia build e automatizzare le build in Trigger di build.

Puoi utilizzare gcloud CLI per creare e gestire le build. Puoi eseguire comandi per eseguire attività come l'invio di una build, l'elenco delle build e l'annullamento di una build.

Puoi richiedere le build utilizzando l'API REST Cloud Build.

Come per altre API della piattaforma Cloud, devi autorizzare l'accesso utilizzando OAuth2. Dopo aver ottenuto l'accesso, puoi utilizzare l'API per avviare nuove build, visualizzarne lo stato e i dettagli, elencare le build per progetto e annullare quelle attualmente in elaborazione.

Per ulteriori informazioni, consulta la documentazione dell'API.

Pool predefiniti e pool privati

Per impostazione predefinita, quando esegui una build su Cloud Build, questa viene eseguita in un ambiente sicuro e ospitato con accesso alla rete internet pubblica. Ogni build viene eseguita sul proprio worker ed è isolata dagli altri carichi di lavoro. Puoi personalizzare la build in diversi modi, ad esempio aumentando le dimensioni del tipo di macchina o assegnando più spazio su disco. Al pool predefinito sono previsti dei limiti al livello di personalizzazione dell'ambiente, in particolare per quanto riguarda l'accesso alla rete privata.

I pool privati sono pool privati e dedicati di worker che offrono una maggiore personalizzazione sull'ambiente di build, inclusa la possibilità di accedere alle risorse in una rete privata. I pool privati, simili ai pool predefiniti, sono ospitati e completamente gestiti da Cloud Build e fanno lo scale up e lo scale down fino a zero, senza infrastruttura da configurare, eseguire l'upgrade o scalare. Poiché i pool privati sono risorse specifiche del cliente, puoi configurarli in più modi.

Per scoprire di più sui pool privati e sulla differenza di funzionalità tra piscina predefinita e pool privato, consulta la panoramica del pool privato.

Crea sicurezza

Cloud Build offre diverse funzionalità per proteggere le tue build, tra cui:

  • Build automatiche

    Una build automatica o una build basata su script definisce tutti i passaggi della build nello script o nella configurazione della build, inclusi i passaggi per recuperare il codice sorgente e quelli per creare il codice. L'unico comando manuale, se presente, è il comando per eseguire la build. Cloud Build utilizza un file di configurazione di compilazione per fornire i passaggi di build in Cloud Build.

    Le build automatiche garantiscono la coerenza nei passaggi della build. Tuttavia, è anche importante eseguire le build in un ambiente coerente e affidabile.

    Sebbene le build locali possano essere utili per il debug, il rilascio di software da build locali può introdurre molti problemi di sicurezza, incongruenze ed inefficienze nel processo di compilazione.

    • Consentire build locali consente a un utente malintenzionato con intento dannoso di modificare il processo di compilazione.
    • Le incoerenze negli ambienti locali degli sviluppatori e nelle loro pratiche rendono difficile riprodurre le build e diagnosticare i relativi problemi.

    Nei requisiti del framework SLSA, le build automatizzate sono un requisito per il livello 1 di SLSA e l'utilizzo di un servizio di compilazione anziché ambienti di sviluppo per le build è un requisito per il livello 2 di SLSA.

  • Origine della build

    La provenienza della build è una raccolta di dati verificabili relativi a una build.

    I metadati di provenienza includono dettagli come i digest delle immagini create, le località di origine di input, la toolchain di build e la durata della build.

    La generazione della provenienza della build ti aiuta a:

    • Verifica che un artefatto creato sia stato creato da una posizione di origine attendibile e da un sistema di compilazione attendibile.
    • Identifica il codice inserito da una posizione di origine o da sistema di compilazione non attendibili.

    Puoi utilizzare meccanismi di avviso e criteri per utilizzare in modo proattivo i dati sulla provenienza della build. Ad esempio, puoi creare criteri che consentono solo il deployment di codice creato a partire da origini verificate.

    Cloud Build può generare la provenienza delle build per le immagini container che offrono la garanzia di livello 3 di SLSA. Per maggiori informazioni, consulta Visualizzare la provenienza delle build.

  • Ambiente di build temporaneo

    Gli ambienti temporanei sono ambienti temporanei pensati per durare una singola chiamata a una build. Dopo la build, l'ambiente viene cancellato o eliminato. Le build temporanee assicurano che il servizio e i passi di build vengano eseguiti in un ambiente temporaneo, ad esempio un container o una VM. Anziché riutilizzare un ambiente di build esistente, il servizio di build esegue il provisioning di un nuovo ambiente per ogni build, quindi lo elimina al termine del processo di compilazione.

    Gli ambienti temporanei assicurano build pulite poiché non ci sono file residui o impostazioni di ambiente di build precedenti che possono interferire con il processo di build. Un ambiente non temporaneo offre ai malintenzionati l'opportunità di inserire file e contenuti dannosi. Un ambiente temporaneo riduce anche l'overhead di manutenzione e le incoerenze nell'ambiente di build.

    Cloud Build configura un nuovo ambiente di macchina virtuale per ogni build e lo elimina dopo la build.

  • Criteri di deployment

    Puoi integrare Cloud Build con Autorizzazione binaria per verificare la presenza di attestazioni di build e bloccare i deployment di immagini non generate da Cloud Build. Questo processo può ridurre il rischio di deployment di software non autorizzati.

  • Chiavi di crittografia gestite dal cliente

    Cloud Build fornisce la conformità con chiavi di crittografia gestite dal cliente (CMEK) per impostazione predefinita. Gli utenti non devono configurare nulla in modo specifico. Cloud Build fornisce la conformità CMEK criptando il disco permanente (DP) in fase di compilazione con una chiave temporanea generata per ogni build. La chiave viene generata in modo univoco per ogni build.

    Al termine della build, la chiave viene cancellata dalla memoria ed eliminata. Non è archiviato da nessuna parte, non è accessibile ai tecnici o al personale di assistenza Google e non può essere ripristinato. I dati protetti con una chiave di questo tipo sono definitivamente inaccessibili. Per saperne di più, consulta Conformità di CMEK in Cloud Build.

  • Riquadro Insight sulla sicurezza

    Cloud Build include un riquadro Approfondimenti sulla sicurezza nella console Google Cloud che mostra una panoramica generale di diverse metriche di sicurezza. Puoi utilizzare questo riquadro per identificare e mitigare i rischi nel processo di compilazione.

    Questo riquadro mostra le seguenti informazioni:

    • Livello della catena di fornitura per gli artefatti software (SLSA): identifica il livello di maturità del processo di compilazione del software in conformità con la specifica SLSA.

    • Vulnerabilità: una panoramica delle vulnerabilità trovate negli artefatti e il nome dell'immagine analizzata da Artifact Analysis. Puoi fare clic sul nome dell'immagine per visualizzare i dettagli della vulnerabilità. Ad esempio, nello screenshot puoi fare clic su java-guestbook-backend.

    • Dettagli build: dettagli della build, come il builder e il link per visualizzare i log.

    • Provenienza della build: prove della build.

  • Software Delivery Shield (scudo per la consegna del software)

    Cloud Build fa parte della soluzione Software Delivery Shield. Software Delivery Shield è una soluzione di sicurezza per la catena di fornitura del software end-to-end completamente gestita che consente di migliorare la strategia di sicurezza di strumenti e flussi di lavoro degli sviluppatori, dipendenze software, sistemi CI/CD utilizzati per creare ed eseguire il deployment del software e ambienti di runtime come Google Kubernetes Engine e Cloud Run. Per scoprire come utilizzare Cloud Build con altri componenti di Software Delivery Shield per migliorare la strategia di sicurezza della catena di fornitura del software, consulta Panoramica di Software Delivery Shield.

Passaggi successivi