Solucionar problemas de implantação no EC2/On-Premises

Erro de credenciais ausentes do plug-in do CodeDeploy CommandPoller

Se você receber um erro semelhante a InstanceAgent::Plugins::CodeDeployPlugin::CommandPoller: Missing credentials - please check if this instance was started with an IAM instance profile, a causa pode ser uma das seguintes:

Um perfil de instância do IAM concede ao agente do CodeDeploy permissão para se comunicar com o CodeDeploy e fazer download da sua revisão do Amazon S3. Para instâncias do EC2, consulte Gerenciamento de identidade e acesso para o AWS CodeDeploy. Para instâncias locais, consulte Working with On-Premises Instances.

A implantação falha com a mensagem "Validation of PKCS7 signed message failed"

Essa mensagem de erro indica que a instância está executando uma versão do agente do CodeDeploy que apenas oferece suporte ao algoritmo de hash SHA-1. O suporte para o algoritmo de hash SHA-2 foi introduzido na versão 1.0.1.854 do agente do CodeDeploy, lançada em novembro de 2015. Desde 17 de outubro de 2016, as implantações falham caso uma versão do agente do CodeDeploy anterior à 1.0.1.854 esteja instalada. Para obter mais informações, consulte AWS para mudar para o algoritmo de hash SHA256 para certificados SSL, AVISO: desativando atendentes de host do CodeDeploy anteriores à versão 1.0.1.85 e Atualizar o agente do CodeDeploy.

A implantação ou reimplantação dos mesmos arquivos nos mesmos locais de instância falha com um erro indicando que a implantação falhou porque um arquivo especificado já existe na localização

Quando o CodeDeploy tenta implantar um arquivo em uma instância, mas um arquivo com o mesmo nome já existe na localização de destino especificada, a implantação nessa instância pode falhar. Você poderá receber a mensagem de erro indicando que a implantação falhou porque um arquivo especificado já existe na localização location-name. Isso ocorre porque, durante cada implantação, o CodeDeploy primeiro exclui todos os arquivos da implantação anterior, que estão listados em um arquivo de log de limpeza. Se houver arquivos nas pastas de instalação de destino que não estão listados nesse arquivo de limpeza, o agente do CodeDeploy, por padrão, interpretará isso como um erro e reprovará a implantação.

A maneira mais fácil de evitar esse erro é especificar uma opção diferente do comportamento padrão de reprovar a implantação. Para cada implantação, você pode optar por reprovar a implantação, substituir os arquivos não listados no arquivo de limpeza ou manter os arquivos que já estão na instância.

A opção de substituição é útil quando, por exemplo, você colocou manualmente um arquivo em uma instância após a última implantação, mas adicionou um arquivo com o mesmo nome à próxima revisão de aplicativo.

É possível escolher a opção de retenção para os arquivos colocados na instância que você deseja que façam parte da próxima implantação sem precisar adicioná-los ao pacote de revisão de aplicativo. A opção de retenção também é útil quando seus arquivos de aplicativo já estão em seu ambiente de produção, e você deseja implantar usando o CodeDeploy pela primeira vez. Para obter mais informações, consulte Componentes de implantação em uma plataforma de computação EC2/On-Premises (console) e Comportamento de reversão com conteúdo existente.

Solução de problemas de erros de implantação The deployment failed because a specified file already exists at this location

Se você optar por não especificar uma opção para substituir ou reter o conteúdo detectado pelo CodeDeploy nos seus locais de implantação de destino (ou se não especificar nenhuma opção de implantação para lidar com conteúdo existente em um comando programático), será possível optar por solucionar o erro.

As informações a seguir aplicam-se somente quando você opta por não reter ou substituir o conteúdo.

Se você tentar redistribuir arquivos com os mesmos nomes e localizações, a reimplantação terá melhores chances de sucesso se você especificar o nome do aplicativo e o grupo de implantação com o mesmo ID de grupo de implantação subjacente usado antes. O CodeDeploy usa o ID de grupo de implantação subjacente para identificar arquivos a serem removidos antes de uma reimplantação.

A implantação de novos arquivos ou a reimplantação dos mesmos arquivos nas mesmas localizações em instâncias pode falhar por estes motivos:

Para resolver essas situações, siga um destes procedimentos:

Caminhos de arquivo longos causam erros do tipo “Nenhum arquivo ou diretório”

Para implantações em instâncias do Windows, se você tiver um caminho de arquivo com mais de 260 caracteres na seção de arquivos do seu arquivo appspec.yml, talvez as implantações falhem com um erro semelhante ao seguinte:

No such file or directory @ dir_s_mkdir - C:\your-long-file-path

Esse erro ocorre porque, por padrão, o Windows não permite caminhos de arquivo maiores que 260 caracteres, conforme detalhado na documentação da Microsoft.

Para as versões 1.4.0 ou posteriores do agente do CodeDeploy, você pode ativar caminhos de arquivo longos de duas maneiras, dependendo do processo de instalação do agente:

Se o agente do CodeDeploy ainda não tiver sido instalado:

Se o agente do CodeDeploy já tiver sido instalado:

Processos de execução longa podem fazer com que as implantações falhem

Para implantações em instâncias Amazon Linux, Ubuntu Server e RHEL, se você tiver um script de implantação que inicia um processo de longa execução, o CodeDeploy poderá demorar muito tempo em espera no evento de ciclo de vida de implantação e reprovar a implantação. Isso ocorre porque, se o processo demorar mais que o tempo esperado para os processos de primeiro e segundo plano nesse evento, o CodeDeploy interromperá e reprovará a implantação, mesmo que o processo ainda esteja sendo executado conforme o esperado.

Por exemplo, uma revisão de aplicativo contém dois arquivos em sua raiz, after-install.sh e sleep.sh. Seu arquivo AppSpec contém as seguintes instruções:

version: 0.0
os: linux
files:
  - source: ./sleep.sh
    destination: /tmp
hooks:
  AfterInstall:
    - location: after-install.sh
      timeout: 60

O arquivo after-install.sh é executado durante o evento de ciclo de vida de aplicativo AfterInstall. Seu conteúdo é o seguinte:

#!/bin/bash
/tmp/sleep.sh

O arquivo sleep.sh contém o seguinte, que suspende a execução do programa por três minutos (180 segundos), simulando alguns processos de execução longa:

#!/bin/bash
sleep 180

Quando after-install.sh chamar sleep.sh, sleep.sh será iniciado e executado por três minutos (180 segundos), o que corresponde a dois minutos (120 segundos) além do tempo estimado pelo CodeDeploy sleep.sh para a interrupção da execução (e, por conseguinte, after-install.sh). Após o tempo limite de um minuto (60 segundos), o CodeDeploy interromperá e reprovará a implantação no evento de ciclo de vida de aplicativo AfterInstall, mesmo que sleep.sh continue a ser executado conforme o esperado. O seguinte erro é exibido:

Script at specified location: after-install.sh failed to complete in 60 seconds.

Você não pode simplesmente adicionar um E comercial (&) em after-install.sh para executar sleep.sh em segundo plano.

#!/bin/bash
# Do not do this.
/tmp/sleep.sh &

Ao fazer isso, é possível que a implantação fique em um estado pendente até o período de tempo limite do evento de ciclo de vida de implementação padrão de uma hora, após o qual o CodeDeploy interromperá e reprovará a implantação no evento de ciclo de vida de aplicativo AfterInstall, como antes.

Em after-install.sh, chame sleep.sh da seguinte maneira, o que permite que o CodeDeploy continue depois que o processo começar a ser executado:

#!/bin/bash
/tmp/sleep.sh > /dev/null 2> /dev/null < /dev/null &

Na chamada anterior, sleep.sh é o nome do processo que você deseja começar a executar em segundo plano, redirecionando stdout, stderr e stdin para /dev/null.

Solucionando problemas com um evento de ciclo de vida AllowTraffic com falha em erro relatado nos logs de implantação

Em alguns casos, uma implantação azul/verde falha durante o evento de ciclo de vida AllowTraffic, mas os logs de implantação não indicam a causa da falha.

Essa falha geralmente é devido a verificações de integridade que são configuradas incorretamente no Elastic Load Balancing para o Classic Load Balancer, Application Load Balancer ou Network Load Balancer usado para gerenciar o tráfego do grupo de implantação.

Para resolver o problema, revise e corrija quaisquer erros na configuração de verificação de integridade do load balancer.

Para Classic Load Balancers, consulte Configurar verificações de integridade no Guia do usuário para Classic Load Balancers e ConfigureHealthCheck na Referência da API do Elastic Load Balancing versão 2012-06-01.

Para Application Load Balancer, consulte Verificações de integridade de grupos de destino no Manual do usuário de Application Load Balancers.

Para Network Load Balancer, consulte Verificações de integridade de grupos de destino no Manual do usuário de Network Load Balancers.

Solução de problemas com eventos de ciclo de vida de implantação ApplicationStop, BeforeBlockTraffic e AfterBlockTraffic

Durante uma implantação, o agente do CodeDeploy executa os scripts especificados para ApplicationStop, BeforeBlockTraffic e AfterBlockTraffic no arquivo AppSpec a partir da implantação anterior bem-sucedida. (Todos os outros scripts são executados a partir do arquivo AppSpec na implantação atual.) Se um desses scripts contiver um erro e não for executado com sucesso, a implantação poderá falhar.

Os possíveis motivos dessas falhas incluem:

Use o console do CodeDeploy para investigar por que uma implantação pode ter falhado durante qualquer um desses eventos. Na página de detalhes da implantação, escolha View events (Exibir eventos). Na página de detalhes para a instância, na linha ApplicationStop, BeforeBlockTraffic ou AfterBlockTraffic, escolha View logs (Exibir logs). Ou use o AWS CLI para chamar o comando get-deployment-instance.

Se a causa da falha for um script da última implantação bem-sucedida que nunca é executado com êxito, crie uma implantação e especifique que as falhas ApplicationStop, BeforeBlockTraffic e AfterBlockTraffic devem ser ignoradas. Há duas maneiras de fazer isso:

Quando você implantar a revisão de aplicativo novamente, a implantação continuará mesmo se algum desses três eventos de ciclo de vida falhar. Se a nova revisão incluir scripts fixos para esses eventos de ciclo de vida, as implementações futuras poderão ser bem-sucedidas sem a aplicação dessa correção.

Solucionar problemas com um evento de ciclo de vida de implantação DownloadBundle com falha que indica "UnknownError: not opened for reading"

Se você estiver tentando implantar uma revisão de aplicativo a partir do Amazon S3 e essa implantação falhar durante o evento de ciclo de vida de implantação DownloadBundle com o erro UnknownError: not opened for reading:

Na página de detalhes do evento da implantação, na linha Download bundle (Fazer download do pacote), escolha View logs (Exibir logs). Ou use o AWS CLI para chamar o comando get-deployment-instance. Se esse erro tiver ocorrido, deverá haver um erro na saída com o código UnknownError e a mensagem not opened for reading.

Para determinar o motivo desse erro:

Para obter informações sobre como encontrar o arquivo de log e habilitar e desabilitar o registro em log, consulte :log_aws_wire: em Referência de configuração do agente do CodeDeploy.

Solução de problemas de erros relacionados a todos os eventos de ciclo de vida ignorados

Se todos os eventos de ciclo de vida de uma implantação do EC2 ou on-premises forem ignorados, você poderá receber um erro semelhante a The overall deployment failed because too many individual instances failed deployment, too few healthy instances are available for deployment, or some instances in your deployment group are experiencing problems. (Error code: HEALTH_CONSTRAINTS). Aqui estão algumas causas e soluções possíveis:

Os scripts do Windows PowerShell não conseguem usar a versão de 64 bits do Windows PowerShell por padrão

Se um script do Windows PowerShell executado como parte de uma implantação depender da funcionalidade de 64 bits (por exemplo, porque consome mais memória do que um aplicativo de 32 bits permite ou chama bibliotecas que são oferecidas somente em uma versão de 64 bits), o script poderá falhar ou não ser executado conforme o esperado. Isso ocorre porque, por padrão, o CodeDeploy usa a versão de 32 bits do Windows PowerShell para executar scripts do Windows PowerShell que fazem parte de uma revisão de aplicativo.

Adicione um código como o seguinte ao início de qualquer script que deve ser executado com a versão de 64 bits do Windows PowerShell:

# Are you running in 32-bit mode?
#   (\SysWOW64\ = 32-bit mode)

if ($PSHOME -like "*SysWOW64*")
{
  Write-Warning "Restarting this script under 64-bit Windows PowerShell."

  # Restart this script under 64-bit Windows PowerShell.
  #   (\SysNative\ redirects to \System32\ for 64-bit mode)

  & (Join-Path ($PSHOME -replace "SysWOW64", "SysNative") powershell.exe) -File `
    (Join-Path $PSScriptRoot $MyInvocation.MyCommand) @args

  # Exit 32-bit script.

  Exit $LastExitCode
}

# Was restart successful?
Write-Warning "Hello from $PSHOME"
Write-Warning "  (\SysWOW64\ = 32-bit mode, \System32\ = 64-bit mode)"
Write-Warning "Original arguments (if any): $args"

# Your 64-bit script code follows here...
# ...

Embora as informações de caminho de arquivo nesse código possam não parecer intuitivas, o Windows PowerShell de 32 bits usa um caminho como:

c:\Windows\SysWOW64\WindowsPowerShell\v1.0\powershell.exe

O Windows PowerShell de 64 bits usa um caminho como:

c:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe