Esegui gli hook prima e dopo il deployment

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

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

Puoi configurare ogni hook in modo che venga eseguito in un ambiente di esecuzione Cloud Deploy specificato, ma se esegui il deployment in Google Kubernetes Engine, puoi configurarlo facoltativamente in modo che venga eseguito 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 sola, non c'è alcun effetto aggiuntivo.

Come funzionano gli hook di deployment?

Di seguito sono descritti i passaggi per configurare i hook di deployment e la procedura di Skaffold e Cloud Deploy per eseguirli:

  1. Configura il skaffold.yaml utilizzato per una determinata release in modo da includere customActions che identificano l'immagine o le immagini del contenitore da utilizzare per eseguire gli hook e il comando o lo script specifico da eseguire su ogni contenitore.

  2. Configura gli hook in uno o più passaggi della progressione della pipeline di distribuzione, ognuno dei quali fa riferimento a uno dei customActions configurati 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 nella pipeline progressione.

    L'hook predeploy viene sempre eseguito come primo job della 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 nel corso della progressione della pipeline.

Gli hook di deployment vengono eseguiti nell'esecuzione predefinita di Cloud Deploy dell'ambiente di lavoro o in un ambiente di esecuzione alternativo specificato. Per i deployment su GKE e GKE Enterprise, facoltativamente puoi eseguire gli hook nello 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, devi tenere presente diverse cose:

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

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

Configura le azioni in Skaffold

Nel file skaffold.yaml, la stanza customActions accetta una o più stanze customActions, 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 scegliere un nome qualsiasi, ma deve essere univoci in questo skaffold.yaml. Questo è il nome a cui farà riferimento le azioni pre- e post-deployment definite nella fase della pipeline di distribuzione.

  • CONTAINER_NAME

    È il nome del container specifico. Puoi scegliere il nome che preferisci, deve essere univoco all'interno di questo skaffold.yaml.

  • IMAGE

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

  • COMMANDS_TO_RUN

    È un elenco di punti di ingresso da eseguire su quel container. "/bin/sh" è un valore tipico da specificare qui, richiamare una shell, e dovresti includere il comando in esecuzione nella shell negli argomenti.

  • LIST_OF_ARGS

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

    Ecco un esempio:

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

Per saperne 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, configura la pipeline di importazione in modo che faccia riferimento alle azioni personalizzate che hai definito nel file skaffold.yaml. Le azioni pre e post-deployment sono configurate in uno o più specifiche nella pipeline progressione.

Di seguito è descritto come configurare gli hook pre e post-deployment in una 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 a ACTION_NAME che hai utilizzato in skaffold.yaml per definire l'azione personalizzata da eseguire prima del deployment.

  • POSTDEPLOY_ACTION

    È uguale a 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 vengono specificate più azioni, queste vengono eseguite in serie, nel nell'ordine in cui vengono specificati. Il job (predeploy o postdeploy) non va a buon fine alla prima azione che non va a buon fine e le azioni rimanenti non vengono eseguite.

Per impostazione predefinita, se esegui più di un container, in parallelo, un errore, entrambi i container vengono arrestati. Puoi configurare questo comportamento utilizzando Strategia personalizzata di non riuscita per le azioni personalizzate Skaffold.

Esegui gli hook sul cluster dell'applicazione

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

Questa funzionalità è disponibile per i deployment in GKE Solo 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 un'istruzione executionMode.kubernetesCluster stanza del file di configurazione skaffold.yaml, all'interno di customActions stanza 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 è riportato un esempio di stanza customActions che include executionMode per richiamare il container hook sul cluster di applicazioni:

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 la un container di azioni personalizzate nell'ambiente di esecuzione di Cloud Deploy.

Variabili di ambiente disponibili

Cloud Deploy fornisce e compila il seguente ambiente variabili nell'ambiente di esecuzione, che puoi utilizzare per i tuoi hook:

  • ANTHOS_MEMBERSHIP

    Per le destinazioni di tipo ANTHOS, il nome risorsa completamente specificato di Anthos .

  • CLOUD_RUN_LOCATION

    Per le destinazioni di tipo RUN, la regione in cui è il servizio Cloud Run di cui è stato eseguito il deployment.

  • CLOUD_RUN_PROJECT

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

  • 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 terminano che gli utenti utilizzeranno per accedere al tuo servizio. Puoi trovare queste informazioni Dettagli per il tuo servizio Cloud Run, nella sezione 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 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 importazione.

  • CLOUD_DEPLOY_TARGET

    L'ID del target.

  • 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 nell'implementazione che contiene il job per gli hook.

Esegui il deployment dei parametri come variabili di ambiente

Oltre alle variabili di ambiente elencate in questa sezione, Cloud Deploy può passare ai container personalizzati tutti i parametri di deployment che hai impostato.

Scopri di più.

Passaggi successivi