Esegui gli hook prima e dopo il deployment

Questo documento descrive come eseguire programmi o operazioni arbitrari prima o dopo il deployment.

Puoi configurare Cloud Deploy per eseguire azioni di pre-deployment e/o post-deployment. Questi programmi, eseguiti in questo modo, sono chiamati "hook". Gli hook pre-deployment e post-deployment vengono eseguiti come job pre-deployment e post-deployment durante l'implementazione.

Puoi configurare ogni hook per l'esecuzione in un ambiente di esecuzione Cloud Deploy specificato, ma se esegui il deployment in Google Kubernetes Engine, puoi facoltativamente configurarlo per l'esecuzione nel cluster GKE in cui esegui il deployment dell'applicazione.

Si presume che gli hook di deployment siano idempotenti. Se una determinata azione viene eseguita più di una volta, non si verifica alcun effetto aggiuntivo.

Come funzionano gli hook di deployment?

Di seguito viene descritto come vengono eseguiti gli hook di deployment in Cloud Deploy e come configurarli:

  1. Configuri gli hook in una o più fasi della progressione della pipeline di distribuzione.

  2. Prima dell'esecuzione del job di deployment del rollout, Cloud Deploy esegue tutte le attività configurate in una definizione predeploy nella progressione della pipeline.

    L'hook predeploy viene sempre eseguito come primo job nella fase.

  3. Dopo l'esecuzione del job di deployment del rollout, Cloud Deploy esegue tutte le attività configurate in una definizione postdeploy nella progressione della pipeline.

Gli hook di deployment vengono eseguiti nell'ambiente di esecuzione di Cloud Deploy.

Utilizzo degli hook di deployment con un deployment canary

Quando configuri gli hook di deployment per un deployment canary, ci sono diverse cose da sapere:

  • Nella fase della pipeline di distribuzione, la configurazione dell'hook (predeploy e postdeploy) si trova in strategy.canary.canaryDeployment o strategy.canary.customCanaryDeployment.phaseConfigs, anziché in strategy.standard.

  • Per un canary automatizzato, gli hook predeploy vengono eseguiti prima del deployment solo nella prima fase, mentre gli hook postdeploy vengono eseguiti dopo il deployment solo nell'ultima fase (stabile).

Configura la pipeline per eseguire gli hook

Configuri gli hook pre- e post-deployment in una o più fasi specifiche della progressione della pipeline.

Di seguito viene illustrato come configurare gli hook pre-deployment e post-deployment in una fase della pipeline quando si utilizza una strategia di deployment standard:

serialPipeline:
  stages:
  - targetId: hooks-staging
    profiles: []
    strategy:
      standard:
        predeploy:
          tasks: [TASKS]
        postdeploy:
          tasks: [TASKS]

In questo file YAML:

  • TASKS

    È un elenco di una o più attività che vuoi eseguire nell'ambito degli hook predeploy o postdeploy. Quando specifichi più di un'attività, queste vengono eseguite in sequenza, nell'ordine in cui sono specificate. Il job (pre-deployment o post-deployment) non riesce alla prima attività che non va a buon fine e le attività rimanenti non vengono eseguite.

Esegui gli hook sul cluster di applicazioni

Per impostazione predefinita, gli hook di deployment vengono eseguiti nell'ambiente di esecuzione di Cloud Deploy. Puoi anche configurare Skaffold per eseguire hook di deployment sullo stesso cluster in cui viene eseguita l'applicazione.

Per eseguire gli hook sul cluster di applicazioni, devi configurarli come customActions nel tuo skaffold.yaml e farvi riferimento utilizzando actions nella stanza predeploy o postdeploy nella configurazione della fase della pipeline di distribuzione:

serialPipeline:
  stages:
  - targetId: hooks-staging
    profiles: []
    strategy:
      standard:
        predeploy:
          actions: ["my-predeploy-action"]
        postdeploy:
          actions: ["my-postdeploy-action"]

Questa funzionalità è disponibile solo per i deployment su GKE, non per Cloud Run. I deployment su Cloud Run possono eseguire hook solo nell'ambiente di esecuzione di Cloud Deploy.

Per configurare l'hook in modo che venga eseguito sul cluster, includi una sezione executionMode.kubernetesCluster nel file di configurazione skaffold.yaml, all'interno della sezione customActions per ogni azione che vuoi eseguire sul cluster:

customActions:
- name: ACTION_NAME
  containers:
  - name: CONTAINER_NAME
    image: IMAGE
    command: [COMMANDS_TO_RUN]
    args: [LIST_OF_ARGS]
  executionMode:
    kubernetesCluster: {}

Di seguito è riportato un esempio di sezione customActions che include executionMode per richiamare il container hook sul cluster dell'applicazione:

customActions:
- name: predeploy-action
  containers:
  - name: predeploy-echo
    image: ubuntu
    command: ["/bin/sh"]
    args: ["-c", 'echo "this is a predeploy action"' ]
  executionMode:
    kubernetesCluster: {}

La sezione executionMode è facoltativa e, se la ometti, Skaffold esegue il container di azioni personalizzate nell'ambiente di esecuzione di Cloud Deploy.

Variabili di ambiente disponibili

Cloud Deploy fornisce e popola anche le seguenti variabili di ambiente nell'ambiente di esecuzione. Puoi utilizzare queste variabili di ambiente come parte del deploy hook, del verify job, o del rendering o del deployment del target personalizzato.

  • ANTHOS_MEMBERSHIP

    Per i target di tipo ANTHOS, il nome della risorsa completamente specificato dell'appartenenza Anthos.

  • CLOUD_RUN_LOCATION

    Per i target di tipo RUN, la regione in cui è stato eseguito il deployment del servizio Cloud Run.

  • CLOUD_RUN_PROJECT

    Per le destinazioni di tipo RUN, il progetto in cui è stato creato il servizio Cloud Run.

  • CLOUD_RUN_SERVICE

    Per le destinazioni di tipo RUN, il nome del servizio Cloud Run di cui è stato eseguito il deployment.

  • CLOUD_RUN_SERVICE_URLS

    Per i target di tipo RUN, l'URL o gli URL (elenco separato da virgole) che gli utenti finali utilizzeranno per accedere al tuo servizio. Puoi trovarli nei dettagli del servizio Cloud Run per il tuo servizio, nella consoleGoogle Cloud . Gli URL vengono generati da Cloud Run dopo il deployment riuscito del servizio o dei servizi Cloud Run. Pertanto, questa variabile di ambiente è disponibile solo negli hook post-deployment e nei job di verifica.

  • CLOUD_RUN_REVISION

    Per i target di tipo RUN, la revisione specifica del servizio Cloud Run.

  • GKE_CLUSTER

    Per le destinazioni di tipo GKE, il nome della risorsa completamente specificato del cluster Google Kubernetes Engine, ad esempio projects/p/locations/us-central1/clusters/dev.

  • TARGET_TYPE

    Il tipo di runtime specifico della destinazione. GKE, ANTHOS o RUN. Per i target personalizzati, questo valore non verrà impostato.

  • CLOUD_DEPLOY_LOCATION

    La regione contenente le risorse Cloud Deploy.

  • CLOUD_DEPLOY_DELIVERY_PIPELINE

    L'ID della pipeline di distribuzione.

  • CLOUD_DEPLOY_TARGET

    L'ID del target.

  • CLOUD_DEPLOY_PROJECT

    Il numero di progetto Google Cloud per il progetto contenente le risorse Cloud Deploy.

  • CLOUD_DEPLOY_PROJECT_ID

    L'ID progetto Google Cloud del progetto.

  • CLOUD_DEPLOY_RELEASE

    L'ID della release in cui verranno eseguiti gli hook.

  • CLOUD_DEPLOY_ROLLOUT

    L'ID del rollout che contiene i job per gli hook.

  • CLOUD_DEPLOY_JOB_RUN

    L'ID dell'esecuzione del job che rappresenta l'esecuzione corrente del job.

  • CLOUD_DEPLOY_PHASE

    La fase del lancio che contiene il job per l'hook di deployment, il job di verifica o il rendering o il deployment personalizzato.

Esegui il deployment dei parametri come variabili di ambiente

Oltre alle variabili di ambiente elencate in questa sezione, Cloud Deploy può passare ai tuoi container personalizzati qualsiasi parametro di deployment che hai impostato.

Scopri di più.

Passaggi successivi