Seção “hooks” de AppSpec - AWS CodeDeploy
A seção “hooks” AppSpec para uma implantação Amazon ECSA seção “hooks” AppSpec para uma implantação AWS LambdaA seção “hooks” AppSpec para uma implantação EC2/On-Premises

Seção “hooks” de AppSpec

O conteúdo da seção 'hooks' do arquivo AppSpec varia de acordo com a plataforma de computação para a implantação. A seção 'hooks' para uma implantação EC2/On-Premises contém mapeamentos que vinculam os hooks de evento do ciclo de vida de implantação a um ou mais scripts. A seção 'hooks' para uma implantação do Lambda ou Amazon ECS especifica as funções de validação Lambda que serão executadas durante um evento de ciclo de vida de implantação. Se um gancho de evento não estiver presente, nenhuma operação será executada para esse evento. Esta seção é necessária somente se você está executando scripts ou funções de validação do Lambda como parte da implantação.

A seção “hooks” AppSpec para uma implantação Amazon ECS

Lista de hooks do evento do ciclo de vida para uma implantação Amazon ECS

Um hook Lambda AWS é uma função do Lambda especificada com uma string em uma nova linha após o nome do evento de ciclo de vida. Cada gancho é executado uma vez por implantação. Veja a seguir as descrições dos eventos de ciclo de vida em que você pode executar um hook durante uma implantação do Amazon ECS.

  • BeforeInstall: use para executar tarefas antes que o conjunto de tarefas de substituição seja criado. Um grupo de destino é associado ao conjunto de tarefas original. Se um listener de teste opcional for especificado, ele será associado ao conjunto de tarefas original. Não é possível fazer uma reversão nesse momento.

  • AfterInstall: use para executar tarefas depois que o conjunto de tarefas de substituição for criado e um dos grupos de destino for associado a ele. Se um listener de teste opcional for especificado, ele será associado ao conjunto de tarefas original. Os resultados de uma função de gancho nesse evento de ciclo de vida podem acionar uma reversão.

  • AfterAllowTestTraffic: use para executar tarefas depois que o receptor de teste distribuir o tráfego para o conjunto de tarefas de substituição. Os resultados de uma função de gancho, nesse momento, podem acionar uma reversão.

  • BeforeAllowTraffic: use para executar tarefas depois que o segundo grupo de destino for associado ao conjunto de tarefas de substituição, mas antes que o tráfego seja deslocado para o conjunto de tarefas de substituição. Os resultados de uma função de gancho nesse evento de ciclo de vida podem acionar uma reversão.

  • AfterAllowTraffic: use para executar tarefas depois que o segundo grupo de destino distribuir o tráfego para o conjunto de tarefas de substituição. Os resultados de uma função de gancho nesse evento de ciclo de vida podem acionar uma reversão.

Para obter mais informações, consulte O que acontece durante uma implantação do e Tutorial: Implantar um serviço do Amazon ECS com um teste de validação.

Ordem de execução de hooks em uma implantação do Amazon ECS.

Em uma implantação do Amazon ECS, hooks de eventos são executados na seguinte ordem:

A ordem de hooks de eventos em uma implantação do Amazon ECS.
nota

Os eventos Start, Install, TestTraffic, AllowTraffic e End na implantação não podem ser expressos em scripts, e é por isso que eles são exibidos em cinza nesse diagrama.

Estrutura da seção 'hooks'

Os seguintes são exemplos da estrutura da seção 'hooks'.

Uso de YAML:

Hooks:
  - BeforeInstall: "BeforeInstallHookFunctionName"
  - AfterInstall: "AfterInstallHookFunctionName"
  - AfterAllowTestTraffic: "AfterAllowTestTrafficHookFunctionName"
  - BeforeAllowTraffic: "BeforeAllowTrafficHookFunctionName"
  - AfterAllowTraffic: "AfterAllowTrafficHookFunctionName"

Uso de JSON:

"Hooks": [
		{
			"BeforeInstall": "BeforeInstallHookFunctionName"
		},
		{
			"AfterInstall": "AfterInstallHookFunctionName"
		},
		{
			"AfterAllowTestTraffic": "AfterAllowTestTrafficHookFunctionName"
		},
		{
			"BeforeAllowTraffic": "BeforeAllowTrafficHookFunctionName"
		},
		{
			"AfterAllowTraffic": "AfterAllowTrafficHookFunctionName"
		}
	]
}

Exemplo da função do Lambda 'hooks'

Use a seção 'hooks' para especificar uma função do Lambda que o CodeDeploy pode chamar para validar uma implantação do Amazon ECS. É possível usar a mesma função ou uma diferente para os eventos de ciclo de vida de implantação BeforeInstall, AfterInstall, AfterAllowTestTraffic, BeforeAllowTraffic e AfterAllowTraffic. Após a conclusão dos testes de validação, a função do Lambda AfterAllowTraffic chama de volta o CodeDeploy e entrega um resultado de Succeeded ou Failed.

Importante

Considera-se que houve falha na implantação se o CodeDeploy não for notificado pela função do Lambda de validação dentro de uma hora.

Antes de invocar uma função de hook do Lambda, o servidor deve ser notificado sobre o ID de implantação e o ID de execução do hook de evento de ciclo de vida usando o comando putLifecycleEventHookExecutionStatus.

A seguir está um exemplo de uma função de hook do Lambda escrita em Node.js. 

'use strict';

const aws = require('aws-sdk');
const codedeploy = new aws.CodeDeploy({apiVersion: '2014-10-06'});

exports.handler = (event, context, callback) => {
    //Read the DeploymentId from the event payload.
    var deploymentId = event.DeploymentId;

    //Read the LifecycleEventHookExecutionId from the event payload
    var lifecycleEventHookExecutionId = event.LifecycleEventHookExecutionId;

    /*
     Enter validation tests here.
    */

    // Prepare the validation test results with the deploymentId and
    // the lifecycleEventHookExecutionId for CodeDeploy.
    var params = {
        deploymentId: deploymentId,
        lifecycleEventHookExecutionId: lifecycleEventHookExecutionId,
        status: 'Succeeded' // status can be 'Succeeded' or 'Failed'
    };
    
    // Pass CodeDeploy the prepared validation test results.
    codedeploy.putLifecycleEventHookExecutionStatus(params, function(err, data) {
        if (err) {
            // Validation failed.
            callback('Validation test failed');
        } else {
            // Validation succeeded.
            callback(null, 'Validation test succeeded');
        }
    });
};

A seção “hooks” AppSpec para uma implantação AWS Lambda

Lista de hooks do evento do ciclo de vida para uma implantação AWS Lambda

Um hook Lambda AWS é uma função do Lambda especificada com uma string em uma nova linha após o nome do evento de ciclo de vida. Cada gancho é executado uma vez por implantação. Veja a seguir as descrições dos ganchos disponíveis para uso no arquivo AppSpec.

  • BeforeAllowTraffic: use para executar tarefas antes que o tráfego seja deslocado para a versão da função do Lambda;

  • AfterAllowTraffic: use para executar tarefas depois que o tráfego for deslocado para a versão da função do Lambda;

Ordem de execução de hooks em uma implantação da versão da função do Lambda

Em uma implantação da versão da função do Lambda com tecnologia sem servidor, os hooks de eventos são executados na seguinte ordem:

Ordem de hooks de eventos em uma implantação do Lambda.
nota

Os eventos Start, AllowTraffic e End na implantação não podem ser especificados em scripts e é por isso que aparecem em cinza nesse diagrama.

Estrutura da seção 'hooks'

Os seguintes são exemplos da estrutura da seção 'hooks'.

Uso de YAML:

hooks:
   - BeforeAllowTraffic: BeforeAllowTrafficHookFunctionName
   - AfterAllowTraffic: AfterAllowTrafficHookFunctionName

Uso de JSON:

"hooks": [{
    "BeforeAllowTraffic": "BeforeAllowTrafficHookFunctionName"
    },
    {
    "AfterAllowTraffic": "AfterAllowTrafficHookFunctionName"
}]

Exemplo da função do Lambda 'hooks'

Use a seção "hooks" para especificar uma função do Lambda que o CodeDeploy possa chamar para validar uma implantação do Lambda. É possível usar a mesma função ou uma diferente para os eventos de ciclo de vida de implantação BeforeAllowTraffic e AfterAllowTraffic. Após a conclusão dos testes de validação, a função do Lambda chama de volta o CodeDeploy e entrega um resultado de Succeeded ou Failed.

Importante

Considera-se que houve falha na implantação se o CodeDeploy não for notificado pela função do Lambda de validação dentro de uma hora.

Antes de invocar uma função de hook do Lambda, o servidor deve ser notificado sobre o ID de implantação e o ID de execução do hook de evento de ciclo de vida usando o comando putLifecycleEventHookExecutionStatus.

A seguir está um exemplo de uma função de hook do Lambda escrita em Node.js. 

'use strict';

const aws = require('aws-sdk');
const codedeploy = new aws.CodeDeploy({apiVersion: '2014-10-06'});

exports.handler = (event, context, callback) => {
    //Read the DeploymentId from the event payload.
    var deploymentId = event.DeploymentId;

    //Read the LifecycleEventHookExecutionId from the event payload
    var lifecycleEventHookExecutionId = event.LifecycleEventHookExecutionId;

    /*
     Enter validation tests here.
    */

    // Prepare the validation test results with the deploymentId and
    // the lifecycleEventHookExecutionId for CodeDeploy.
    var params = {
        deploymentId: deploymentId,
        lifecycleEventHookExecutionId: lifecycleEventHookExecutionId,
        status: 'Succeeded' // status can be 'Succeeded' or 'Failed'
    };
    
    // Pass CodeDeploy the prepared validation test results.
    codedeploy.putLifecycleEventHookExecutionStatus(params, function(err, data) {
        if (err) {
            // Validation failed.
            callback('Validation test failed');
        } else {
            // Validation succeeded.
            callback(null, 'Validation test succeeded');
        }
    });
};

A seção “hooks” AppSpec para uma implantação EC2/On-Premises

Lista de hooks de eventos de ciclo de vida

Um hook de implantação EC2/On-Premises é executado uma vez por implantação a uma instância. Você pode especificar um ou mais scripts a serem executados em um gancho. Cada gancho para um evento de ciclo de vida é especificado com uma string em uma linha separada. Veja a seguir as descrições dos ganchos disponíveis para uso no arquivo AppSpec.

Para obter informações sobre quais ganchos de eventos de ciclo de vida são válidos para quais tipos de implantação e reversão, consulte Disponibilidade de hooks de eventos de ciclo de vida.

  • ApplicationStop: esse evento de ciclo de vida de implantação ocorre mesmo antes do download da revisão de aplicativo. É possível especificar scripts para esse evento de forma a interromper normalmente o aplicativo ou remover pacotes atualmente instalados na preparação para uma implantação. O arquivo AppSpec e os scripts usados para esse evento de ciclo de vida de implantação são da revisão de aplicativo anterior implementada com êxito.

    nota

    Um arquivo AppSpec não existe em uma instância antes de implantar nela. Por esse motivo, o gancho ApplicationStop não é executado da primeira vez em que você implanta na instância. Você poderá usar o gancho ApplicationStop na segunda vez que implantar em uma instância.

    Para determinar a localização da revisão de aplicativo mais recente implantada com êxito, o agente do CodeDeploy procura pela localização listada no arquivo deployment-group-id_last_successful_install. Esse arquivo está localizado em:

    Pasta /opt/codedeploy-agent/deployment-root/deployment-instructions em instâncias do Amazon Linux, do Ubuntu Server e do RHEL do Amazon EC2.

    Pasta C:\ProgramData\Amazon\CodeDeploy\deployment-instructions em instâncias do Windows Server Amazon EC2

    Para solucionar um problema de falha na implantação durante o evento de ciclo de vida de implantação ApplicationStop, consulte Solução de problemas com eventos de ciclo de vida de implantação ApplicationStop, BeforeBlockTraffic e AfterBlockTraffic.

  • DownloadBundle: durante esse evento de ciclo de vida de implantação, o agente do CodeDeploy copia os arquivos de revisão de aplicativo para uma localização temporária:

    Pasta /opt/codedeploy-agent/deployment-root/deployment-group-id/deployment-id/deployment-archive em instâncias do Amazon Linux, do Ubuntu Server e do RHEL do Amazon EC2.

    Pasta C:\ProgramData\Amazon\CodeDeploy\deployment-group-id\deployment-id\deployment-archive em instâncias do Windows Server Amazon EC2

    Esse evento é reservado para o agente do CodeDeploy e não pode ser usado para executar scripts.

    Para solucionar um problema de falha na implantação durante o evento de ciclo de vida de implantação DownloadBundle, consulte Solucionar problemas com um evento de ciclo de vida de implantação DownloadBundle com falha que indica "UnknownError: not opened for reading".

  • BeforeInstall: use esse evento de ciclo de vida de implantação para tarefas de pré-instalação, como descriptografar arquivos e criar um backup da versão atual.

  • Install: durante esse evento de ciclo de vida da implantação, o agente do CodeDeploy copia os arquivos de revisão de um local temporário para a pasta de destino final. Esse evento é reservado para o agente do CodeDeploy e não pode ser usado para executar scripts.

  • AfterInstall: use esse evento de ciclo de vida de implantação para tarefas como configurar seu aplicativo ou alterar as permissões dos arquivos.

  • ApplicationStart: normalmente, você usa esse evento de ciclo de vida de implantação para reiniciar os serviços que foram interrompidos durante o ApplicationStop.

  • ValidateService: este é o último evento de ciclo de vida de implantação. Ele é usado para verificar se a implantação foi concluída com êxito.

  • BeforeBlockTraffic: você pode usar esse evento de ciclo de vida de implantação para executar tarefas em instâncias antes que elas tenham seu registro cancelado em um balanceador de carga.

    Para solucionar um problema de falha na implantação durante o evento de ciclo de vida de implantação BeforeBlockTraffic, consulte Solução de problemas com eventos de ciclo de vida de implantação ApplicationStop, BeforeBlockTraffic e AfterBlockTraffic.

  • BlockTraffic: durante esse evento de ciclo de vida de implantação, o tráfego da Internet é impedido de acessar as instâncias que atualmente estão distribuindo o tráfego. Esse evento é reservado para o agente do CodeDeploy e não pode ser usado para executar scripts.

  • AfterBlockTraffic: você pode usar esse evento de ciclo de vida de implantação para executar tarefas em instâncias depois que elas tenham seu registro cancelado em seu respectivo balanceador de carga.

    Para solucionar um problema de falha na implantação durante o evento de ciclo de vida de implantação AfterBlockTraffic, consulte Solução de problemas com eventos de ciclo de vida de implantação ApplicationStop, BeforeBlockTraffic e AfterBlockTraffic.

  • BeforeAllowTraffic: você pode usar esse evento de ciclo de vida de implantação para executar tarefas em instâncias antes que elas sejam registradas em um balanceador de carga.

  • AllowTraffic: durante esse evento de ciclo de vida de implantação, o tráfego da Internet pode acessar instâncias após uma implantação. Esse evento é reservado para o agente do CodeDeploy e não pode ser usado para executar scripts.

  • AfterAllowTraffic: você pode usar esse evento de ciclo de vida de implantação para executar tarefas em instâncias depois que elas sejam registradas em um balanceador de carga.

Disponibilidade de hooks de eventos de ciclo de vida

A tabela a seguir lista os ganchos de eventos de ciclo de vida disponíveis para cada cenário de implantação e reversão.

Nome do evento de ciclo de vida Implantação de inicialização do Auto Scaling¹ Implantação de encerramento do Auto Scaling¹ Implantação no local² Implementação azul/verde: instâncias originais Implementação azul/verde: instâncias de substituição Reversão de implementação azul/verde: instâncias originais Reversão de implantação azul/verde: instâncias de substituição
ApplicationStop ✓ ✓ ✓ ✓
DownloadBundle³ ✓ ✓ ✓
BeforeInstall ✓ ✓ ✓
Instalar³ ✓ ✓ ✓
AfterInstall ✓ ✓ ✓
ApplicationStart ✓ ✓ ✓
ValidateService ✓ ✓ ✓
BeforeBlockTraffic ✓ ✓ ✓ ✓
BlockTraffic³ ✓ ✓ ✓ ✓
AfterBlockTraffic ✓ ✓ ✓ ✓
BeforeAllowTraffic ✓ ✓ ✓ ✓
AllowTraffic³ ✓ ✓ ✓ ✓
AfterAllowTraffic ✓ ✓ ✓ ✓

¹ Para obter informações sobre as implantações do Amazon EC2 Auto Scaling, consulte Como o Amazon EC2 Auto Scaling funciona com o CodeDeploy.

² Também se aplica à reversão de uma implantação no local.

³ Reservado para operações do CodeDeploy. Não pode ser usado para executar scripts.

Ordem de execução de hooks em uma implantação

Implantações de inicialização do Auto Scaling

Durante uma implantação de inicialização do Auto Scaling, o CodeDeploy executa hooks de eventos na ordem a seguir.

Para obter mais informações sobre as implantações de inicialização do Auto Scaling, consulte Como o Amazon EC2 Auto Scaling funciona com o CodeDeploy.

A ordem de hooks de eventos durante uma implantação de inicialização do Auto Scaling.
nota

Os eventos Start, DownloadBundle, Install, AllowTraffic e End na implantação não podem ser expressos em scripts, e é por isso que eles são exibidos em cinza neste diagrama. No entanto, é possível editar a seção 'files' do arquivo AppSpec para especificar o que é instalado durante o evento Instalação.

Implantações de encerramento do Auto Scaling

Durante uma implantação de encerramento do Auto Scaling, o CodeDeploy executa hooks de eventos na ordem a seguir.

Para obter mais informações sobre as implantações de encerramento do Auto Scaling, consulte Ativar implantações de encerramento durante eventos de redução da escala horizontal do Auto Scaling.

A ordem de hooks de eventos durante uma implantação de encerramento do Auto Scaling.
nota

Os eventos Start, BlockTraffic e End na implantação não podem ser especificados em scripts, e é por isso que aparecem em cinza neste diagrama.

Implantações no local

Em uma implantação no local, incluindo a reversão de uma implantação no local, ganchos de eventos são executados na seguinte ordem:

nota

Para implantações no local, os seis hooks relacionados ao bloqueio e à permissão de tráfego apenas serão aplicáveis se você especificar um Classic Load Balancer, Application Load Balancer ou Network Load Balancer do Elastic Load Balancing no grupo de implantação.

A ordem de hooks de eventos durante a reversão de uma implantação no local.
nota

Os eventos Start, DownloadBundle, Install e End na implantação não podem ser especificados em scripts e é por isso que aparecem em cinza nesse diagrama. No entanto, é possível editar a seção 'files' do arquivo AppSpec para especificar o que é instalado durante o evento Instalação.

Implantações azuis/verdes

Em uma implantação azul/verde, ganchos de eventos são executados na seguinte ordem:

A ordem de hooks de eventos em uma implantação azul/verde.
nota

Os eventos Start, DownloadBundle, Install, BlockTraffic, AllowTraffic e End na implantação não podem ser especificados em scripts e é por isso que aparecem em cinza nesse diagrama. No entanto, é possível editar a seção “files” do arquivo AppSpec para especificar o que é instalado durante o evento Instalação.

Estrutura da seção 'hooks'

A seção 'hooks' tem a seguinte estrutura:

hooks:
   deployment-lifecycle-event-name:
     - location: script-location
       timeout: timeout-in-seconds
       runas: user-name

É possível incluir os seguintes elementos em uma entrada hook após o nome do evento de ciclo de vida de implantação:

local

Obrigatório. A localização no pacote do arquivo de script para a revisão. A localização dos scripts que você especifica na seção hooks é relativa à raiz do empacotamento de revisão de aplicativo. Para obter mais informações, consulte Planejar uma revisão para o CodeDeploy.

timeout

Opcional. O número de segundos para permitir que o script seja executado antes que ele seja considerado com falha. O padrão é 3600 segundos (1 hora).

nota

3600 segundos (1 hora) é o tempo máximo permitido para a execução do script para cada evento de ciclo de vida de implantação. Se os scripts excederem esse limite, a implantação será interrompida, e a implantação na instância falhará. Certifique-se de que o número total de segundos especificado em timeout para todos os scripts em cada evento de ciclo de vida de implantação não exceda esse limite.

runas

Opcional. O usuário para representar ao executar o script. Por padrão, este é o agente do CodeDeploy em execução na instância. O CodeDeploy não armazena senhas e, portanto, o usuário não poderá ser representado se o usuário runas precisar de uma senha. Esse elemento se aplica somente às instâncias Amazon Linux e Ubuntu Server.

Referenciar arquivos em scripts de hook

Se você estiver fazendo hook de um script em um evento de ciclo de vida do CodeDeploy, conforme descrito em Seção “hooks” de AppSpec, e quiser referenciar um arquivo (por exemplo, helper.sh) no script, será necessário especificar helper.sh utilizando:

Utilizar caminhos absolutos

Para referenciar um arquivo utilizando o caminho absoluto, você pode:

Local de arquivamento da implantação

Durante o evento de ciclo de vida do DownloadBundle, o agente do CodeDeploy extrai a revisão da implantação em um diretório que tem o seguinte formato:

root-directory/deployment-group-id/deployment-id/deployment-archive

A parte do root-directory do caminho é sempre definida como o padrão mostrado na tabela a seguir ou é controlada pela definição de configuração de :root_dir. Para obter mais informações sobre as definições das configurações, consulte Referência de configuração do agente do CodeDeploy.

Plataforma de agentes Diretório raiz padrão
Linux: todas as distribuições de rpm /opt/codedeploy-agent/deployment-root
Ubuntu Server: todas as distribuições de deb /opt/codedeploy-agent/deployment-root
Windows Server %ProgramData%\Amazon\CodeDeploy

Nos scripts de hook, é possível acessar o arquivo de implantação atual utilizando o caminho do diretório raiz e as variáveis de ambiente DEPLOYMENT_ID e DEPLOYMENT_GROUP_ID. Para obter mais informações sobre as variáveis, consulte Disponibilidade variáveis de ambientes para hooks.

Por exemplo, veja como é possível acessar um arquivo data.json que reside na raiz da revisão no Linux:

#!/bin/bash

rootDirectory="/opt/codedeploy-agent/deployment-root" # note: this will be different if you
                                                      # customize the :root_dir configuration
dataFile="$rootDirectory/$DEPLOYMENT_GROUP_ID/$DEPLOYMENT_ID/deployment-archive/data.json"
data=$(cat dataFile)

Como outro exemplo, veja como é possível acessar um arquivo data.json que reside na raiz da revisão utilizando o Powershell no Windows:

$rootDirectory="$env:ProgramData\Amazon\CodeDeploy" # note: this will be different if you
                                                    # customize the :root_dir configuration
$dataFile="$rootDirectory\$env:DEPLOYMENT_GROUP_ID\$env:DEPLOYMENT_ID\deployment-archive\data.json"
$data=(Get-Content $dataFile)

Utilizar caminhos relativos

Para referenciar um arquivo utilizando o caminho relativo, você precisará conhecer o diretório de trabalho do agente do CodeDeploy. Os caminhos dos arquivos são relativos a esse diretório.

A tabela a seguir mostra o diretório de trabalho de cada plataforma compatível com o agente do CodeDeploy.

Plataforma de agentes Método de gerenciamento do processo Diretório de trabalho de scripts de eventos de ciclo de vida
Linux: todas as distribuições de rpm systemd (padrão) /
init.d: saiba mais /opt/codedeploy-agent
Ubuntu Server: todas as distribuições de debian tudo /opt/codedeploy-agent
Windows Server não aplicável C:\Windows\System32

Disponibilidade variáveis de ambientes para hooks

Durante cada evento de ciclo de vida de implantação, os scripts hook podem acessar as seguintes variáveis de ambiente:

APPLICATION_NAME

O nome do aplicativo no CodeDeploy que faz parte da implantação atual (por exemplo, WordPress_App).

DEPLOYMENT_ID

O ID do CodeDeploy que foi atribuído à implantação atual (por exemplo, d-AB1CDEF23).

DEPLOYMENT_GROUP_NAME

O nome do grupo de implantação no CodeDeploy que faz parte da implantação atual (por exemplo, WordPress_DepGroup).

DEPLOYMENT_GROUP_ID

O ID do grupo de implantação no CodeDeploy que faz parte da implantação atual (por exemplo, b1a2189b-dd90-4ef5-8f40-4c1c5EXAMPLE).

LIFECYCLE_EVENT

O nome do evento de ciclo de vida de implantação atual (por exemplo, AfterInstall).

Essas variáveis de ambiente são locais para cada evento de ciclo de vida de implantação.

Há variáveis de ambiente adicionais disponíveis para scripts de hook, dependendo da origem do empacotamento de implantação:

Empacotamento do Amazon S3

  • BUNDLE_BUCKET

    O nome do bucket do Amazon S3 do qual o empacotamento de implantação foi baixado por download (por exemplo, my-s3-bucket).

  • BUNDLE_KEY

    A chave do objeto para o empacotamento baixado dentro do bucket do Amazon S3 (por exemplo, WordPress_App.zip).

  • BUNDLE_VERSION

    A versão do objeto do empacotamento (por exemplo, 3sL4kqtJlcpXroDTDmJ+rmSpXd3dIbrHY+MTRCxf3vjVBH40Nr8X8gdRQBpUMLUo). Essa variável só é definida se o bucket do Amazon S3 tiver o versionamento de objetos ativado.

  • BUNDLE_ETAG

    A etag do objeto do empacotamento (por exemplo, b10a8db164e0754105b7a99be72e3fe5-4).

Empacotamento do GitHub

  • BUNDLE_COMMIT

    O hash de confirmação SHA256 do empacotamento gerado pelo Git (por exemplo, d2a84f4b8b650937ec8f73cd8be2c74add5a911ba64df27458ed8229da804a26).

O script a seguir mudará a porta de escuta em um servidor Apache HTTP para 9090 em vez de 80 se o valor de DEPLOYMENT_GROUP_NAME for igual a Staging. Este script deve ser invocado durante o evento de ciclo de vida de implantação BeforeInstall:

if [ "$DEPLOYMENT_GROUP_NAME" == "Staging" ]
then
    sed -i -e 's/Listen 80/Listen 9090/g' /etc/httpd/conf/httpd.conf
fi

O exemplo de script a seguir alterará o nível de detalhamento das mensagens registradas em seu log de erros de aviso para depuração quando o valor da variável de ambiente DEPLOYMENT_GROUP_NAME for igual a Staging. Este script deve ser invocado durante o evento de ciclo de vida de implantação BeforeInstall:

if [ "$DEPLOYMENT_GROUP_NAME" == "Staging" ]
then
    sed -i -e 's/LogLevel warn/LogLevel debug/g' /etc/httpd/conf/httpd.conf
fi

O exemplo de script a seguir substitui o texto na página da Web especificada pelo texto que exibe o valor dessas variáveis de ambiente. Este script deve ser invocado durante o evento de ciclo de vida de implantação AfterInstall:

#!/usr/bin/python

import os
 
strToSearch="<h2>This application was deployed using CodeDeploy.</h2>"
strToReplace="<h2>This page for "+os.environ['APPLICATION_NAME']+" application and "+os.environ['DEPLOYMENT_GROUP_NAME']+" deployment group with "+os.environ['DEPLOYMENT_GROUP_ID']+" deployment group ID was generated by a "+os.environ['LIFECYCLE_EVENT']+" script during "+os.environ['DEPLOYMENT_ID']+" deployment.</h2>"
 
fp=open("/var/www/html/index.html","r")
buffer=fp.read()
fp.close()
 
fp=open("/var/www/html/index.html","w")
fp.write(buffer.replace(strToSearch,strToReplace))
fp.close()

Exemplo de hooks

Veja a seguir um exemplo de uma entrada de ganchos que especifica dois ganchos para o evento de ciclo de vida AfterInstall:

hooks:
   AfterInstall:
     - location: Scripts/RunResourceTests.sh
       timeout: 180
     - location: Scripts/PostDeploy.sh
       timeout: 180

O script Scripts/RunResourceTests.sh será executado durante o estágio AfterInstall do processo de implantação. A implantação não terá êxito se o script precisar de mais de 180 segundos (3 minutos) para ser executado.

A localização dos scripts que você especifica na seção hooks é relativa à raiz do pacote de revisão de aplicativo. No exemplo anterior, um arquivo chamado RunResourceTests.sh está em um diretório chamado Scripts. O diretório Scripts está no nível raiz do pacote. Para obter mais informações, consulte Planejar uma revisão para o CodeDeploy.