Automatizzare le build in risposta agli eventi Pub/Sub

I trigger Pub/Sub di Cloud Build ti consentono eseguire build in risposta agli eventi Google Cloud pubblicati in Pub/Sub. Puoi utilizzare le informazioni di un Pub/Sub per parametrizzare la build e per decidere se una build vengono eseguite in risposta all'evento. I trigger Pub/Sub possono essere configurati di un argomento Pub/Sub.

In questa pagina viene spiegato come creare un trigger Pub/Sub per automatizzare le build in risposta agli eventi su Artifact Registry Container Registry (deprecato) e di archiviazione ideale in Cloud Storage.

Limitazioni

I trigger Pub/Sub di Cloud Build non sono supportati se Si utilizza Controlli di servizio VPC.

Prima di iniziare

  • Attiva l'API Cloud Build.

    Abilita l'API

  • Assicurati che il codice sorgente contenga un file di configurazione della build o un Dockerfile nel repository.

  • Per utilizzare i comandi gcloud in questa pagina, installa Google Cloud CLI.

Creazione di un trigger di build che risponde agli eventi Artifact Registry

Puoi creare un trigger Pub/Sub che risponda Eventi Artifact Registry, ad esempio l'esecuzione del push delle immagini, dei tag eliminati. Questa sezione illustra come creare un trigger Pub/Sub che richiama una build quando viene eseguito il push di un nuovo tag a un'immagine esistente. Se non hai dimestichezza con Artifact Registry, consulta Panoramica di Artifact Registry.

Console

Per creare un attivatore che ascolti un nuovo tag inviato a un un'immagine esistente in Artifact Registry utilizzando la console Google Cloud:

  1. Apri la pagina Attivatori:

    Apri la pagina Attivatori

  2. Seleziona il tuo progetto nella parte superiore della pagina e fai clic su Apri.

  3. Fai clic su Crea trigger.

  4. Inserisci le seguenti impostazioni di trigger:

    • Nome: inserisci un nome per l'attivatore.

    • Regione: seleziona la regione per il tuo trigger.

      • Se il file di configurazione di compilazione associato al trigger specifica un pool privato, Cloud Build lo utilizza per eseguire la build. In questo caso, la regione specificata nel trigger deve corrispondere alla regione in cui hai creato il pool privato.
      • Se il file di configurazione di compilazione associato al trigger non specifica un pool privato, Cloud Build utilizza il valore predefinito pool per eseguire la build nella stessa regione come trigger.

    • (Facoltativo) Descrizione: inserisci una descrizione per l'attivatore.

    • Evento: seleziona Messaggio Pub/Sub come evento per per richiamare il trigger.

    • Subscription: seleziona l'argomento Pub/Sub che preferisci a cui iscriversi come evento di trigger. Vedrai tutti gli argomenti esistenti nel progetto nel menu a discesa.

    • Origine: seleziona l'origine da creare quando il trigger di Pub/Sub viene eseguito. Puoi specificare 1a generazione o 2a generazione come origine.

      • Repository: dall'elenco di repository disponibili, seleziona la repository desiderato.

      • Ramo o Tag: specifica un'espressione regolare con il ramo o valore del tag da far corrispondere. Per informazioni sulla sintassi accettabile delle espressioni regolari, consulta la sintassi RE2.

      • Controllo dei commenti: se hai selezionato Richiesta pull (solo app GitHub) Evento, scegli una delle seguenti opzioni per controlla se una build verrà eseguita automaticamente dal trigger:

        • Obbligatorio, tranne che per proprietari e collaboratori: quando viene eseguito un pull una richiesta viene creata o aggiornata da un proprietario o un collaboratore del repository, le build verranno eseguite automaticamente dal trigger. Se un server inizia l'azione, le build verranno eseguite solo dopo un proprietario o un collaboratore commenta /gcbrun sulla richiesta di pull.

        • Obbligatorio: quando una richiesta di pull viene creata o aggiornata da un collaboratore, le build verranno eseguite solo dopo che un proprietario il collaboratore commenta /gcbrun sulla richiesta di pull. Build vengono eseguiti ogni volta che viene apportata una modifica a una richiesta di pull.

        • Non obbligatorio: quando una richiesta di pull viene creata o aggiornata da un , le build verranno eseguite automaticamente dai trigger.

    • Configurazione: seleziona il file di configurazione della build (che si trova in repository remoto) o creare un file di configurazione di compilazione incorporato per la tua build.

      • Tipo: seleziona il tipo di configurazione da utilizzare per la build.
        • File di configurazione di Cloud Build (yaml o json): Utilizza un file di configurazione di compilazione per la configurazione.
        • Dockerfile: utilizza un Dockerfile per la configurazione.
        • Buildpacks: utilizza buildpacks per la tua configurazione.

      • Posizione: specifica la posizione per la configurazione.

        • Repository: se il file di configurazione si trova nella cartella repository remoto, fornisci la posizione file di configurazione della build, Dockerfile o la directory buildpacks. Se la configurazione della build è un Dockerfile o un buildpack, dovrai fornire un nome per l'immagine risultante e, facoltativamente, un timeout per creare. Dopo che hai fornito Dockerfile o buildpack nome dell'immagine, vedrai un'anteprima della docker build o pack che verrà eseguito dalla build.
        • (Facoltativo) Variabili di ambiente Buildpack: se buildpacks come tipo di configurazione, fai clic Aggiungi la variabile di ambiente del pacchetto per specificare il tuo buildpack variabili e valori di ambiente. Per scoprire di più su Variabili di ambiente buildpack, consulta Variabili di ambiente.

        • In linea: se hai selezionato File di configurazione di Cloud Build (yaml o json) come l'opzione di configurazione, puoi specificare la configurazione della build in linea. Fai clic su Apri editor per scrivere il file di configurazione della build nell' Console Google Cloud con la sintassi YAML o JSON. Fai clic su Fine per e salvare la configurazione della build.

    • (Facoltativo) Sostituzioni: se hai selezionato il file di configurazione della build come di configurazione della build, puoi scegliere di definire specifiche variabili di sostituzione utilizzando questo campo.

      Nel seguente esempio, vogliamo ottenere il nome del tag immagine dalla payload e l'azione associata all'evento gcr. Per farlo, per creare variabili di sostituzione associazioni di payload.

      Specifica le variabili e i valori seguenti:

      Nome variabile Valore variabile
      _IMAGE_TAG $(body.message.data.tag)
      _ACTION $(body.message.data.action)

      body.message fa riferimento a PubSubMessage pubblicate dagli editori e consumate dagli abbonati. Per altri esempi di payload di notifica Pub/Sub, consulta gli esempi di notifiche.

    • (Facoltativo) Filtri: puoi creare filtri all'interno di un attivatore che determinano se il trigger eseguirà o meno una build in risposta al in entrata specificando filtri sulle variabili di sostituzione. L'espressione di filtro deve restituire true per poter build per l'esecuzione.

      Ti consigliamo di utilizzare i filtri durante la configurazione dei trigger di Pub/Sub. su argomenti con diversi messaggi. I filtri possono essere usati per controllare con precisione che vengono eseguite in risposta ai messaggi Pub/Sub in arrivo. A scopri di più sui rischi associati alla configurazione di un trigger senza filtri consulta Rischi associati a un attivatore non filtrato.

      Nell'esempio seguente, vogliamo che il trigger esegua una build se nuovo tag viene inviato a un'immagine esistente. Utilizziamo la condizione di filtro per verificare se la variabile _IMAGE_TAG corrisponde a una variabile e se la variabile _ACTION corrisponde a INSERT da cercare appena aggiunti.

      Specifica quanto segue come filtri:

      • _IMAGE_TAG != ""
      • _ACTION == INSERT

      L'utilizzo dei trigger di Pub/Sub per filtrare la sintassi CEL (Common Expression Language) per la valutazione delle espressioni. Per scoprire di più su CEL, consulta il repository cel-spec.

  1. Fai clic su Crea per creare il trigger di build.

gcloud

Per creare un attivatore che ascolti un nuovo tag inviato a un un'immagine esistente in Artifact Registry utilizzando i comandi gcloud:

  1. Apri una finestra del terminale.

  2. Esegui il comando gcloud per creare un trigger di build nel progetto. Nell'esempio seguente, il trigger è configurato per rispondere alle build con un tag corrispondente a prod e un'azione corrispondente a INSERT in base a il payload specificato, come definito dalla variabile di sostituzione _IMAGE_TAG.

     gcloud builds triggers create pubsub \
   --region=REGION \
   --name=TRIGGER_NAME \
   --repository=projects/PROJECT_ID/locations/REGION/connections/CONNECTION_NAME/repositories/REPO_NAME \
   --topic=projects/PROJECT_ID/topics/TOPIC_NAME \
   --build-config=BUILD_CONFIG \ # or --inline-config=INLINE_BUILD_CONFIG
   --substitutions=\
     '_IMAGE_TAG_="$(body.message.data.tag)",' \
     '_ACTION="$(body.message.data.action)"' \
   --subscription-filter='_IMAGE_TAG == "" && _ACTION == "INSERT"' \
   --tag=TAG_NAME  # or --branch=BRANCH_NAME

Dove:

  • REGION è la regione per il tuo trigger.
  • TRIGGER_NAME è il nome del tuo trigger.
  • PROJECT_ID è l'ID del tuo progetto cloud.
  • CONNECTION_NAME è il nome della connessione host.
  • REPO_NAME è il nome del tuo repository.
  • TOPIC_NAME è il nome dell'argomento Pub/Sub a cui hai effettuato la sottoscrizione.
  • BUILD_CONFIG è il percorso del file di configurazione della build.
  • INLINE_BUILD_CONFIG è il percorso del tuo file di configurazione della build incorporato.
  • TAG_NAME è il nome del tag se vuoi impostare l'attivatore in modo che si basi su un tag.
  • BRANCH_NAME è il nome del ramo se vuoi impostare il trigger per creare su un ramo.

Creazione di un trigger di build che risponde agli eventi di Container Registry

Puoi creare un trigger Pub/Sub che risponda Eventi di Container Registry, ad esempio l'esecuzione del push delle immagini, dei tag eliminati. Questa sezione illustra come creare un trigger Pub/Sub che richiama una build quando un'immagine corrisponde a un tag impostato da un filtro personalizzato. Se non hai dimestichezza con Container Registry, consulta Guida rapida per Container Registry per imparare a eseguire il push e il pull delle immagini con i tag.

Console

Creare un trigger che ascolti il push di un'immagine in Container Registry. e trova corrispondenze in base al nome di un tag utilizzando la console Google Cloud:

  1. Apri la pagina Attivatori:

    Apri la pagina Attivatori

  2. Seleziona il tuo progetto nella parte superiore della pagina e fai clic su Apri.

  3. Fai clic su Crea trigger.

  4. Inserisci le seguenti impostazioni di trigger:

    • Nome: inserisci un nome per l'attivatore.

    • Regione: seleziona la regione per il tuo trigger.

      • Se il file di configurazione di compilazione associato al trigger specifica un pool privato, Cloud Build lo utilizza per eseguire la build. In questo caso, la regione specificata nel trigger deve corrispondere alla regione in cui hai creato il pool privato.
      • Se il file di configurazione di compilazione associato al trigger non specifica un pool privato, Cloud Build utilizza il valore predefinito pool per eseguire la build nella stessa regione come trigger.

    • (Facoltativo) Descrizione: inserisci una descrizione per l'attivatore.

    • Evento: seleziona Messaggio Pub/Sub come evento per per richiamare il trigger.

    • Subscription: seleziona l'argomento Pub/Sub che preferisci a cui iscriversi come evento di trigger. Vedrai tutti gli argomenti esistenti nel progetto nel menu a discesa.

    • Origine: seleziona l'origine da creare quando il trigger di Pub/Sub viene eseguito. Puoi specificare 1a generazione o 2a generazione come origine.

      • Repository: dall'elenco di repository disponibili, seleziona la repository desiderato.

      • Ramo o Tag: specifica un'espressione regolare con il ramo o valore del tag da far corrispondere. Per informazioni sulla sintassi accettabile delle espressioni regolari, consulta la sintassi RE2.

      • Controllo dei commenti: se hai selezionato Richiesta pull (solo app GitHub) Evento, scegli una delle seguenti opzioni per controlla se una build verrà eseguita automaticamente dal trigger:

        • Obbligatorio, tranne che per proprietari e collaboratori: quando viene eseguito un pull una richiesta viene creata o aggiornata da un proprietario o un collaboratore del repository, le build verranno eseguite automaticamente dal trigger. Se un server inizia l'azione, le build verranno eseguite solo dopo un proprietario o un collaboratore commenta /gcbrun sulla richiesta di pull.

        • Obbligatorio: quando una richiesta di pull viene creata o aggiornata da un collaboratore, le build verranno eseguite solo dopo che un proprietario il collaboratore commenta /gcbrun sulla richiesta di pull. Build vengono eseguiti ogni volta che viene apportata una modifica a una richiesta di pull.

        • Non obbligatorio: quando una richiesta di pull viene creata o aggiornata da un , le build verranno eseguite automaticamente dai trigger.

    • Configurazione: seleziona il file di configurazione della build (che si trova in repository remoto) o creare un file di configurazione di compilazione incorporato per la tua build.

      • Tipo: seleziona il tipo di configurazione da utilizzare per la build.
        • File di configurazione di Cloud Build (yaml o json): Utilizza un file di configurazione di compilazione per la configurazione.
        • Dockerfile: utilizza un Dockerfile per la configurazione.
        • Buildpacks: utilizza buildpacks per la tua configurazione.

      • Posizione: specifica la posizione per la configurazione.

        • Repository: se il file di configurazione si trova nella cartella repository remoto, fornisci la posizione file di configurazione della build, Dockerfile o la directory buildpacks. Se la configurazione della build è un Dockerfile o un buildpack, dovrai fornire un nome per l'immagine risultante e, facoltativamente, un timeout per creare. Dopo che hai fornito Dockerfile o buildpack nome dell'immagine, vedrai un'anteprima della docker build o pack che verrà eseguito dalla build.
        • (Facoltativo) Variabili di ambiente Buildpack: se buildpacks come tipo di configurazione, fai clic Aggiungi la variabile di ambiente del pacchetto per specificare il tuo buildpack variabili e valori di ambiente. Per scoprire di più su Variabili di ambiente buildpack, consulta Variabili di ambiente.

        • In linea: se hai selezionato File di configurazione di Cloud Build (yaml o json) come l'opzione di configurazione, puoi specificare la configurazione della build in linea. Fai clic su Apri editor per scrivere il file di configurazione della build nell' Console Google Cloud con la sintassi YAML o JSON. Fai clic su Fine per e salvare la configurazione della build.

    • (Facoltativo) Sostituzioni: se hai selezionato il file di configurazione della build come di configurazione della build, puoi scegliere di definire specifiche variabili di sostituzione utilizzando questo campo.

      Nel seguente esempio, vogliamo ottenere il nome del tag immagine dalla payload e l'azione associata all'evento gcr. Per farlo, per creare variabili di sostituzione associazioni di payload.

      Specifica le variabili e i valori seguenti:

      Nome variabile Valore variabile
      _IMAGE_TAG $(body.message.data.tag)
      _ACTION $(body.message.data.action)

      body.message fa riferimento a PubSubMessage pubblicate dagli editori e consumate dagli abbonati. Per vedere altri esempi di payload di notifica Pub/Sub, consulta gli esempi di notifiche.

    • (Facoltativo) Filtri: puoi creare filtri all'interno di un attivatore che determinano se il trigger eseguirà o meno una build in risposta al in entrata specificando filtri sulle variabili di sostituzione. L'espressione di filtro deve restituire true per poter build per l'esecuzione.

      Ti consigliamo di utilizzare i filtri durante la configurazione dei trigger di Pub/Sub. su argomenti con diversi messaggi. I filtri possono essere usati per controllare con precisione che vengono eseguite in risposta ai messaggi Pub/Sub in arrivo. A scopri di più sui rischi associati alla configurazione di un trigger senza filtri consulta Rischi associati a un attivatore non filtrato.

      Nell'esempio seguente, vogliamo che il trigger esegua una build se il nome la variabile tag _IMAGE_TAG corrisponde a un nome tag specifico, ad esempio prod. Puoi specificare l'operatore delle condizioni di filtro come "==" per la corrispondenza esatta. Puoi anche controllare l'azione associata al tuo evento gcr. Ad esempio, potresti voler specificare che _ACTION è INSERT da cercare appena aggiunti.

      Specifica quanto segue come filtri:

      • _IMAGE_TAG.matches(prod)
      • _ACTION.matches(INSERT)

      L'utilizzo dei trigger di Pub/Sub per filtrare la sintassi CEL (Common Expression Language) per la valutazione delle espressioni. Per scoprire di più su CEL, consulta il repository cel-spec. Per visualizzare altri esempi di sintassi dei filtri, puoi applicare Trigger di Pub/Sub. Consulta Filtrare le build.

  1. Fai clic su Crea per creare il trigger di build.

gcloud

Creazione di un trigger di build che risponde agli eventi di Cloud Storage

Puoi creare un trigger Pub/Sub che risponda a Cloud Storage come quando viene eseguito il push di un nuovo file binario a un bucket di archiviazione esistente. Questa sezione illustra come creare un trigger Pub/Sub che risponde con una build durante il deployment di un nuovo programma binario in un bucket caricato. Se Non hai dimestichezza con Cloud Storage, consulta le guide rapide.

Console

Per creare un trigger che ascolti eventi di Cloud Storage utilizzando la console Google Cloud:

  1. Apri la pagina Attivatori:

    Apri la pagina Attivatori

  2. Seleziona il tuo progetto nella parte superiore della pagina e fai clic su Apri.

  3. Fai clic su Crea trigger.

  4. Inserisci le seguenti impostazioni di trigger:

    • Nome: inserisci un nome per l'attivatore.

    • Regione: seleziona la regione per il tuo trigger.

      • Se il file di configurazione di compilazione associato al trigger specifica un pool privato, Cloud Build lo utilizza per eseguire la build. In questo caso, la regione specificata nel trigger deve corrispondere alla regione in cui hai creato il pool privato.
      • Se il file di configurazione di compilazione associato al trigger non specifica un pool privato, Cloud Build utilizza il valore predefinito pool per eseguire la build nella stessa regione come trigger.

    • (Facoltativo) Descrizione: inserisci una descrizione per l'attivatore.

    • Evento: seleziona Messaggio Pub/Sub come evento per per richiamare il trigger.

    • Subscription: seleziona l'argomento Pub/Sub che preferisci a cui iscriversi come evento di trigger. Vedrai tutti gli argomenti esistenti nel progetto nel menu a discesa.

    • Origine: seleziona l'origine da creare quando il trigger di Pub/Sub viene eseguito. Puoi specificare 1a generazione o 2a generazione come origine.

      • Repository: dall'elenco di repository disponibili, seleziona la repository desiderato.

      • Ramo o Tag: specifica un'espressione regolare con il ramo o valore del tag da far corrispondere. Per informazioni sulla sintassi accettabile delle espressioni regolari, consulta la sintassi RE2.

      • Controllo dei commenti: se hai selezionato Richiesta pull (solo app GitHub) Evento, scegli una delle seguenti opzioni per controlla se una build verrà eseguita automaticamente dal trigger:

        • Obbligatorio, tranne che per proprietari e collaboratori: quando viene eseguito un pull una richiesta viene creata o aggiornata da un proprietario o un collaboratore del repository, le build verranno eseguite automaticamente dal trigger. Se un server inizia l'azione, le build verranno eseguite solo dopo un proprietario o un collaboratore commenta /gcbrun sulla richiesta di pull.

        • Obbligatorio: quando una richiesta di pull viene creata o aggiornata da un collaboratore, le build verranno eseguite solo dopo che un proprietario il collaboratore commenta /gcbrun sulla richiesta di pull. Build vengono eseguiti ogni volta che viene apportata una modifica a una richiesta di pull.

        • Non obbligatorio: quando una richiesta di pull viene creata o aggiornata da un , le build verranno eseguite automaticamente dai trigger.

    • Configurazione: seleziona il file di configurazione della build (che si trova in repository remoto) o creare un file di configurazione di compilazione incorporato per la tua build.

      • Tipo: seleziona il tipo di configurazione da utilizzare per la build.
        • File di configurazione di Cloud Build (yaml o json): Utilizza un file di configurazione di compilazione per la configurazione.
        • Dockerfile: utilizza un Dockerfile per la configurazione.
        • Buildpacks: utilizza buildpacks per la tua configurazione.

      • Posizione: specifica la posizione per la configurazione.

        • Repository: se il file di configurazione si trova nella cartella repository remoto, fornisci la posizione file di configurazione della build, Dockerfile o la directory buildpacks. Se la configurazione della build è un Dockerfile o un buildpack, dovrai fornire un nome per l'immagine risultante e, facoltativamente, un timeout per creare. Dopo che hai fornito Dockerfile o buildpack nome dell'immagine, vedrai un'anteprima della docker build o pack che verrà eseguito dalla build.
        • (Facoltativo) Variabili di ambiente Buildpack: se buildpacks come tipo di configurazione, fai clic Aggiungi la variabile di ambiente del pacchetto per specificare il tuo buildpack variabili e valori di ambiente. Per scoprire di più su Variabili di ambiente buildpack, consulta Variabili di ambiente.

        • In linea: se hai selezionato File di configurazione di Cloud Build (yaml o json) come l'opzione di configurazione, puoi specificare la configurazione della build in linea. Fai clic su Apri editor per scrivere il file di configurazione della build nell' Console Google Cloud con la sintassi YAML o JSON. Fai clic su Fine per e salvare la configurazione della build.

    • (Facoltativo) Sostituzioni: se hai selezionato il file di configurazione della build come di configurazione della build, puoi scegliere di definire specifiche variabili di sostituzione utilizzando questo campo.

      In questo esempio, vediamo il deployment di un nuovo file quando viene caricato in un bucket. Per ottenere questi dati, possiamo creare variabili di sostituzione utilizzando associazioni di payload.

      Specifica le variabili e i valori seguenti:

      Nome variabile Valore variabile
      _EVENT_TYPE $(body.message.attributes.eventType)
      _BUCKET_ID $(body.message.attributes.bucketId)
      _OBJECT_ID $(body.message.attributes.objectId)

      body.message fa riferimento a PubSubMessage pubblicate dagli editori e consumate dagli abbonati. Per vedere altri esempi di payload di notifica Pub/Sub, consulta gli esempi di notifiche.

    • (Facoltativo) Filtri: puoi creare filtri all'interno di un attivatore che determinano se il trigger eseguirà o meno una build in risposta al in entrata specificando filtri sulle variabili di sostituzione. L'espressione di filtro deve restituire true per poter build per l'esecuzione.

      Ti consigliamo di utilizzare i filtri durante la configurazione dei trigger di Pub/Sub. su argomenti con diversi messaggi. I filtri possono essere usati per controllare con precisione che vengono eseguite in risposta ai messaggi Pub/Sub in arrivo. A scopri di più sui rischi associati alla configurazione di un trigger senza filtri consulta Rischi associati a un attivatore non filtrato.

      Poiché vogliamo che il trigger esegua una build se il nuovo programma binario è in un bucket specifico, possiamo usare "==" operatore per verificare corrispondenze esatte. Puoi anche utilizzare i "corrispondenti" se vuoi per trovare una corrispondenza con un'espressione regolare.

      Specifica quanto segue come filtri:

      • _EVENT_TYPE == OBJECT_FINALIZE
      • _OBJECT_ID corrisponde a ^<object-id>$
      • _BUCKET_ID corrisponde a ^<bucket-id>$
  1. Fai clic su Crea per creare il trigger di build.
    2. .
.

gcloud

Rischi associati a un attivatore non filtrato

Se non hai configurato filtri nel trigger Pub/Sub, il tuo trigger potrebbe terminare per richiamare un numero infinito di build se Il trigger modifica un artefatto o un oggetto che viene pubblicato involontariamente un nuovo messaggio per l'argomento che sta ascoltando. Ad esempio, può richiamare un numero infinito di build se il trigger:

  • Punta a un argomento gcr.
  • Crea qualsiasi immagine o tag in gcr.
  • Punta a un argomento gcs per un oggetto specifico nel tuo bucket e modifica l'oggetto.

Se riscontri un ciclo infinito, puoi eliminare il trigger oppure aggiornalo in modo che punti a un argomento separato per evitare di incorrere in per ogni build che richiami.

Passaggi successivi