As traduções são geradas por tradução automática. Em caso de conflito entre o conteúdo da tradução e da versão original em inglês, a versão em inglês prevalecerá.

EC2Solucionar/Problemas de implantação no local

CodeDeploy erro de credenciais CommandPoller ausentes do plugin

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 IAM instância concede ao CodeDeploy agente permissão para se comunicar CodeDeploy e baixar sua revisão do Amazon S3. Por EC2 exemplo, consulteGerenciamento 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 “Falha na validação da mensagem PKCS7 assinada”

Essa mensagem de erro indica que a instância está executando uma versão do CodeDeploy agente que suporta somente o algoritmo de hash SHA -1. O suporte para o algoritmo de hash SHA -2 foi introduzido na versão 1.0.1.854 do CodeDeploy agente, lançada em novembro de 2015. A partir de 17 de outubro de 2016, as implantações falharão se uma versão do CodeDeploy agente anterior à 1.0.1.854 for instalada. Para obter mais informações, consulte AWS para mudar para o algoritmo de SHA256 hash para SSL certificados, NOTICE: Desativação de agentes de CodeDeploy host anteriores à versão 1.0.1.85 e. Atualize o CodeDeploy agente

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 CodeDeploy tenta implantar um arquivo em uma instância, mas já existe um arquivo com o mesmo nome no local de destino especificado, a implantação nessa instância pode falhar. Você pode receber a mensagem de erro “A implantação falhou porque um arquivo especificado já existe neste local: location-name.”. Isso ocorre porque, durante cada implantaçã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 estejam listados nesse arquivo de limpeza, o CodeDeploy agente, por padrão, interpreta isso como um erro e falha na 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 se os arquivos do aplicativo já estiverem em seu ambiente de produção e você quiser implantá-los usando CodeDeploy pela primeira vez. Para ter mais informações, consulte Criar uma implantação de EC2 /On-Premises Compute Platform (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 CodeDeploy detectado nos locais de implantação de destino (ou se você não especificar nenhuma opção de implantação para lidar com o conteúdo existente em um comando programático), poderá 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 reimplantar arquivos com os mesmos nomes e locais, é mais provável que a reimplantação seja bem-sucedida se você especificar o nome do aplicativo e o grupo de implantação com o mesmo ID do grupo de implantação subjacente que você usou antes. CodeDeploy usa o ID do grupo de implantação subjacente para identificar os 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 CodeDeploy agente, você pode ativar caminhos de arquivo longos de duas maneiras, dependendo do processo de instalação do agente:

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

Se o CodeDeploy agente já tiver sido instalado:

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

Para implantações no Amazon Linux, Ubuntu Server e RHEL instâncias, se você tiver um script de implantação que inicie um processo de longa execução, CodeDeploy poderá passar muito tempo aguardando o evento do ciclo de vida da implantação e, em seguida, falhar na implantação. Isso ocorre porque, se o processo for executado por mais tempo do que se espera que os processos em primeiro e segundo plano nesse evento durem, CodeDeploy interrompam e falhem, 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 AppSpec arquivo 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 after-install.sh arquivo é executado durante o evento do ciclo de vida do AfterInstall aplicativo. 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 ligasleep.sh, sleep.sh inicia e funciona por três minutos (180 segundos), ou seja, dois minutos (120 segundos) após o tempo CodeDeploy esperado sleep.sh (e, por relação,after-install.sh) parar de funcionar. Após o tempo limite de um minuto (60 segundos), CodeDeploy interrompe e falha a implantação no evento do ciclo de vida do AfterInstall aplicativo, mesmo que sleep.sh continue funcionando 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 &

Isso pode deixar a implantação em um estado pendente por até o período padrão de tempo limite do evento do ciclo de vida da implantação de uma hora, após o qual CodeDeploy interrompe e falha a implantação no evento do ciclo de vida do AfterInstall aplicativo, como antes.

Emafter-install.sh, chame da sleep.sh seguinte forma, o que permite CodeDeploy continuar após o início da execução do processo:

#!/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.

Solução de problemas em um evento de AllowTraffic ciclo de vida com falha sem nenhum erro relatado nos registros de implantação

Em alguns casos, uma implantação azul/verde falha durante o evento do AllowTraffic ciclo de vida, mas os registros 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 Health Checks no Guia do usuário para Classic Load Balancers e ConfigureHealthCheckna versão 2012-06-01 do Elastic Load API Balancing Reference.

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 de falha ApplicationStop ou BeforeBlockTraffic evento do ciclo AfterBlockTraffic de vida da implantação

Durante uma implantação, o CodeDeploy agente executa os scripts especificados para ApplicationStop BeforeBlockTraffic, e AfterBlockTraffic no AppSpec arquivo da implantação anterior bem-sucedida. (Todos os outros scripts são executados a partir do AppSpec arquivo 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 CodeDeploy console 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 da instância, na AfterBlockTrafficlinha ApplicationStopBeforeBlockTraffic, ou, escolha Exibir registros. Ou use o AWS CLI para chamar o get-deployment-instancecomando.

Se a causa da falha for um script da última implantação bem-sucedida que nunca foi executado com êxito, crie uma implantação e especifique que as AfterBlockTraffic falhas ApplicationStop BeforeBlockTraffic, e 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.

Solução de problemas em um evento DownloadBundle de ciclo de vida de implantação com falha com UnknownError: não aberto para leitura

Se você estiver tentando implantar uma revisão do aplicativo a partir do Amazon S3 e a implantação falhar durante o evento do ciclo de vida da DownloadBundle implantação 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 get-deployment-instancecomando. 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 registro de conexões e ativar e desativar o registro de conexões, consulte :log_aws_wire: a referência de configuração do CodeDeploy agente.

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

Se todos os eventos do ciclo de vida de uma implantação local EC2 ou de uma implantação local 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:

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

Se um PowerShell script do Windows 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 pode falhar ou não ser executado conforme o esperado. Isso ocorre porque, por padrão, CodeDeploy usa a versão de 32 bits do Windows PowerShell para executar PowerShell scripts do Windows que fazem parte de uma revisão do aplicativo.

Adicione um código como o seguinte ao início de qualquer script que precise 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 do caminho do arquivo nesse código possam parecer contra-intuitivas, o Windows de 32 bits PowerShell usa um caminho como:

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

O Windows de 64 bits PowerShell usa um caminho como:

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