Panoramica di Cloud Build

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

Cloud Build può importare codice sorgente da vari repository o spazi di spazio di archiviazione sul cloud, eseguire una build secondo le tue specifiche e come container Docker o archivi Java.

Puoi anche utilizzare Cloud Build per proteggere la tua catena di approvvigionamento del software. Le funzionalità di Cloud Build soddisfano i requisiti del livello 3 della catena di fornitura per artefatti software (SLSA). Per indicazioni su come proteggere le procedure di compilazione, consulta Proteggere le build.

Configurazione e passaggi di compilazione

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 build come Docker, Gradle, Maven, Bazel e gulp.

Cloud Build esegue la build come una serie di passaggi, dove ogni viene eseguito in un container Docker. L'esecuzione dei passaggi di build è analoga a: dei comandi in uno script.

Puoi usare i passaggi di build forniti da Cloud Build e dalla sua community o scrivere passaggi di build personalizzati:

Ogni passaggio di build viene eseguito con il relativo container collegato a una rete Docker locale denominato cloudbuild. In questo modo i passaggi della build possono comunicare tra loro condividere i dati. Per ulteriori informazioni sulla rete cloudbuild, consulta la pagina 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 i trigger di build di Cloud Build per creare un flusso di lavoro di integrazione/distribuzione continua (CI/CD) automatico che avvia nuove build in risposta alle modifiche del codice.

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

Visualizzazione dei risultati della build

Puoi visualizzare i risultati della build utilizzando l'interfaccia a riga di comando gcloud, l'API Cloud Build o la pagina Cronologia di Build nella sezione Cloud Build della console Google Cloud, che mostra i dettagli e i log di ogni build eseguita da Cloud Build. Per le istruzioni, vedi Visualizzare i risultati della compilazione.

Come funzionano le build

I passaggi che seguono descrivono, in generale, il ciclo di vita di una compilazione Cloud Build:

  1. Prepara il codice dell'applicazione e tutti gli asset necessari.
  2. Crea un file di configurazione di compilazione in formato YAML o JSON, che contenga le 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, gli elementi costruiti vengono inviati ad Artifact Registry.

Docker

Cloud Build utilizza Docker per eseguire le build. Per ogni passaggio di compilazione, Cloud Build esegue un container Docker come istanza di docker run. Al momento, Cloud Build esegue il motore Docker 20.10.24.

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 della build di Cloud Build nella Cronologia build e automatizzare le build Trigger di build.

Puoi utilizzare gcloud CLI per creare e gestire . Puoi eseguire comandi per svolgere attività come inviare una build, elencare le build e annullare un per la creazione di modelli.

Puoi richiedere le build utilizzando il REST Cloud Build tramite Google Cloud.

Come per le altre API della piattaforma Cloud, devi autorizzare l'accesso utilizzando OAuth2. Dopo aver autorizzato l'accesso, puoi utilizzare l'API per avviare nuove build, visualizzare lo stato e i dettagli delle build, elencare le build per progetto e annullare le build in corso.

Per ulteriori informazioni, consulta documentazione dell'API.

Pool predefiniti e pool privati

Per impostazione predefinita, quando esegui una build su Cloud Build, questa viene eseguita un ambiente sicuro e ospitato con accesso alla rete internet pubblica. Ogni build viene eseguita ha il proprio worker e viene isolato da altri carichi di lavoro. Puoi personalizzare la compilazione in diversi modi, ad esempio aumentando le dimensioni del tipo di macchina o allocando più spazio su disco. Il pool predefinito ha limiti per quanto riguarda la personalizzazione dell'ambiente, in particolare per l'accesso alla rete privata.

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

Scopri di più sui pool privati e sulla differenza di funzionalità tra i pool predefiniti e pool, vedi Panoramica del pool privato.

Sicurezza di Build

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

  • Build automatizzate

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

    Le build automatiche garantiscono la coerenza dei passaggi di compilazione. Tuttavia, è importante anche eseguire le build in un ambiente coerente e attendibile.

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

    • La possibilità di eseguire build locali offre a un utente malintenzionato un modo per modificare il processo di compilazione.
    • Le incoerenze negli ambienti locali degli sviluppatori e nelle loro pratiche rendono è difficile riprodurre le build e diagnosticare i problemi.

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

  • Provenienza build

    La provenienza della build è una raccolta di dati verificabili su una build.

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

    Generare la provenienza della build ti aiuta a:

    • Verifica che un elemento compilato sia stato creato dalla posizione della sorgente attendibile e da un sistema di compilazione attendibile.
    • Identificare il codice iniettato da una posizione di origine o da un sistema di compilazione non attendibile.

    Puoi utilizzare i meccanismi di avviso e dei criteri per utilizzare in modo proattivo i dati sulla provenienza della compilazione. Ad esempio, puoi creare criteri che consentono solo il deployment di codice creati da fonti verificate.

    Cloud Build può generare la provenienza della build per le immagini container che forniscono una garanzia SLSA di livello 3. Per ulteriori informazioni, vedi Visualizzazione della provenienza della build.

  • Ambiente di compilazione temporaneo

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

    Gli ambienti effimeri garantiscono build pulite perché non sono presenti file residuali o impostazioni di ambiente delle build precedenti che possono interferire con il processo di compilazione. Un ambiente non temporaneo offre agli utenti malintenzionati l'opportunità di inserire file e contenuti dannosi. Un ambiente effimero riduce inoltre i costi generali di manutenzione e le incoerenze nell'ambiente di compilazione.

    Cloud Build configura una nuova macchina virtuale per ogni build e lo distrugge dopo la build.

  • Criteri di deployment

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

  • Chiavi di crittografia gestite dal cliente

    Cloud Build garantisce la conformità alle chiavi di crittografia gestite dal cliente (CMEK) per impostazione predefinita. Gli utenti non devono configurare nulla in modo specifico. Cloud Build garantisce la conformità alle CMEK criptando il disco permanente (PD) al momento della compilazione con una chiave effimera generata per ogni compilazione. La chiave è in modo univoco generate per ogni build.

    Appena la build viene completata, la chiave viene cancellata dalla memoria ed eliminata. Non viene memorizzato da nessuna parte, non è accessibile agli ingegneri o al personale di assistenza di Google e non può essere ripristinato. I dati protetti con una chiave di questo tipo rimangono definitivamente inaccessibili. Per ulteriori informazioni, consulta la sezione Conformità CMEK in Cloud Build.

  • Riquadro degli approfondimenti sulla sicurezza

    Cloud Build include un riquadro Approfondimenti sulla sicurezza nella Console Google Cloud che mostra una panoramica generale di più metriche di sicurezza. Puoi utilizzare questo riquadro per identificare e mitigare i rischi in il processo di compilazione.

    Questo riquadro mostra le seguenti informazioni:

    • Supply-chain Levels for Software Artifacts (SLSA) Level: identifica il livello livello di maturità del tuo processo di compilazione del software in base specifica SLSA).

    • Vulnerabilità: una panoramica delle eventuali vulnerabilità rilevate negli elementi 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: i dettagli della build, ad esempio il builder e il link a e visualizzare i log.

    • Provenienza della build: la provenienza della build.

  • Software Delivery Shield

    Cloud Build fa parte della soluzione Software Delivery Shield. Software Delivery Shield è una soluzione di sicurezza della catena di fornitura del software end-to-end completamente gestita che ti aiuta a migliorare la posizione di sicurezza dei flussi di lavoro e degli strumenti per gli sviluppatori, delle dipendenze del software, dei sistemi CI/CD utilizzati per creare e implementare il software e degli ambienti di runtime come Google Kubernetes Engine e Cloud Run. Per scoprire come puoi utilizzare Cloud Build con altri componenti di Software Delivery Shield per migliorare la postura di sicurezza della tua catena di fornitura del software, consulta Panoramica di Software Delivery Shield.

Passaggi successivi