Esegui gli hook prima e dopo il deployment

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

Puoi configurare Cloud Deploy e Skaffold per eseguire azioni al fine di eseguire azioni pre-deployment o post-deployment oppure entrambe. Questi programmi vengono eseguiti in questo modo sono chiamati "hook". Gli hook pre-deployment e post-deployment vengono eseguiti come job pre-deployment e post-deployment nell'implementazione.

Puoi configurare ogni hook in modo che venga eseguito in un ambiente di esecuzione specifico di Cloud Deploy, ma se stai eseguendo il deployment in Google Kubernetes Engine, puoi facoltativamente configurarlo in modo che venga eseguito sul cluster GKE in cui esegui il deployment dell'applicazione.

Gli hook di deployment sono considerati idempotenti. Se una determinata azione viene eseguita più di una volta, non c'è alcun effetto aggiuntivo.

Come funzionano gli hook di deployment?

Di seguito sono descritti i passaggi per configurare gli hook di deployment e il processo di Skaffold e Cloud Deploy per l'esecuzione di questi hook:

  1. Puoi configurare il criterio skaffold.yaml utilizzato per una determinata release in modo da includere customActions che identificano l'immagine o le immagini container da utilizzare per eseguire gli hook e il comando o lo script specifico da eseguire su ciascun container.

  2. Gli hook vengono configurati in una o più fasi nell'avanzamento della pipeline di distribuzione, ognuno dei quali fa riferimento a uno degli customActions che hai configurato in skaffold.yaml.

  3. Prima dell'esecuzione del job di deployment dell'implementazione, Skaffold esegue tutti i comandi configurati in skaffold.yaml a cui viene fatto riferimento in una stanza predeploy nell'avanzamento della pipeline.

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

  4. Dopo l'esecuzione del job di deployment dell'implementazione, Cloud Deploy esegue tutti i comandi configurati in skaffold.yaml a cui viene fatto riferimento in una stanza postdeploy nell'avanzamento della pipeline.

Gli hook di deployment vengono eseguiti nell'ambiente di esecuzione predefinito di Cloud Deploy o in un ambiente di esecuzione alternativo specificato. Per i deployment su GKE e GKE Enterprise, puoi facoltativamente eseguire gli hook sullo stesso cluster in cui viene eseguito il deployment dell'applicazione.

Utilizzo degli hook di deployment con un deployment canary

Quando configuri gli hook di deployment per un deployment canary, tieni presente quanto segue:

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

  • Per una versione 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 le azioni in Skaffold

Nel tuo file skaffold.yaml, la stanza customActions prende una o più customActions stanza, configurate come segue:

customActions
- name: ACTION_NAME
  containers:
  - name: CONTAINER_NAME
    image: IMAGE
    command: [COMMANDS_TO_RUN]
    args: [LIST_OF_ARGS]

In questa stanza customerActions:

  • ACTION_NAME

    È un nome per questa azione. Puoi specificare qualsiasi nome, ma deve essere univoco all'interno di skaffold.yaml. Questo è il nome a cui verrà fatto riferimento nelle azioni pre e post-deployment definite nella fase della pipeline di distribuzione.

  • CONTAINER_NAME

    È un nome per il contenitore specifico. Puoi scegliere qualsiasi nome, ma deve essere univoco all'interno di skaffold.yaml.

  • IMAGE

    È il nome dell'immagine container in cui verrà eseguito il comando.

  • COMMANDS_TO_RUN

    È un elenco di entrypoint da eseguire in quel container. "/bin/sh" è un comando tipico da specificare qui, per richiamare una shell, e dovresti includere il comando da eseguire in quella shell negli argomenti.

  • LIST_OF_ARGS

    È un elenco di argomenti da fornire al comando. Si tratta di un elenco separato da virgole, con ogni argomento tra virgolette. Se COMMAND_TO_RUN è "/bin/sh", uno degli argomenti qui sarà "-c" e un altro argomento sarebbe l'intero comando che vuoi eseguire nella shell che stai richiamando.

    Ecco un esempio:

    command: ["/bin/sh"]
args: ["-c", `echo "This command ran!"`]

Per scoprire di più sulle azioni personalizzate di Skaffold, consulta la documentazione di Skaffold.

Configura la pipeline per fare riferimento alle azioni

Per completare la configurazione degli hook di deployment, devi configurare la pipeline di distribuzione in modo che faccia riferimento alle azioni personalizzate definite nel file skaffold.yaml. Le azioni pre e post-deployment sono configurate in una o più fasi specifiche dell'avanzamento della pipeline.

Di seguito è riportato come configurare gli hook pre e post-deployment in una fase della pipeline quando utilizzi una strategia di deployment standard:

serialPipeline:
  stages:
  - targetId: hooks-staging
    profiles: []
    strategy:
      standard:
        predeploy:
          actions: ["PREDEPLOY-ACTION"]
        postdeploy:
          actions: ["POSTDEPLOY-ACTION"]

In questo YAML:

  • PREDEPLOY_ACTION

    È uguale al ACTION_NAME che hai utilizzato in skaffold.yaml per definire l'azione personalizzata da eseguire prima del deployment.

  • POSTDEPLOY_ACTION

    È uguale al ACTION_NAME che hai utilizzato in skaffold.yaml per definire l'azione personalizzata da eseguire dopo il deployment.

Puoi specificare più di un'azione per predeploy e postdeploy, separate da virgole. Quando sono specificate più azioni, vengono eseguite in serie, nell'ordine in cui sono specificate. Il job (pre-deployment o post-deployment) non va a buon fine alla prima azione non riuscita e le azioni rimanenti non vengono eseguite.

Per impostazione predefinita, se esegui più di un container in parallelo e un job non va a buon fine, entrambi i container vengono arrestati. Puoi configurare questo comportamento utilizzando la strategia di errore delle azioni personalizzate di Skaffold.

Esegui gli hook sul cluster dell'applicazione

Per impostazione predefinita, gli hook di deployment vengono eseguiti nell'ambiente di esecuzione di Cloud Deploy. Puoi anche configurare Skaffold per eseguire queste azioni personalizzate sullo stesso cluster in cui è in esecuzione la tua applicazione. Quando configuri le azioni personalizzate in skaffold.yaml e le abiliti in una fase della pipeline, l'azione viene eseguita automaticamente nel cluster di destinazione.

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

Per eseguire l'hook sul cluster, includi unastanza executionMode.kubernetesCluster nel file di configurazione skaffold.yaml all'interno della stanza customActions per l'azione personalizzata specifica:

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

Di seguito è riportata una stanza customActions di esempio 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 stanza executionMode è facoltativa e, se la ometti, Skaffold esegue il container delle azioni personalizzate nell'ambiente di esecuzione di Cloud Deploy.

Variabili di ambiente disponibili

Cloud Deploy fornisce e compila le seguenti variabili di ambiente nell'ambiente di esecuzione, che puoi utilizzare per gli hook:

  • ANTHOS_MEMBERSHIP

    Per i target di tipo ANTHOS, il nome risorsa completo dell'abbonamento Anthos.

  • CLOUD_RUN_LOCATION

    Per i target di tipo RUN, la regione in cui è 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 trovare queste informazioni nei dettagli del servizio Cloud Run per il tuo servizio, nella console Google Cloud.

  • CLOUD_RUN_REVISION

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

  • GKE_CLUSTER

    Per i target di tipo GKE, il nome completo della risorsa 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, questa impostazione non verrà impostata.

  • 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 della destinazione.

  • CLOUD_DEPLOY_PROJECT

    Il progetto Google Cloud contenente le risorse Cloud Deploy.

  • CLOUD_DEPLOY_RELEASE

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

  • CLOUD_DEPLOY_ROLLOUT

    L'ID dell'implementazione 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 dell'implementazione che contiene il job per gli hook.

Passaggi successivi