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á.
# Solução de problemas CodeDeploy
Use os tópicos desta seção para ajudar a resolver problemas e erros que você possa encontrar ao usar CodeDeploy.
**nota**
Você pode identificar as causas de muitas falhas de implantação por meio da revisão dos arquivos de log criados durante o processo de implantação. Para simplificar, recomendamos usar o Amazon CloudWatch Logs para monitorar centralmente os arquivos de log em vez de visualizá-los instância por instância. Para mais informações, consulte [Monitoramento de implantações com ferramentas da Amazon CloudWatch](monitoring-cloudwatch.md).
**Topics**
+ [Tópicos gerais de solução de problemas](troubleshooting-general.md)
+ [Solucionar problemas de implantação no EC2/On-Premises](troubleshooting-deployments.md)
+ [Solucionar problemas de implantação do Amazon ECS](troubleshooting-ecs.md)
+ [Solucionar problemas de implantação do AWS Lambda](troubleshooting-deployments-lambda.md)
+ [Solução de problemas de grupo de implantação](troubleshooting-deployment-groups.md)
+ [Solução de problemas de instância](troubleshooting-ec2-instances.md)
+ [Solucionar problemas de GitHub token](troubleshooting-github-token-issues.md)
+ [Solucionar problemas do Amazon EC2 Auto Scaling](troubleshooting-auto-scaling.md)
+ [Códigos de erro para o AWS CodeDeploy](error-codes.md)
# Tópicos gerais de solução de problemas
**Topics**
+ [Lista de verificação geral para solução de problemas](#troubleshooting-checklist)
+ [CodeDeploy os recursos de implantação são suportados somente em algumas AWS regiões](#troubleshooting-supported-regions)
+ [Os procedimentos deste guia não coincidem com o CodeDeploy console](#troubleshooting-old-console)
+ [Perfis do IAM necessários não estão disponíveis](#troubleshooting-iam-cloudformation)
+ [Usar alguns editores de texto para criar AppSpec arquivos e scripts de shell pode causar falhas nas implantações](#troubleshooting-text-editors)
+ [O uso do Finder no macOS para agrupar uma revisão de aplicativo pode causar falhas na implantação](#troubleshooting-bundle-with-finder)
## Lista de verificação geral para solução de problemas
Você pode usar a seguinte lista de verificação para solucionar problemas com uma implantação que falhou.
1. Consulte [Exibir detalhes CodeDeploy da implantação](deployments-view-details.md) e [Visualizar detalhes da instância com o CodeDeploy](instances-view-details.md) para determinar por que a implantação falhou. Se você não conseguir determinar a causa, examine os itens desta lista de verificação.
1. Verifique se você configurou corretamente as instâncias:
+ A instância foi iniciada com um par de chaves do EC2 especificado? Para acessar mais informações, consulte [EC2 Key Pairs](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/EC2-key-pairs.html) no *Guia do usuário do Amazon EC2*.
+ O perfil de instância do IAM correto está anexado à instância? Para obter mais informações, consulte [Configurar uma instância do Amazon EC2 para trabalhar com CodeDeploy](instances-ec2-configure.md) e [Etapa 4: criar um perfil de instância do IAM para as suas instâncias do Amazon EC2](getting-started-create-iam-instance-profile.md).
+ A instância foi marcada? Para acessar mais informações, consulte [Working with tags in the console](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/Using_Tags.html#Using_Tags_Console) no *Guia do usuário do Amazon EC2*.
+ O CodeDeploy agente está instalado, atualizado e em execução na instância? Para obter mais informações, consulte [Gerenciando as operações CodeDeploy do agente](codedeploy-agent-operations.md). Para verificar qual versão do agente está instalada, consulte [Determine a versão do CodeDeploy agente](codedeploy-agent-operations-version.md).
1. Verifique as configurações do aplicativo e do grupo de implantação:
+ Para verificar as configurações do seu aplicativo, consulte [Veja os detalhes do aplicativo com CodeDeploy](applications-view-details.md).
+ Para verificar as configurações do seu grupo de implantação, consulte [Veja os detalhes do grupo de implantação com CodeDeploy](deployment-groups-view-details.md).
1. Confirme se a revisão de aplicativo está corretamente configurada:
+ Verifique o formato do seu AppSpec arquivo. Para obter mais informações, consulte [Adicionar um arquivo de especificação do aplicativo a uma revisão do CodeDeploy](application-revisions-appspec-file.md) e [CodeDeploy AppSpec referência de arquivo](reference-appspec-file.md).
+ Verifique seu bucket ou GitHub repositório do Amazon S3 para verificar se a revisão do aplicativo está no local esperado.
+ Revise os detalhes da revisão da sua CodeDeploy inscrição para garantir que ela esteja registrada corretamente. Para mais informações, consulte [Visualize os detalhes da revisão do aplicativo com CodeDeploy](application-revisions-view-details.md).
+ Se você estiver implantando a partir do Amazon S3, verifique seu bucket do Amazon S3 para CodeDeploy verificar se recebeu permissões para baixar a revisão do aplicativo. Para obter informações sobre políticas de bucket, consulte [Pré-requisitos de implantação](deployments-create-prerequisites.md).
+ Se você estiver implantando a partir de GitHub, verifique seu GitHub repositório para verificar se foram CodeDeploy concedidas permissões para baixar a revisão do aplicativo. Para obter mais informações, consulte [Crie uma implantação com CodeDeploy](deployments-create.md) e [GitHub autenticação com aplicativos em CodeDeploy](integrations-partners-github.md#behaviors-authentication).
1. Verifique se a função de serviço está configurada corretamente. Para mais informações, consulte [Etapa 2: criar uma função de serviço para CodeDeploy](getting-started-create-service-role.md).
1. Confirme que você seguiu as etapas em [Começando com CodeDeploy](getting-started-codedeploy.md) para:
+ Provisionou um usuário com as permissões apropriadas.
+ Instale ou atualize e configure a AWS CLI.
+ Crie um perfil de instância do IAM e um perfil de serviço.
Para obter mais informações, consulte [Gerenciamento de identidade e acesso para AWS CodeDeploy](security-iam.md).
1. Confirme se você está usando a AWS CLI versão 1.6.1 ou posterior. Para verificar a versão instalada, chame **aws --version**.
Se você ainda não consegue solucionar sua implantação com falha, reveja os outros problemas neste tópico.
## CodeDeploy os recursos de implantação são suportados somente em algumas AWS regiões
Se você não vê ou não consegue acessar aplicativos, grupos de implantação, instâncias ou outros recursos de implantação a partir do console AWS CLI ou do CodeDeploy console, certifique-se de fazer referência a uma das AWS regiões listadas em [Região e endpoints](https://docs.aws.amazon.com/general/latest/gr/rande.html#codedeploy_region) em. *Referência geral da AWS*
As instâncias do EC2 e os grupos do Amazon EC2 Auto Scaling que são usados CodeDeploy em implantações devem ser lançados e criados em uma dessas regiões. AWS
Se você estiver usando o AWS CLI, execute o **aws configure** comando a partir do AWS CLI. Em seguida, você pode visualizar e definir sua AWS região padrão.
Se você estiver usando o CodeDeploy console, na barra de navegação, no seletor de regiões, escolha uma das AWS regiões compatíveis.
**Importante**
Para usar serviços na região China (Pequim) ou China (Ningxia), é necessário ter uma conta e credenciais específicas para essas regiões. As contas e credenciais de outras AWS regiões não funcionam para as regiões de Pequim e Ningxia e vice-versa.
Informações sobre alguns recursos para as regiões da China, como nomes de buckets do CodeDeploy Resource Kit e procedimentos de instalação de CodeDeploy agentes, não estão incluídas nesta edição do *Guia CodeDeploy do usuário*.
Para obter mais informações:
[CodeDeploy](http://docs.amazonaws.cn/en_us/aws/latest/userguide/codedeploy.html)em *[Primeiros passos AWS na região da China (Pequim)](http://docs.amazonaws.cn/en_us/aws/latest/userguide/introduction.html)*
*CodeDeploy Guia do usuário para as regiões da China* ([versão em inglês](http://docs.amazonaws.cn/en_us/codedeploy/latest/userguide/welcome.html) \$1 [versão em chinês](http://docs.amazonaws.cn/codedeploy/latest/userguide/welcome.html))
## Os procedimentos deste guia não coincidem com o CodeDeploy console
Os procedimentos deste guia são gravados para refletir o novo design do console. Caso você esteja usando a versão mais antiga do console, muitos dos conceitos e dos procedimentos básicos deste guia ainda são aplicáveis. Para acessar a ajuda no novo console, escolha o ícone de informações.
## Perfis do IAM necessários não estão disponíveis
Se você depende de um perfil de instância do IAM ou de uma função de serviço criada como parte de uma AWS CloudFormation pilha, se você excluir a pilha, todas as funções do IAM também serão excluídas. Talvez seja por isso que a função do IAM não é mais exibida no console do IAM e CodeDeploy não funciona mais conforme o esperado. Para corrigir esse problema, é necessário recriar manualmente o perfil do IAM excluído.
## Usar alguns editores de texto para criar AppSpec arquivos e scripts de shell pode causar falhas nas implantações
Alguns editores de texto introduzem caracteres não imprimíveis e fora de conformidade nos arquivos. Se você usar editores de texto para criar ou modificar AppSpec arquivos ou arquivos de script de shell para execução em instâncias Amazon Linux, Ubuntu Server ou RHEL, qualquer implantação que dependa desses arquivos poderá falhar. Ao CodeDeploy usar esses arquivos durante uma implantação, a presença desses caracteres pode levar a falhas na validação hard-to-troubleshoot AppSpec do arquivo e na execução do script.
No CodeDeploy console, na página de detalhes do evento da implantação, escolha **Exibir registros**. (Ou você usa o AWS CLI para chamar o [get-deployment-instance](https://docs.aws.amazon.com/cli/latest/reference/deploy/get-deployment-instance.html)comando.) Procure erros como `invalid character`, `command not found` ou `file not found`.
Para resolver este problema, recomendamos o seguinte:
+ Não use editores de texto que introduzam caracteres não imprimíveis, como retornos de carro (`^M`caracteres) em seus AppSpec arquivos e arquivos de script de shell.
+ Use editores de texto que exibam caracteres não imprimíveis, como retornos de carro em seus AppSpec arquivos e arquivos de script de shell, para que você possa encontrar e remover qualquer um que possa ser introduzido. Para ver exemplos desses tipos de editores de texto, pesquise os editores de texto que mostram retornos de carro na Internet.
+ Use editores de texto executados em instâncias do Amazon Linux, Ubuntu Server ou RHEL para criar arquivos de script de shell que são executados em instâncias do Amazon Linux, Ubuntu Server ou RHEL. Para ver exemplos desses tipos de editores de texto, pesquise os editores de script de shell Linux na Internet.
+ Se você precisa usar um editor de texto no Windows ou no macOS para criar arquivos de script de shell para execução em instâncias Amazon Linux, Ubuntu Server ou RHEL, use um programa ou utilitário que converta texto de formato Windows ou macOS no formato Unix. Para obter exemplos desses programas e utilitários, pesquise DOS para UNIX ou Mac para UNIX na Internet. Certifique-se de testar os arquivos de script de shell convertidos nos sistemas operacionais de destino.
## O uso do Finder no macOS para agrupar uma revisão de aplicativo pode causar falhas na implantação
As implantações podem falhar se você usar o aplicativo de interface gráfica do usuário (GUI) do Finder em um Mac para agrupar (zip) um AppSpec arquivo e arquivos e scripts relacionados em um arquivo de revisão do aplicativo (.zip). Isso acontece porque o Finder cria uma pasta `__MACOSX` intermediária no arquivo .zip e coloca arquivos de componentes nessa pasta. Como o CodeDeploy não consegue encontrar os arquivos de componentes, a implantação falha.
Para resolver esse problema, recomendamos que você use o comando AWS CLI to call the [push](https://docs.aws.amazon.com/cli/latest/reference/deploy/push.html), que compacta os arquivos do componente na estrutura esperada. Como alternativa, é possível usar o Terminal em vez da GUI para compactar arquivos componentes. O terminal não cria uma pasta `__MACOSX` intermediária.
# Solucionar problemas de implantação no EC2/On-Premises
**Topics**
+ [CodeDeploy erro de credenciais CommandPoller ausentes do plugin](#troubleshooting-agent-commandpoller-error)
+ [A implantação falha com a mensagem “Falha na validação da mensagem PKCS7 assinada”](#troubleshooting-deployments-agent-SHA-256)
+ [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](#troubleshooting-same-files-different-app-name)
+ [Caminhos de arquivo longos causam erros do tipo “Nenhum arquivo ou diretório”](#troubleshooting-long-file-paths)
+ [Processos de execução longa podem fazer com que as implantações falhem](#troubleshooting-long-running-processes)
+ [Solução de problemas em um evento de AllowTraffic ciclo de vida com falha sem nenhum erro relatado nos registros de implantação](#troubleshooting-deployments-allowtraffic-no-logs)
+ [Solução de problemas de falha ApplicationStop ou BeforeBlockTraffic evento do ciclo AfterBlockTraffic de vida da implantação](#troubleshooting-deployments-lifecycle-event-failures)
+ [Solução de problemas em um evento DownloadBundle de ciclo de vida de implantação com falha com UnknownError: não aberto para leitura](#troubleshooting-deployments-downloadbundle)
+ [Solução de problemas de erros relacionados a todos os eventos de ciclo de vida ignorados](#troubleshooting-skipped-lifecycle-events)
+ [PowerShell Os scripts do Windows não usam a versão de 64 bits do Windows PowerShell por padrão](#troubleshooting-deployments-powershell)
**nota**
As causas de muitas falhas de implantação podem ser identificadas por meio da revisão dos arquivos de log criados durante o processo de implantação. Para simplificar, recomendamos usar o Amazon CloudWatch Logs para monitorar centralmente os arquivos de log em vez de visualizá-los instância por instância. Para obter mais informações, consulte [Exibir CodeDeploy registros no console de CloudWatch registros](https://aws.amazon.com/blogs/devops/view-aws-codedeploy-logs-in-amazon-cloudwatch-console/).
**dica**
*Para obter um runbook que automatiza muitas tarefas de solução de problemas relacionadas às implantações EC2/locais, consulte a referência do runbook do [AWSSupport-TroubleshootCodeDeploy](https://docs.aws.amazon.com/systems-manager-automation-runbooks/latest/userguide/automation-awssupport-troubleshootcodedeploy.html)Systems Manager AWS Automation.*
## 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:
+ A instância que você está implantando não tem um perfil de instância do IAM associado a ela.
+ Seu perfil de instância do IAM não tem as permissões corretas configuradas.
Um perfil de instância do IAM concede ao CodeDeploy agente permissão para se comunicar CodeDeploy e baixar sua revisão do Amazon S3. Para instâncias do EC2, consulte [Gerenciamento de identidade e acesso para AWS CodeDeploy](security-iam.md). Para instâncias locais, consulte [Trabalhando com instâncias locais para CodeDeploy](instances-on-premises.md).
## 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. Support para o algoritmo de hash SHA-2 foi introduzido na versão 1.0.1.854 do agente, lançada em novembro de 2015. CodeDeploy 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 certificados SSL](https://aws.amazon.com/security/security-bulletins/aws-to-switch-to-sha256-hash-algorithm-for-ssl-certificates/), [AVISO: Desativação de agentes de CodeDeploy host anteriores à versão 1.0.1.85 e.](https://forums.aws.amazon.com/thread.jspa?threadID=223319) [Atualize o CodeDeploy agente](codedeploy-agent-operations-update.md)
## 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, 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.
**nota**
Nas instâncias do Amazon Linux, RHEL e Ubuntu Server, o arquivo de limpeza está localizado em `/opt/codedeploy-agent/deployment-root/deployment-instructions/`. Em instâncias do Windows Server, o local é `C:\ProgramData\Amazon\CodeDeploy\deployment-instructions\`.
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 obter mais informações, consulte [Componentes de implantação em uma plataforma de computação EC2/On-Premises (console)](deployments-create-console.md) e [Comportamento de reversão com conteúdo existente](deployments-rollback-and-redeploy.md#deployments-rollback-and-redeploy-content-options).
### 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 manter 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 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:
+ Você especificou um nome de aplicativo diferente para uma redistribuição da mesma revisão nas mesmas instâncias. A redistribuição falha porque, mesmo que o nome do grupo de implantação seja o mesmo, o uso de um nome de aplicativo diferente significa que um ID de grupo de implantação subjacente diferente está sendo usado.
+ Você excluiu e recriou um grupo de implantação para um aplicativo e depois tentou reimplantar a mesma revisão no grupo de implantação. A reimplantação falha porque, mesmo que o nome do grupo de implantação seja o mesmo, CodeDeploy faz referência a um ID de grupo de implantação subjacente diferente.
+ Você excluiu um aplicativo e um grupo de implantação em e CodeDeploy, em seguida, criou um novo aplicativo e grupo de implantação com os mesmos nomes dos que você excluiu. Depois disso, você tentou reimplantar uma revisão que havia sido implantada no grupo de implantação anterior no novo grupo de implantação com o mesmo nome. A reimplantação falha porque, embora os nomes do aplicativo e do grupo de implantação sejam os mesmos, CodeDeploy ainda fazem referência ao ID do grupo de implantação que você excluiu.
+ Você implantou uma revisão em um grupo de implantação e, em seguida, implantou a mesma revisão em outro grupo de implantação para as mesmas instâncias. A segunda implantação falha porque o CodeDeploy faz referência a um ID de grupo de implantação subjacente diferente.
+ Você implantou uma revisão em um grupo de implantação e, em seguida, implantou outra revisão em outro grupo de implantação para as mesmas instâncias. Existe pelo menos um arquivo com o mesmo nome e no mesmo local em que o segundo grupo de implantação está tentando implantar. A segunda implantação falha porque CodeDeploy não remove o arquivo existente antes do início da segunda implantação. Ambas as implantações > fazem referência a um grupo de implantação diferente. IDs
+ Você implantou uma revisão em CodeDeploy, mas há pelo menos um arquivo com o mesmo nome e no mesmo local. A implantação falha porque, por padrão, CodeDeploy não remove o arquivo existente antes do início da implantação.
Para resolver essas situações, siga um destes procedimentos:
+ Remova os arquivos das localizações e instâncias em que eles foram implantados anteriormente e, em seguida, tente de novo a implantação.
+ No AppSpec arquivo da revisão, nos eventos do ciclo de vida da BeforeInstall implantação ApplicationStop ou nos eventos do ciclo de vida da implantação, especifique um script personalizado para excluir arquivos em qualquer local que corresponda aos arquivos que sua revisão está prestes a instalar.
+ Implante ou reimplante os arquivos em localizações ou instâncias que não faziam parte de implementações anteriores.
+ Antes de excluir um aplicativo ou um grupo de implantação, implante uma revisão que contenha um AppSpec arquivo que especifique que nenhum arquivo deve ser copiado para as instâncias. Para a implantação, especifique o nome do aplicativo e o nome do grupo de implantação que usam o mesmo aplicativo subjacente e o IDs mesmo grupo de implantação daqueles que você está prestes a excluir. (Você pode usar o [get-deployment-group](https://docs.aws.amazon.com/cli/latest/reference/deploy/get-deployment-group.html)comando para recuperar o ID do grupo de implantação.) CodeDeployusa o ID e o AppSpec arquivo do grupo de implantação subjacentes para remover todos os arquivos instalados na implantação anterior bem-sucedida.
## 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](https://learn.microsoft.com/en-us/windows/win32/fileio/maximum-file-path-limitation?tabs=powershell#enable-long-paths-in-windows-10-version-1607-and-later).
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:
1. Na máquina em que você planeja instalar o CodeDeploy agente, habilite a chave de registro do `LongPathsEnabled` Windows usando este comando:
```
New-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Control\FileSystem"
-Name "LongPathsEnabled" -Value 1 -PropertyType DWORD -Force
```
1. Instale o CodeDeploy agente. Para obter mais informações, consulte [Instale o CodeDeploy agente](codedeploy-agent-operations-install.md).
Se o CodeDeploy agente já tiver sido instalado:
1. Na máquina do CodeDeploy agente, habilite a chave de registro do `LongPathsEnabled` Windows usando este comando:
```
New-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Control\FileSystem"
-Name "LongPathsEnabled" -Value 1 -PropertyType DWORD -Force
```
1. Reinicie o CodeDeploy agente para que a alteração da chave do registro entre em vigor. Para reiniciar o agente, use o seguinte comando:
```
powershell.exe -Command Restart-Service -Name codedeployagent
```
## 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, CodeDeploy pode passar muito tempo esperando pelo evento do ciclo de vida da implantação e, em seguida, falhar na 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 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` liga`sleep.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.
Em`after-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 blue/green implantação 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](https://docs.aws.amazon.com/elasticloadbalancing/latest/classic/elb-healthchecks.html) no *Guia do usuário para Classic Load Balancers* e [ConfigureHealthCheck](https://docs.aws.amazon.com/elasticloadbalancing/2012-06-01/APIReference/API_ConfigureHealthCheck.html)na versão 2012-06-01 de referência da *API Elastic Load Balancing*.
Para Application Load Balancer, consulte [Verificações de integridade de grupos de destino](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/target-group-health-checks.html) no *Manual do usuário de Application Load Balancers*.
Para Network Load Balancer, consulte [Verificações de integridade de grupos de destino](https://docs.aws.amazon.com/elasticloadbalancing/latest/network/target-group-health-checks.html) 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:
+ O CodeDeploy agente encontra o `deployment-group-id_last_successful_install` arquivo no local correto, mas o local listado no `deployment-group-id_last_successful_install` arquivo não existe.
**Em instâncias do Amazon Linux, do Ubuntu Server e do RHEL**, o arquivo deve existir em `/opt/codedeploy-agent/deployment-root/deployment-instructions`.
**Em instâncias do Windows Server**, esse arquivo deve ser armazenado na pasta `C:\ProgramData\Amazon\CodeDeploy\deployment-instructions`.
+ No local listado no `deployment-group-id_last_successful_install` arquivo, o AppSpec arquivo é inválido ou os scripts não são executados com êxito.
+ O script contém um erro que não pode ser corrigido e, portanto, nunca é executado com êxito.
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 **AfterBlockTraffic**linha **ApplicationStop**BeforeBlockTraffic****, ou, escolha **Exibir registros**. Ou use o AWS CLI para chamar o [get-deployment-instance](https://docs.aws.amazon.com/cli/latest/reference/deploy/get-deployment-instance.html)comando.
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:
+ Use o CodeDeploy console para criar uma implantação. Na página **Criar implantação**, em **Falha no evento ApplicationStop do ciclo** de vida, escolha **Não falhar na implantação em uma instância se esse evento do ciclo de vida na** instância falhar.
+ Use o AWS CLI para chamar o **[create-deployment](https://docs.aws.amazon.com/cli/latest/reference/deploy/create-deployment.html)** comando e incluir a `--ignore-application-stop-failures` opção.
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`
+ Houve um erro interno do serviço do Amazon S3. Implante novamente a revisão de aplicativo.
+ O perfil de instância do IAM na sua instância do EC2 não tem permissões para acessar a revisão de aplicativo no Amazon S3. Para obter informações sobre políticas de bucket do Amazon S3, consulte [Envie uma revisão CodeDeploy para o Amazon S3 (somente implantações EC2/locais)](application-revisions-push.md) e [Pré-requisitos de implantação](deployments-create-prerequisites.md).
+ As instâncias nas quais você implanta estão associadas a uma AWS região (por exemplo, Oeste dos EUA (Oregon)), mas o bucket do Amazon S3 que contém a revisão do aplicativo está associado a AWS outra região (por exemplo, Leste dos EUA (Norte da Virgínia)). Certifique-se de que a revisão do aplicativo esteja em um bucket do Amazon S3 associado à mesma AWS região das instâncias.
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-instance](https://docs.aws.amazon.com/cli/latest/reference/deploy/get-deployment-instance.html)comando. 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:
1. Habilite o registro em log em pelo menos uma das instâncias e depois implante novamente a revisão de aplicativo.
1. Examine o arquivo de log para encontrar o erro. Mensagens de erro comuns para esse problema incluem a frase "acesso negado".
1. Depois de examinar os arquivos de log, recomendamos que você desabilite o registro em log para reduzir o tamanho do arquivo de log e a quantidade de informações confidenciais que poderão aparecer na saída em texto sem formatação na instância no futuro.
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](https://docs.aws.amazon.com/codedeploy/latest/userguide/reference-agent-configuration.html).
## 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:
+ O CodeDeploy agente pode não estar instalado ou em execução na instância. Para determinar se o CodeDeploy agente está em execução:
+ Para um servidor Amazon Linux RHEL ou Ubuntu, execute o seguinte:
```
systemctl status codedeploy-agent
```
+ Para o Windows, execute o seguinte:
```
powershell.exe -Command Get-Service -Name CodeDeployagent
```
Se o CodeDeploy agente não estiver instalado ou em execução, consulte[Verifique se o CodeDeploy agente está em execução](codedeploy-agent-operations-verify.md).
Talvez sua instância não consiga acessar o endpoint público CodeDeploy ou o Amazon S3 usando a porta 443. Faça uma das coisas a seguir:
+ Atribua um endereço IP público à instância e use a respectiva tabela de rotas para permitir o acesso à Internet. Verifique se o grupo de segurança associado à instância permite o acesso de saída pela porta 443 (HTTPS). Para obter mais informações, consulte [Protocolo de comunicação e porta para o CodeDeploy agente](codedeploy-agent.md#codedeploy-agent-outbound-port).
+ Se uma instância for provisionada em uma sub-rede privada, use um gateway NAT em vez de um gateway da Internet na tabela de rotas. Para obter mais informações, consulte [Gateways NAT](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-nat-gateway.html).
+ A função de serviço de CodeDeploy pode não ter as permissões necessárias. Para configurar uma função de serviço do CodeDeploy, consulte [Etapa 2: criar uma função de serviço para CodeDeploy](getting-started-create-service-role.md).
+ Se você usa um proxy HTTP, verifique se ele está especificado na `:proxy_uri:` configuração do arquivo de configuração do CodeDeploy agente. Para obter mais informações, consulte [Referência de configuração do agente do CodeDeploy](reference-agent-configuration.md).
+ A assinatura de data e hora da sua instância de implantação pode não corresponder à assinatura de data e hora da sua solicitação de implantação. Procure um erro semelhante ao `Cannot reach InstanceService: Aws::CodeDeployCommand::Errors::InvalidSignatureException - Signature expired` do seu arquivo de log do CodeDeploy agente. Se você vir esse erro, siga as etapas em [Solução de problemas de erros de implantação “InvalidSignatureException — Assinatura expirada: [hora] agora é anterior a [hora]”](troubleshooting-ec2-instances.md#troubleshooting-instance-time-failures). Para obter mais informações, consulte [Exibir dados de log para implantações CodeDeploy EC2/locais](deployments-view-logs.md).
+ O CodeDeploy agente pode parar de ser executado porque a instância está com pouca memória ou espaço no disco rígido. Tente reduzir o número de implantações arquivadas na sua instância atualizando a `max_revisions` configuração na configuração do CodeDeploy agente. Se você fizer isso para uma instância do EC2 e o problema persistir, considere o uso de uma instância maior. Por exemplo, se o tipo de instância for `t2.small`, tente usar `t2.medium`. Para obter mais informações, consulte [Arquivos instalados pelo CodeDeploy agente](codedeploy-agent.md#codedeploy-agent-install-files), [Referência de configuração do agente do CodeDeploy](reference-agent-configuration.md) e [Tipos de instância](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/instance-types.html).
+ A instância na qual você está fazendo a implantação pode não ter um perfil de instância do IAM anexado, ou pode ter um perfil de instância do IAM anexado que não tenha as permissões necessárias.
+ Se não houver um perfil de instância do IAM anexado à sua instância, crie um com as permissões necessárias e anexe-o.
+ Se já houver um perfil de instância do IAM anexado à sua instância, verifique se ele tem as permissões necessárias.
Depois de confirmar que o perfil de instância anexado está configurado com as permissões necessárias, reinicie a instância. Para obter mais informações, consulte [Etapa 4: criar um perfil de instância do IAM para as suas instâncias do Amazon EC2](getting-started-create-iam-instance-profile.md) e [Perfis do IAM para o Amazon EC2](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/iam-roles-for-amazon-EC2.html) no *Guia do usuário do Amazon EC2*.
## 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`
# Solucionar problemas de implantação do Amazon ECS
**Topics**
+ [Ocorre um tempo limite enquanto se aguarda o conjunto de tarefas de substituição](#troubleshooting-ecs-timeout)
+ [Ocorre um limite de tempo enquanto se aguarda a continuação de uma notificação](#troubleshooting-ecs-timeout-notif)
+ [O perfil do IAM não tem permissões suficientes](#troubleshooting-ecs-iam)
+ [A implantação atingiu o tempo limite enquanto aguardava um retorno de chamada de status](#troubleshooting-ecs-timeout-callback)
+ [A implantação falhou porque uma ou mais funções de validação de evento do ciclo de vida falharam](#troubleshooting-ecs-lifecycle)
+ [Não foi possível atualizar o ELB devido ao seguinte erro: o grupo de destino do conjunto de tarefas primário deve estar atrás do receptor](#troubleshooting-ecs-elb)
+ [Às vezes, minha implantação falha ao usar o ajuste de escala automático](#troubleshooting-ecs-auto-scaling)
+ [Somente o ALB oferece suporte ao roteamento gradual de tráfego; em vez disso, use o roteamento de AllAtOnce tráfego quando você estiver no grupo de implantação create/update](#troubleshooting-ecs-lb)
+ [Embora minha implantação tenha sido bem-sucedida, o conjunto de tarefas de substituição falha nas verificações de integridade do Elastic Load Balancing, e meu aplicativo está inativo](#troubleshooting-ecs-task-set-stability)
+ [Posso conectar vários balanceadores de carga a um grupo de implantação?](#troubleshooting-ecs-lb-multi)
+ [Posso realizar implantações em CodeDeploy azul/verde sem um balanceador de carga?](#troubleshooting-ecs-lb-bg)
+ [Como posso atualizar meu serviço Amazon ECS com novas informações durante uma implantação?](#troubleshooting-ecs-exec)
## Ocorre um tempo limite enquanto se aguarda o conjunto de tarefas de substituição
**Problema**: Você vê a seguinte mensagem de erro ao implantar seu aplicativo Amazon ECS usando: CodeDeploy
`The deployment timed out while waiting for the replacement task set to become healthy. This time out period is 60 minutes.`
**Possível causa**: esse erro pode ocorrer se houver um erro no arquivo de definição de tarefas ou em outros arquivos relacionados à implantação. Por exemplo, se houver um erro de digitação no campo `image` do seu arquivo de definição de tarefa, o Amazon ECS tentará extrair a imagem errada do contêiner e falhará continuamente, causando esse erro.
**Possíveis correções e próximas etapas**:
+ Corrija erros tipográficos e problemas de configuração no arquivo de definição de tarefas e em outros arquivos.
+ Confira o evento relacionado ao serviço Amazon ECS e descubra por que as tarefas de substituição não estão ficando íntegras. Para mais informações sobre eventos do Amazon ECS, consulte [Eventos do Amazon ECS](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/ecs_cwe_events.html) no *Guia do desenvolvedor do Amazon Elastic Container Service*.
+ Consulte a seção de [Solução de problemas do Amazon ECS](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/troubleshooting.html) no *Guia do desenvolvedor do Amazon Elastic Container Service* para ver se há erros relacionados às mensagens do evento.
## Ocorre um limite de tempo enquanto se aguarda a continuação de uma notificação
**Problema**: Você vê a seguinte mensagem de erro ao implantar seu aplicativo Amazon ECS usando: CodeDeploy
`The deployment timed out while waiting for a notification to continue. This time out period is n minutes.`
**Possível causa**: esse erro pode ocorrer se você especificou um tempo de espera no campo **Especificar quando redirecionar o tráfego** ao criar seu grupo de implantação, mas a implantação não pôde ser concluída antes que o tempo de espera expirasse.
**Possíveis correções e próximas etapas**:
+ Em seu grupo de implantação, defina **Especificar quando redirecionar o tráfego** para um período maior e reimplante. Para obter mais informações, consulte [Criar um grupo de implantação para uma implantação do Amazon ECS (console)](deployment-groups-create-ecs.md).
+ Em seu grupo de implantação, altere **Especificar quando redirecionar o tráfego** para **Redirecionar o tráfego imediatamente** e reimplante. Para obter mais informações, consulte [Criar um grupo de implantação para uma implantação do Amazon ECS (console)](deployment-groups-create-ecs.md).
+ Reimplante e, em seguida, execute o [https://docs.aws.amazon.com/cli/latest/reference/deploy/continue-deployment.html](https://docs.aws.amazon.com/cli/latest/reference/deploy/continue-deployment.html) AWS CLI comando com a `--deployment-wait-type` opção definida como. `READY_WAIT` Certifique-se de executar esse comando *antes* que o horário especificado em **Especificar quando redirecionar o tráfego** expire.
## O perfil do IAM não tem permissões suficientes
**Problema**: Você vê a seguinte mensagem de erro ao implantar seu aplicativo Amazon ECS usando: CodeDeploy
`The IAM role role-arn does not give you permission to perform operations in the following AWS service: AWSLambda.`
**Possível causa**: Esse erro pode ocorrer se você especificou uma função Lambda na [`Hooks`seção do AppSpec arquivo](reference-appspec-file-structure-hooks.md#appspec-hooks-ecs), mas não deu CodeDeploy permissão ao serviço Lambda.
**Possível correção**: adicione a `lambda:InvokeFunction` permissão à função CodeDeploy de serviço. Para adicionar essa permissão, adicione uma das seguintes políticas gerenciadas pela AWS ao perfil: **AWSCodeDeployRoleForECS** ou **AWSCodeDeployRoleForECSLimited**. Para obter informações sobre essas políticas e como adicioná-las à função CodeDeploy de serviço, consulte[Etapa 2: criar uma função de serviço para CodeDeploy](getting-started-create-service-role.md).
## A implantação atingiu o tempo limite enquanto aguardava um retorno de chamada de status
**Problema**: Você vê a seguinte mensagem de erro ao implantar seu aplicativo Amazon ECS usando: CodeDeploy
`The deployment timed out while waiting for a status callback. CodeDeploy expects a status callback within one hour after a deployment hook is invoked.`
**Possível causa**: esse erro pode ocorrer se você especificar uma função Lambda na [`Hooks`seção do AppSpec arquivo](reference-appspec-file-structure-hooks.md#appspec-hooks-ecs), mas a função Lambda não conseguiu chamar a `PutLifecycleEventHookExecutionStatus` API necessária para retornar um `Succeeded` status ou para. `Failed` CodeDeploy
**Possíveis correções e próximas etapas**:
+ Adicione a `codedeploy:putlifecycleEventHookExecutionStatus` permissão à função de execução do Lambda usada pela função Lambda que você especificou no arquivo. AppSpec Essa permissão concede à função Lambda a capacidade de retornar um status de `Succeeded` ou `Failed` para. CodeDeploy Para obter informações sobre funções de execução do Lambda, consulte [Função de execução do Lambda](https://docs.aws.amazon.com/lambda/latest/dg/lambda-intro-execution-role.html) no *Guia do usuário do AWS Lambda *.
+ Verifique o código da função Lambda e os registros de execução para garantir que sua função Lambda esteja chamando a `PutLifecycleEventHookExecutionStatus` API CodeDeploy do Lambda para informar se o teste de validação do ciclo CodeDeploy de vida é ou não. `Succeeded` `Failed` Para obter informações sobre a `putlifecycleEventHookExecutionStatus` API, consulte [PutLifecycleEventHookExecutionStatus](https://docs.aws.amazon.com/codedeploy/latest/APIReference/API_PutLifecycleEventHookExecutionStatus.html)a *Referência AWS CodeDeploy da API*. Para obter informações sobre os registros de execução do Lambda, consulte Acessando os [ CloudWatch registros da Amazon](https://docs.aws.amazon.com/lambda/latest/dg/monitoring-cloudwatchlogs.html) para. AWS Lambda
## A implantação falhou porque uma ou mais funções de validação de evento do ciclo de vida falharam
**Problema**: Você vê a seguinte mensagem de erro ao implantar seu aplicativo Amazon ECS usando: CodeDeploy
`The deployment failed because one or more of the lifecycle event validation functions failed.`
**Possível causa**: esse erro pode ocorrer se você especificou uma função Lambda na [`Hooks`seção do AppSpec arquivo](reference-appspec-file-structure-hooks.md#appspec-hooks-ecs), mas a função Lambda retornou `Failed` quando foi chamada. CodeDeploy `PutLifecycleEventHookExecutionStatus` Essa falha indica CodeDeploy que o teste de validação do ciclo de vida falhou.
**Próxima etapa possível**: verifique seus logs de execução do Lambda para ver por que o código do teste de validação está falhando. Para obter informações sobre os registros de execução do Lambda, consulte Acessando os [ CloudWatch registros da Amazon](https://docs.aws.amazon.com/lambda/latest/dg/monitoring-cloudwatchlogs.html) para. AWS Lambda
## Não foi possível atualizar o ELB devido ao seguinte erro: o grupo de destino do conjunto de tarefas primário deve estar atrás do receptor
**Problema**: Você vê a seguinte mensagem de erro ao implantar seu aplicativo Amazon ECS usando: CodeDeploy
`The ELB could not be updated due to the following error: Primary taskset target group must be behind listener`
**Possível causa**: esse erro pode ocorrer se você tiver configurado um receptor de teste opcional, e ele estiver configurado com o grupo de destino errado. Para obter mais informações sobre o ouvinte de teste em CodeDeploy, consulte [Antes de começar uma implantação do](deployment-steps-ecs.md#deployment-steps-prerequisites-ecs) e. [O que acontece durante uma implantação do](deployment-steps-ecs.md#deployment-steps-what-happens) Para obter mais informações sobre conjuntos de tarefas, consulte [TaskSet](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_TaskSet.html)na *Referência de API do Amazon Elastic Container Service* e [describe-task-set](https://docs.aws.amazon.com/cli/latest/reference/ecs/describe-task-set.html)na seção Amazon ECS da *Referência de AWS CLI Comandos*.
**Possível correção**: certifique-se de que o receptor de produção e o receptor de teste do Elastic Load Balancing estejam apontando para o grupo de destino que atualmente atende aos seus workloads. Há três lugares para verificar:
+ No Amazon EC2, nas configurações de **Receptores e regras** do seu balanceador de carga. Para obter mais informações, consulte [Receptores para o seu Application Load Balancer](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/load-balancer-listeners.html), no *Guia do usuário do Application Load Balancers*, e [Receptores para o seu Network Load Balancer](https://docs.aws.amazon.com/elasticloadbalancing/latest/network/load-balancer-listeners.html) ,no *Guia do usuário do Network Load Balancer*.
+ No Amazon ECS, no seu cluster, na configuração de **Rede** do seu serviço. Para obter mais informações, consulte as considerações sobre o [Application Load Balancer e o Network Load Balancer](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/load-balancer-types.html#alb-considerations) no *Guia do Desenvolvedor do Amazon Elastic Container Service*.
+ Em CodeDeploy, nas configurações do seu grupo de implantação. Para obter mais informações, consulte [Criar um grupo de implantação para uma implantação do Amazon ECS (console)](deployment-groups-create-ecs.md).
## Às vezes, minha implantação falha ao usar o ajuste de escala automático
**Problema**: Você está usando o Auto Scaling com CodeDeploy e percebe que suas implantações ocasionalmente falham. Para obter mais informações sobre os sintomas desse problema, consulte o tópico que diz: [Para serviços configurados para usar escalabilidade automática de serviço e o tipo de blue/green implantação, a escalabilidade automática não é bloqueada durante uma implantação, mas a implantação pode falhar em algumas circunstâncias](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/deployment-type-bluegreen.html#deployment-type-bluegreen-considerations) no *Amazon Elastic Container Service Developer* Guide.
**Possível causa**: Esse problema pode ocorrer se CodeDeploy os processos do Auto Scaling entrarem em conflito.
**Possível correção**: suspender e retomar os processos do Auto Scaling durante CodeDeploy a implantação usando `RegisterScalableTarget` a API (ou o comando `register-scalable-target` AWS CLI correspondente). Para obter mais informações, consulte [Suspender e retomar o ajuste de escala do ajuste de escala automático do aplicativo](https://docs.aws.amazon.com/autoscaling/application/userguide/application-auto-scaling-suspend-resume-scaling.html) no *Guia do usuário do ajuste de escala automático do aplicativo*.
**nota**
CodeDeploy não consigo ligar `RegisterScaleableTarget` diretamente. Para usar essa API, você deve configurar CodeDeploy para enviar uma notificação ou evento para o Amazon Simple Notification Service (ou Amazon CloudWatch). Em seguida, você deve configurar o Amazon SNS (ou CloudWatch) para chamar uma função Lambda e configurar a função Lambda para chamar a API. `RegisterScalableTarget` A API `RegisterScalableTarget` deve ser chamada com o parâmetro `SuspendedState` definido como `true`, para suspender as operações de ajuste de escala automático, e como `false`, para retomá-las.
A notificação ou evento CodeDeploy enviado deve ocorrer quando uma implantação é iniciada (para acionar as operações de suspensão do Auto Scaling) ou quando uma implantação é bem-sucedida, falha ou é interrompida (para acionar a retomada das operações do Auto Scaling).
Para obter informações sobre como configurar CodeDeploy para gerar notificações ou CloudWatch eventos do Amazon SNS, consulte[Monitoramento de implantações com Amazon Events CloudWatch](monitoring-cloudwatch-events.md). e. [Monitoramento de implantações com notificações de eventos do Amazon SNS](monitoring-sns-event-notifications.md)
## Somente o ALB oferece suporte ao roteamento gradual de tráfego; em vez disso, use o roteamento de AllAtOnce tráfego quando você estiver no grupo de implantação create/update
**Problema**: Você vê a seguinte mensagem de erro ao criar ou atualizar um grupo de implantação em CodeDeploy:
`Only ALB supports gradual traffic routing, use AllAtOnce Traffic routing instead when you create/update Deployment group.`
**Possível causa**: esse erro pode ocorrer se você estiver usando um Network Load Balancer e tentar usar uma configuração de implantação predefinida diferente de `CodeDeployDefault.ECSAllAtOnce`.
**Correções possíveis:**
+ Altere sua configuração de implantação predefinida para `CodeDeployDefault.ECSAllAtOnce`. Essa é a única configuração de implantação predefinida permitida pelo Network Load Balancers.
Para obter mais informações sobre configurações de implantação pré-definidas, consulte [Configurações de implantação predefinidas para uma plataforma de computação do Amazon ECS](deployment-configurations.md#deployment-configurations-predefined-ecs).
+ Mude seu balanceador de carga para um Application Load Balancer. O Application Load Balancer é compatível com todas as configurações de implantação predefinidas. Para obter mais informações sobre como criar um Application Load Balancer, consulte [Configure um balanceador de carga, grupos-alvo e ouvintes para implantações do CodeDeploy Amazon ECS](deployment-groups-create-load-balancer-for-ecs.md).
## Embora minha implantação tenha sido bem-sucedida, o conjunto de tarefas de substituição falha nas verificações de integridade do Elastic Load Balancing, e meu aplicativo está inativo
**Problema**: Embora CodeDeploy indique que minha implantação foi bem-sucedida, o conjunto de tarefas de substituição falha nas verificações de saúde do Elastic Load Balancing e meu aplicativo está inativo.
**Possível causa**: Esse problema pode ocorrer se você executou uma CodeDeploy all-at-once implantação e seu conjunto de tarefas de substituição (verde) contém um código incorreto que está causando a falha nas verificações de integridade do Elastic Load Balancing. Com a configuração de all-at-once implantação, as verificações de integridade do balanceador de carga começam a ser executadas no conjunto de tarefas de substituição *depois* que o tráfego é transferido para ele (ou seja, *após a ocorrência CodeDeploy do evento* do `AllowTraffic` ciclo de vida). É por isso que você verá as verificações de integridade falharem no conjunto de tarefas de substituição após a mudança de tráfego, mas não antes. Para obter informações sobre os eventos do ciclo de vida que são CodeDeploy gerados, consulte. [O que acontece durante uma implantação do](deployment-steps-ecs.md#deployment-steps-what-happens)
**Correções possíveis:**
+ Altere sua configuração de implantação all-at-once de canária ou linear. *Em uma configuração linear ou canária, as verificações de integridade do balanceador de carga começam a ser executadas no conjunto de tarefas de substituição durante a CodeDeploy instalação do aplicativo no ambiente de substituição e *antes* do deslocamento do tráfego (ou seja, durante o evento do `Install` ciclo de vida e antes do evento).* `AllowTraffic` Ao permitir que as verificações sejam executadas durante a instalação do aplicativo, mas antes que o tráfego seja transferido, um código incorreto do aplicativo será detectado e causará falhas na implantação antes que o aplicativo se torne disponível publicamente.
Para obter informações sobre como configurar implantações canário ou lineares, consulte [Altere as configurações do grupo de implantação com CodeDeploy](deployment-groups-edit.md).
Para obter informações sobre eventos de CodeDeploy ciclo de vida que são executados durante uma implantação do Amazon ECS, consulte. [O que acontece durante uma implantação do](deployment-steps-ecs.md#deployment-steps-what-happens)
**nota**
As configurações de implantação canário e linear são compatíveis somente com Application Load Balancers.
+ Se você quiser manter sua configuração de all-at-once implantação, configure um ouvinte de teste e verifique o status de integridade do conjunto de tarefas de substituição com o gancho de `BeforeAllowTraffic` ciclo de vida. Para obter mais informações, consulte [Lista de hooks do evento do ciclo de vida para uma implantação Amazon ECS](reference-appspec-file-structure-hooks.md#reference-appspec-file-structure-hooks-list-ecs).
## Posso conectar vários balanceadores de carga a um grupo de implantação?
Não. Se você quiser usar vários Application Load Balancers ou Network Load Balancers, use as atualizações contínuas do Amazon ECS em vez de CodeDeploy implantações azul/verdes. Para obter mais informações sobre as atualizações contínuas, consulte [Atualização contínua](https://docs.aws.amazon.com/AmazonECS/latest/userguide/deployment-type-ecs.html) no *Guia do desenvolvedor do Amazon Elastic Container Service*. Para obter mais informações sobre o uso de vários balanceadores de carga com o Amazon ECS, consulte [Registrar vários grupos de destino com um serviço](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/register-multiple-targetgroups.html) no *Guia do desenvolvedor do Amazon Elastic Container Service*.
## Posso realizar implantações em CodeDeploy azul/verde sem um balanceador de carga?
Não, você não pode realizar implantações em CodeDeploy azul/verde sem um balanceador de carga. Se você não conseguir usar um balanceador de carga, use o atributo de atualizações contínuas do Amazon ECS. Para obter mais informações sobre as atualizações contínuas do Amazon ECS, consulte [Atualização contínua](https://docs.aws.amazon.com/AmazonECS/latest/userguide/deployment-type-ecs.html) no *Guia do desenvolvedor do Amazon Elastic Container Service*.
## Como posso atualizar meu serviço Amazon ECS com novas informações durante uma implantação?
Para CodeDeploy atualizar seu serviço Amazon ECS com um novo parâmetro enquanto ele conduz uma implantação, especifique o parâmetro na `resources` seção do AppSpec arquivo. Somente alguns parâmetros do Amazon ECS são compatíveis CodeDeploy, como o arquivo de definição da tarefa e os parâmetros do nome do contêiner. Para obter uma lista completa dos parâmetros do Amazon ECS que CodeDeploy podem ser atualizados, consulte[AppSpec seção 'recursos' para implantações do Amazon ECS](reference-appspec-file-structure-resources.md#reference-appspec-file-structure-resources-ecs).
**nota**
Se você precisar atualizar seu serviço Amazon ECS com um parâmetro que não é suportado pelo CodeDeploy, conclua estas tarefas:
Chame a API `UpdateService` do Amazon ECS com o parâmetro que você deseja atualizar. Para obter uma lista completa dos parâmetros que podem ser atualizados, consulte [UpdateService](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_UpdateService.html)a *Amazon Elastic Container Service API Reference*.
Para aplicar a alteração às tarefas, crie uma nova blue/green implantação do Amazon ECS. Para obter mais informações, consulte [Criar uma implantação da plataforma de computação do Amazon ECS (console)](deployments-create-console-ecs.md).
# Solucionar problemas de implantação do AWS Lambda
**Topics**
+ [AWS Lambda as implantações falham após interromper manualmente uma implantação do Lambda que não tem reversões configuradas](#troubleshooting-manually-stopped-lambda-deployment)
## AWS Lambda as implantações falham após interromper manualmente uma implantação do Lambda que não tem reversões configuradas
Em alguns casos, o alias da função do Lambda especificada em uma implantação pode fazer referência a duas versões diferentes da função. O resultado é que as tentativas subsequentes de implantar a função do Lambda falham. A implantação do Lambda pode chegar a esse estado quando não há reversões configuradas e ela for interrompida manualmente. Para continuar, use o AWS Lambda console para garantir que a função não esteja configurada para mudar o tráfego entre duas versões:
1. Faça login no Console de gerenciamento da AWS e abra o AWS Lambda console em [https://console.aws.amazon.com/lambda/](https://console.aws.amazon.com/lambda/).
1. No painel esquerdo, escolha **Functions (Funções)**.
1. Selecione o nome da função Lambda que está em sua CodeDeploy implantação.
1. **Em Aliases****, escolha o alias usado em sua CodeDeploy implantação e, em seguida, escolha Editar.**
1. Em **Alias ponderado**, escolha **none**. Isso garante que o alias não esteja configurado para deslocar uma porcentagem, ou peso, do tráfego para mais de uma versão. Anote a versão selecionada em **Version (Versão)**.
1. Escolha **Salvar**.
1. Abra o CodeDeploy console e tente implantar a versão exibida no menu suspenso na etapa 5.
# Solução de problemas de grupo de implantação
## Marcar uma instância como parte de um grupo de implantação não implanta automaticamente seu aplicativo na nova instância
CodeDeploy não implanta automaticamente seu aplicativo em uma instância recém-marcada. Você deve criar uma nova implantação no grupo de implantação.
Você pode usar CodeDeploy para habilitar implantações automáticas em novas instâncias do EC2 nos grupos do Amazon EC2 Auto Scaling. Para obter mais informações, consulte [Integração CodeDeploy com o Amazon EC2 Auto Scaling](integrations-aws-auto-scaling.md).
# Solução de problemas de instância
**Topics**
+ [As tags devem ser definidas corretamente](#troubleshooting-EC2-tags)
+ [AWS CodeDeploy o agente deve estar instalado e em execução nas instâncias](#troubleshooting-sds-agent)
+ [As implantações não falham por até uma hora quando uma instância é encerrada durante uma implantação](#troubleshooting-one-hour-timeout)
+ [Analisando arquivos de log para investigar falhas de implantação em instâncias](#troubleshooting-deploy-failures)
+ [Crie um novo arquivo de CodeDeploy log se ele tiver sido excluído acidentalmente](#troubleshooting-create-new-log-file)
+ [Solução de problemas de erros de implantação “InvalidSignatureException — Assinatura expirada: [hora] agora é anterior a [hora]”](#troubleshooting-instance-time-failures)
## As tags devem ser definidas corretamente
Use o comando [list-deployment-instances](https://docs.aws.amazon.com/cli/latest/reference/deploy/list-deployment-instances.html) para confirmar que as instâncias usadas para uma implantação estão marcadas corretamente. Se uma instância do EC2 estiver ausente na saída, use o console do EC2 para confirmar que as tags foram definidas nessa instância. Para acessar mais informações, consulte [Working with tags in the console](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/Using_Tags.html#Using_Tags_Console) no *Guia do usuário do Amazon EC2*.
**nota**
Se você marcar uma instância e usá-la imediatamente CodeDeploy para implantar um aplicativo nela, a instância pode não ser incluída na implantação. Isso ocorre porque pode levar alguns minutos até que CodeDeploy você possa ler as tags. Recomendamos que você aguarde pelo menos cinco minutos entre o momento de marcar uma instância e a tentativa de implantar nela.
## AWS CodeDeploy o agente deve estar instalado e em execução nas instâncias
Para verificar se o CodeDeploy agente está instalado e em execução em uma instância, consulte[Verifique se o CodeDeploy agente está em execução](codedeploy-agent-operations-verify.md).
Para instalar, desinstalar ou reinstalar o CodeDeploy agente, consulte[Instale o CodeDeploy agente](codedeploy-agent-operations-install.md).
## As implantações não falham por até uma hora quando uma instância é encerrada durante uma implantação
CodeDeploy fornece uma janela de uma hora para que cada evento do ciclo de vida da implantação seja executado até a conclusão. Isso fornece tempo suficiente para scripts de execução longa.
Se os scripts não forem executados até a conclusão enquanto um evento de ciclo de vida estiver em andamento (por exemplo, se uma instância for encerrada ou o CodeDeploy agente for desligado), pode levar até uma hora para que o status da implantação seja exibido como Falha. Isso é verdade mesmo que o período de tempo limite especificado no script seja menor que uma hora. Isso ocorre porque, quando a instância é encerrada, o CodeDeploy agente é encerrado e não consegue processar mais scripts.
Porém, se uma instância for encerrada entre eventos de ciclo de vida ou antes do início da primeira etapa do evento de ciclo de vida, o tempo limite ocorrerá depois de apenas cinco minutos.
## Analisando arquivos de log para investigar falhas de implantação em instâncias
Se o status de uma instância na implantação for algo diferente de `Succeeded`, você poderá analisar os dados do arquivo de log de implantação para ajudar a identificar o problema. Para obter informações sobre como acessar dados do log de implantação, consulte [Exibir dados de log para implantações CodeDeploy EC2/locais](deployments-view-logs.md).
## Crie um novo arquivo de CodeDeploy log se ele tiver sido excluído acidentalmente
Se você excluir acidentalmente o arquivo de log de implantação em uma instância, CodeDeploy não cria um arquivo de log substituto. Para criar um novo arquivo de log, faça login na instância e depois execute estes comandos:
**Para uma instância do Amazon Linux, Ubuntu Server ou RHEL**, execute estes comandos nesta ordem, um de cada vez:
```
systemctl stop codedeploy-agent
```
```
systemctl start codedeploy-agent
```
**Para uma instância do Windows Server**:
```
powershell.exe -Command Restart-Service -Name codedeployagent
```
## Solução de problemas de erros de implantação “InvalidSignatureException — Assinatura expirada: [hora] agora é anterior a [hora]”
CodeDeploy requer referências temporais precisas para realizar suas operações. Se a data e a hora da sua instância não estiverem definidas corretamente, elas podem não corresponder à data de assinatura da sua solicitação de implantação, que é CodeDeploy rejeitada.
Para evitar falhas de implantação relacionadas a configurações de tempo incorretas, consulte os seguintes tópicos:
+ [Definição da hora de sua instância do Linux](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/set-time.html)
+ [Definição de horário para uma instância do Windows](https://docs.aws.amazon.com/AWSEC2/latest/WindowsGuide/windows-set-time.html)
# Solucionar problemas de GitHub token
## Token inválido GitHub OAuth
CodeDeploy os aplicativos criados após junho de 2017 usam GitHub OAuth tokens para cada AWS região. O uso de tokens vinculados a AWS regiões específicas oferece mais controle sobre quais CodeDeploy aplicativos têm acesso a um GitHub repositório.
Se você receber um erro de GitHub token, talvez tenha um token antigo que agora é inválido.
**Para corrigir um token inválido GitHub OAuth **
1. Remova o token antigo usando um dos seguintes métodos:
+ Para remover o token antigo usando a API, use [ DeleteGitHubAccountToken](https://docs.aws.amazon.com/codedeploy/latest/APIReference/API_DeleteGitHubAccountToken.html).
+ Para remover o token antigo usando o AWS Command Line Interface:
1. Vá para o computador em que o token reside.
1. Verifique se o AWS CLI está instalado neste computador. Para obter instruções de instalação, consulte [Instalação, atualização e desinstalação da AWS CLI](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-install.html) no *Guia do usuário AWS Command Line Interface *.
1. Digite o seguinte comando no computador em que o token reside:
**aws delete-git-hub-account-token**
Para obter detalhes sobre a sintaxe do comando, consulte [delete-git-hub-account-token](https://docs.aws.amazon.com/cli/latest/reference/deploy/delete-git-hub-account-token.html).
1. Adicione um novo OAuth token. Para obter mais informações, consulte [Integrando com CodeDeploy GitHub](integrations-partners-github.md).
## Número máximo de GitHub OAuth tokens excedido
Quando você cria uma CodeDeploy implantação, o número máximo de GitHub tokens permitidos é 10. Se você receber um erro sobre GitHub OAuth tokens, verifique se você tem 10 ou menos tokens. Se você tiver mais de 10 tokens, os primeiros tokens que foram criados serão considerados inválidos. Por exemplo, se você tiver 11 tokens, o primeiro token criado será inválido. Se tiver 12 tokens, os dois primeiros tokens que você criou serão inválidos. Para obter informações sobre como usar a CodeDeploy API para remover tokens antigos, consulte [ DeleteGitHubAccountToken](https://docs.aws.amazon.com/codedeploy/latest/APIReference/API_DeleteGitHubAccountToken.html).
# Solucionar problemas do Amazon EC2 Auto Scaling
**Topics**
+ [Solução de problemas gerais do Amazon EC2 Auto Scaling](#troubleshooting-auto-scaling-general)
+ [“CodeDeployRole não lhe dá permissão para realizar operações no seguinte AWS serviço: AmazonAutoScaling" erro](#troubleshooting-auto-scaling-permissions-error)
+ [As instâncias em um grupo de Amazon EC2 Auto Scaling são continuamente provisionadas e encerradas antes que uma revisão possa ser implantada](#troubleshooting-auto-scaling-provision-termination-loop)
+ [O encerramento ou a reinicialização de uma instância do Amazon EC2 Auto Scaling pode causar falhas nas implantações](#troubleshooting-auto-scaling-reboot)
+ [Evite associar vários grupos de implantação a um único grupo de Amazon EC2 Auto Scaling](#troubleshooting-multiple-depgroups)
+ [As instâncias do EC2 em um grupo Amazon EC2 Auto Scaling falham ao ser iniciadas e recebem o erro "Heartbeat Timeout"](#troubleshooting-auto-scaling-heartbeat)
+ [Ganchos do ciclo de vida do Amazon EC2 Auto Scaling podem fazer com que as implantações automáticas em grupos do Amazon EC2 Auto Scaling parem ou falhem.](#troubleshooting-auto-scaling-hooks)
+ [Erro “A implantação falhou porque nenhuma instância foi encontrada para seu grupo de implantação”](#troubleshooting-deployment-failed-because-no-instances-found)
## Solução de problemas gerais do Amazon EC2 Auto Scaling
Implantações em instâncias do EC2 em um grupo de Amazon EC2 Auto Scaling podem falhar pelos seguintes motivos:
+ **O Amazon EC2 Auto Scaling inicia e termina continuamente instâncias do EC2.** Se CodeDeploy não puder implantar automaticamente a revisão do seu aplicativo, o Amazon EC2 Auto Scaling inicia e encerra continuamente as instâncias do EC2.
Desassocie o grupo Amazon EC2 Auto Scaling do grupo de implantação ou altere CodeDeploy a configuração do seu grupo Amazon EC2 Auto Scaling para que o número desejado de instâncias corresponda ao número atual de instâncias (evitando assim que o Amazon EC2 Auto Scaling lance mais instâncias do EC2). Para obter mais informações, consulte [Altere as configurações do grupo de implantação com CodeDeploy](deployment-groups-edit.md) ou [Escalabilidade manual do Amazon EC2 Auto Scaling](https://docs.aws.amazon.com/autoscaling/ec2/userguide/as-manual-scaling.html).
+ **O CodeDeploy agente não responde.** O CodeDeploy agente pode não ser instalado se os scripts de inicialização (por exemplo, scripts cloud-init) executados imediatamente após a inicialização ou inicialização de uma instância do EC2 levarem mais de uma hora para serem executados. CodeDeploy tem um tempo limite de uma hora para o CodeDeploy agente responder às implantações pendentes. Para resolver esse problema, mova seus scripts de inicialização para sua revisão de aplicativo CodeDeploy.
+ **Uma instância do EC2 em um grupo do Amazon EC2 Auto Scaling é reinicializada durante uma implantação.** Sua implantação pode falhar se uma instância do EC2 for reinicializada durante uma implantação ou se o CodeDeploy agente for desligado durante o processamento de um comando de implantação. Para obter mais informações, consulte [O encerramento ou a reinicialização de uma instância do Amazon EC2 Auto Scaling pode causar falhas nas implantações](#troubleshooting-auto-scaling-reboot).
+ **Várias revisões de aplicativos são implantadas simultaneamente na mesma instância do EC2 em um grupo de Amazon EC2 Auto Scaling.** A implantação de várias revisões de aplicativos na mesma instância do EC2 em um grupo de Amazon EC2 Auto Scaling ao mesmo tempo poderá falhar se uma das implantações tiver scripts que forem executados por mais de alguns minutos. Não implante várias revisões de aplicativos nas mesmas instâncias do EC2 em um grupo de Amazon EC2 Auto Scaling.
+ **Uma implantação falhará para novas instâncias do EC2 que forem iniciadas como parte de um grupo de Amazon EC2 Auto Scaling.** Nesse cenário, a execução de scripts em uma implantação pode impedir a execução de instâncias do EC2 no grupo Amazon EC2 Auto Scaling. (Outras instâncias do EC2 no grupo do Amazon EC2 Auto Scaling podem parecer estar em execução normalmente.) Para resolver esse problema, verifique se todos os outros scripts são concluídos primeiro:
+ CodeDeploy o **agente não está incluído na sua AMI**: se você usar o **cfn-init** comando para instalar o CodeDeploy agente ao iniciar uma nova instância, coloque o script de instalação do agente no final da `cfn-init` seção do seu CloudFormation modelo.
+ CodeDeploy o **agente está incluído na sua AMI**: configure a AMI para que o agente esteja em um `Stopped` estado quando a instância for criada e, em seguida, inclua um script para iniciar o agente como etapa final na sua biblioteca de `cfn-init` scripts.
## “CodeDeployRole não lhe dá permissão para realizar operações no seguinte AWS serviço: AmazonAutoScaling" erro
As implantações que usam um grupo do Auto Scaling criado com um modelo de execução exige as permissões a seguir. Elas são um acréscimo às permissões concedidas pela política `AWSCodeDeployRole` AWS gerenciada.
+ `EC2:RunInstances`
+ `EC2:CreateTags`
+ `iam:PassRole`
Você poderá receber esse erro se não tiver essas permissões. Para obter mais informações, consulte [Tutorial: Use CodeDeploy para implantar um aplicativo em um grupo do Auto Scaling](tutorials-auto-scaling-group.md), [Criação de um modelo de execução para um grupo do Auto Scaling](https://docs.aws.amazon.com/autoscaling/ec2/userguide/create-launch-template.html) e [Permissões](https://docs.aws.amazon.com/autoscaling/ec2/userguide/launch-templates.html#launch-templates-permissions) no *Manual do usuário do Amazon EC2 Auto Scaling*.
## As instâncias em um grupo de Amazon EC2 Auto Scaling são continuamente provisionadas e encerradas antes que uma revisão possa ser implantada
Em alguns casos, um erro pode impedir uma implantação bem-sucedida em instâncias recém-provisionadas em um grupo Amazon EC2 Auto Scaling. Os resultados são instâncias não íntegras e implantações sem sucesso. Como a implantação não pode ser executada ou concluída com êxito, as instâncias são encerradas logo depois de serem criadas. A configuração do grupo Amazon EC2 Auto Scaling fará com que outro lote de instâncias seja provisionado para tentar atender ao requisito mínimo de hosts íntegros. Este lote também é encerrado, e o ciclo continua.
As possíveis causas incluem:
+ Falha nas verificações de integridade do Amazon EC2 Auto Scaling.
+ Um erro na revisão de aplicativo.
Para contornar esse problema, siga estas etapas:
1. Crie manualmente uma instância do EC2 que não faça parte do grupo Amazon EC2 Auto Scaling. Marque a instância com uma tag de instância do EC2 exclusiva.
1. Adicione a nova instância ao grupo de implementação afetado.
1. Implante uma nova revisão de aplicativo sem erros no grupo de implantação.
Isso faz com que o grupo do Amazon EC2 Auto Scaling implante a revisão do aplicativo em futuras instâncias do grupo do Amazon EC2 Auto Scaling.
**nota**
Depois de confirmar que as implantações foram bem-sucedidas, exclua a instância que você criou para evitar cobranças contínuas em sua AWS conta.
## O encerramento ou a reinicialização de uma instância do Amazon EC2 Auto Scaling pode causar falhas nas implantações
Se uma instância do EC2 for iniciada através do Amazon EC2 Auto Scaling e, depois, for encerrada ou reinicializada, as implantações nessa instância poderão falhar pelos seguintes motivos:
+ Durante uma implantação em andamento, um evento de dimensionamento ou qualquer outro evento de encerramento faz com que a instância se separe do grupo do Amazon EC2 Auto Scaling e seja encerrada. Como a implantação não pode ser concluída, ela falha.
+ A instância é reinicializada, mas leva mais de cinco minutos para ser iniciada. CodeDeploy trata isso como um tempo limite. O serviço reprova todas as implantações atuais e futuras na instância.
Para resolver esse problema:
+ Em geral, verifique se todas as implantações foram concluídas antes que a instância seja encerrada ou reinicializada. Verifique se todas as implantações foram iniciadas após a reinicialização da instância.
+ As implantações podem falhar se você especificar uma Amazon Machine Image (AMI) baseada no Windows Server para uma configuração do Amazon EC2 Auto Scaling e usar o serviço EC2 Config para definir o nome do computador da instância. Para corrigir esse problema, na AMI base do Windows Server, na guia **Geral** de **Propriedades do serviço EC2**, desmarque **Definir o nome do computador**. Depois que você desmarcar a caixa de seleção, esse comportamento será desabilitado para todas as novas instâncias do Amazon EC2 Auto Scaling no Windows Server executadas com essa AMI base do Windows Server. Para as instâncias do Amazon EC2 Auto Scaling no Windows Server em que esse comportamento esteja habilitado, você não precisa desmarcar essa caixa de seleção. Basta reimplantar implementações com falha nessas instâncias depois que elas forem reinicializadas.
## Evite associar vários grupos de implantação a um único grupo de Amazon EC2 Auto Scaling
Como prática recomendada, você deve associar apenas um grupo de implantação a cada grupo de Amazon EC2 Auto Scaling.
Isso porque, se o Amazon EC2 Auto Scaling aumentar verticalmente a escala de uma instância que tem hooks associados a vários grupos de implantação, ela enviará notificações para todos os hooks de uma só vez. Isso faz com que várias implantações em cada instância sejam iniciadas ao mesmo tempo. Quando várias implantações enviam comandos ao CodeDeploy agente ao mesmo tempo, o tempo limite de cinco minutos entre um evento do ciclo de vida e o início da implantação ou o final do evento do ciclo de vida anterior pode ser atingido. Se isso acontecer, a implantação falhará, mesmo que um processo de implantação esteja em execução conforme o esperado.
**nota**
O tempo limite padrão para um script em um evento de ciclo de vida é de 30 minutos. Você pode alterar o tempo limite para um valor diferente no AppSpec arquivo. Para obter mais informações, consulte [Adicionar um AppSpec arquivo para uma implantação EC2/local](application-revisions-appspec-file.md#add-appspec-file-server).
Não é possível controlar a ordem em que as implantações ocorrem quando mais de uma implantação tenta ser executada ao mesmo tempo.
Por fim, se a implantação em qualquer instância falhar, o Amazon EC2 Auto Scaling encerrará essa instância imediatamente. Quando essa primeira instância for encerrada, as outras implantações em execução começarão a falhar. Como CodeDeploy o tempo limite é de uma hora para o CodeDeploy agente responder às implantações pendentes, pode levar até 60 minutos para que cada instância atinja o tempo limite.
Para obter mais informações sobre o Amazon EC2 Auto Scaling[, consulte Under the CodeDeploy hood: and Auto Scaling](https://aws.amazon.com/blogs/devops/under-the-hood-aws-codedeploy-and-auto-scaling-integration/) integration.
## As instâncias do EC2 em um grupo Amazon EC2 Auto Scaling falham ao ser iniciadas e recebem o erro "Heartbeat Timeout"
Um grupo Amazon EC2 Auto Scaling pode falhar ao inicializar novas instâncias do EC2, gerando uma mensagem semelhante à seguinte:
`Launching a new EC2 instance . Status Reason: Instance failed to complete user's Lifecycle Action: Lifecycle Action with token was abandoned: Heartbeat Timeout`.
Em geral, essa mensagem indica uma das seguintes situações:
+ O número máximo de implantações simultâneas associadas a uma AWS conta foi atingido. Para obter mais informações sobre limites de implantação, consulte [CodeDeploy cotas](limits.md).
+ O grupo do Auto Scaling tentou iniciar muitas instâncias do EC2 muito rapidamente. As chamadas de API para [RecordLifecycleActionHeartbeat](https://docs.aws.amazon.com/autoscaling/ec2/APIReference/API_RecordLifecycleActionHeartbeat.html)ou [CompleteLifecycleAction](https://docs.aws.amazon.com/autoscaling/ec2/APIReference/API_CompleteLifecycleAction.html)para cada nova instância foram limitadas.
+ Um aplicativo em CodeDeploy foi excluído antes que seus grupos de implantação associados fossem atualizados ou excluídos.
Quando você exclui um aplicativo ou grupo de implantação, CodeDeploy tenta limpar qualquer gancho do Amazon EC2 Auto Scaling associado a ele, mas alguns ganchos podem permanecer. Se você executar um comando para excluir um grupo de implantação, os ganchos restantes serão retornados na saída. No entanto, se você executar um comando para excluir um aplicativo, os ganchos restantes não aparecerão na saída.
Portanto, como prática recomendada, você deve excluir todos os grupos de implantação associados a um aplicativo antes de excluir esse aplicativo. É possível usar a saída do comando para identificar os ganchos de ciclo de vida que devem ser excluídos manualmente.
Se receber uma mensagem de erro "Heartbeat Timeout" (Tempo de vida de pulsação), você poderá determinar se os ganchos de ciclo de vida útil restantes são a causa e resolver o problema fazendo o seguinte:
1. Execute um destes procedimentos:
+ Chame o [delete-deployment-group](https://docs.aws.amazon.com/cli/latest/reference/deploy/delete-deployment-group.html)comando para excluir o grupo de implantação associado ao grupo Auto Scaling que está causando o tempo limite do heartbeat.
+ Chame o [update-deployment-group](https://docs.aws.amazon.com/cli/latest/reference/deploy/update-deployment-group.html)comando com uma lista vazia não nula de nomes de grupos do Auto Scaling para separar todos os ganchos do ciclo de vida do CodeDeploy Auto Scaling gerenciados.
Por exemplo, insira o seguinte AWS CLI comando:
`aws deploy update-deployment-group --application-name my-example-app --current-deployment-group-name my-deployment-group --auto-scaling-groups`
Como outro exemplo, se você estiver usando a CodeDeploy API com Java, chame `UpdateDeploymentGroup` e `autoScalingGroups` defina como`new ArrayList()`. Isso configura o `autoScalingGroups` para uma lista vazia e remove a lista existente. Não use `null`, que é o padrão, pois isso deixa o `autoScalingGroups` como está, e isso não é o que você deseja.
Examine a saída da chamada. Se a saída contiver uma estrutura `hooksNotCleanedUp` com uma lista de ganchos do ciclo de vida de Amazon EC2 Auto Scaling, os ganchos do ciclo de vida restantes são provavelmente a causa do erro.
1. Chame o [describe-lifecycle-hooks](https://docs.aws.amazon.com/cli/latest/reference/autoscaling/describe-lifecycle-hooks.html)comando, especificando o nome do grupo Amazon EC2 Auto Scaling associado às instâncias do EC2 que falharam na inicialização. Na saída, procure qualquer um dos seguintes:
+ Nomes de ganchos do ciclo de vida do Amazon EC2 Auto Scaling que correspondem à estrutura `hooksNotCleanedUp` que você identificou na etapa 1.
+ Nomes de ganchos do ciclo de vida do Amazon EC2 Auto Scaling que contêm o nome do grupo de implantação associado ao grupo do Auto Scaling que está falhando.
+ Nomes de ganchos do ciclo de vida do Amazon EC2 Auto Scaling que podem ter causado o tempo limite de pulsação da implantação. CodeDeploy
1. Se um gancho se enquadrar em uma das categorias listadas na etapa 2, chame o [delete-lifecycle-hook](https://docs.aws.amazon.com/cli/latest/reference/autoscaling/delete-lifecycle-hook.html)comando para excluí-lo. Especifique o grupo do Amazon EC2 Auto Scaling e o gancho do ciclo de vida na chamada.
**Importante**
Exclua somente os hooks que estão causando problemas, conforme descrito na etapa 2. Se você excluir ganchos viáveis, suas implantações poderão falhar ou CodeDeploy talvez não consigam implantar suas revisões de aplicativos em instâncias escaláveis do EC2.
1. Chame o [create-deployment-group](https://docs.aws.amazon.com/cli/latest/reference/deploy/create-deployment-group.html)comando [update-deployment-group](https://docs.aws.amazon.com/cli/latest/reference/deploy/update-deployment-group.html)ou com os nomes de grupo do Auto Scaling desejados. CodeDeployreinstala os ganchos do Auto Scaling com novos. UUIDs
**nota**
Se você separar um grupo do Auto Scaling de CodeDeploy um grupo de implantação, qualquer implantação em andamento no grupo do Auto Scaling poderá falhar, e as novas instâncias do EC2 que forem escaladas pelo grupo do Auto Scaling não receberão as revisões do seu aplicativo. CodeDeploy Para que o Auto Scaling funcione novamente CodeDeploy, você precisará reconectar o grupo do Auto Scaling ao grupo de implantação e chamar um novo para iniciar uma implantação em toda `CreateDeployment` a frota.
## Ganchos do ciclo de vida do Amazon EC2 Auto Scaling podem fazer com que as implantações automáticas em grupos do Amazon EC2 Auto Scaling parem ou falhem.
O Amazon EC2 Auto CodeDeploy Scaling usa ganchos de ciclo de vida para determinar quais revisões de aplicativos devem ser implantadas em quais instâncias do EC2 após serem lançadas em grupos do Amazon EC2 Auto Scaling. As implantações automáticas podem parar ou falhar se os ganchos do ciclo de vida e as informações sobre esses ganchos não corresponderem exatamente ao Amazon EC2 Auto Scaling e. CodeDeploy
Se as implantações em um grupo do Amazon EC2 Auto Scaling estiverem falhando, veja se os nomes dos ganchos do ciclo de vida no Amazon EC2 Auto Scaling correspondem. CodeDeploy Caso contrário, use essas chamadas de AWS CLI comando.
Primeiro, obtenha a lista dos nomes de ganchos do ciclo de vida para o grupo de Amazon EC2 Auto Scaling e o grupo de implantação:
1. Chame o [describe-lifecycle-hooks](https://docs.aws.amazon.com/cli/latest/reference/autoscaling/describe-lifecycle-hooks.html)comando, especificando o nome do grupo Amazon EC2 Auto Scaling associado ao grupo de implantação em. CodeDeploy Na saída, na lista `LifecycleHooks`, anote cada valor de `LifecycleHookName`.
1. Chame o [get-deployment-group](https://docs.aws.amazon.com/cli/latest/reference/deploy/get-deployment-group.html)comando, especificando o nome do grupo de implantação associado ao grupo Amazon EC2 Auto Scaling. Na saída, na lista `autoScalingGroups`, localize cada item cujo valor de nome corresponda ao nome do grupo de Amazon EC2 Auto Scaling e depois anote o valor de `hook` correspondente.
Agora, compare os dois conjuntos de nomes de ganchos de ciclo de vida. Se eles corresponderem exatamente, caractere por caractere, então este não é o problema. Você pode tentar outras etapas de solução de problemas do Amazon EC2 Auto Scaling descritas em outras partes desta seção.
No entanto, se os dois conjuntos de nomes de ganchos de ciclo de vida não corresponderem exatamente, caractere por caractere, faça o seguinte:
1. Se houver nomes de ganchos de ciclo de vida na saída do comando **describe-lifecycle-hooks** que também não estão na saída do comando **get-deployment-group**, faça o seguinte:
1. Para cada nome de gancho do ciclo de vida na saída do **describe-lifecycle-hooks** comando, chame o [delete-lifecycle-hook](https://docs.aws.amazon.com/cli/latest/reference/autoscaling/delete-lifecycle-hook.html)comando.
1. Chame o [update-deployment-group](https://docs.aws.amazon.com/cli/latest/reference/deploy/update-deployment-group.html)comando, especificando o nome do grupo original do Amazon EC2 Auto Scaling. CodeDeploy cria novos ganchos de ciclo de vida de substituição no grupo Amazon EC2 Auto Scaling e associa os ganchos de ciclo de vida ao grupo de implantação. As implantações automáticas serão agora retomadas à medida que novas instâncias forem adicionadas ao grupo de Amazon EC2 Auto Scaling.
1. Se houver nomes de ganchos de ciclo de vida na saída do comando **get-deployment-group** que não estejam também na saída do comando **describe-lifecycle-hooks**, faça o seguinte:
1. Chame o [update-deployment-group](https://docs.aws.amazon.com/cli/latest/reference/deploy/update-deployment-group.html)comando, mas não especifique o nome do grupo original do Amazon EC2 Auto Scaling.
1. Chame o **update-deployment-group** comando novamente, mas desta vez especifique o nome do grupo original do Amazon EC2 Auto Scaling. CodeDeploy recria os ganchos do ciclo de vida que faltam no grupo Amazon EC2 Auto Scaling. As implantações automáticas serão agora retomadas à medida que novas instâncias forem adicionadas ao grupo de Amazon EC2 Auto Scaling.
Depois de fazer com que os dois conjuntos de nomes de ganchos do ciclo de vida correspondam exatamente, caractere por caractere, as revisões de aplicativos deverão ser reimplantadas, mas apenas nas novas instâncias à medida que elas forem adicionadas ao grupo de Amazon EC2 Auto Scaling. As implantações não ocorrem automaticamente para as instâncias que já estão no grupo do Amazon EC2 Auto Scaling.
## Erro “A implantação falhou porque nenhuma instância foi encontrada para seu grupo de implantação”
Leia esta seção se você ver o seguinte CodeDeploy erro:
`The deployment failed because no instances were found for your deployment group. Check your deployment group settings to make sure the tags for your EC2 instances or Auto Scaling groups correctly identify the instances you want to deploy to, and then try again.`
As causas possíveis esse erro são:
1. Suas configurações de grupo de implantação incluem tags para instâncias do EC2, instâncias on-premises ou grupos do Auto Scaling que não estão corretas. Para corrigir esse problema, verifique se suas tags estão corretas e reimplante seu aplicativo.
1. Sua frota aumentou a escala horizontalmente após o início da implantação. Nesse cenário, você vê instâncias íntegras no estado `InService` da sua frota, mas também vê o erro acima. Para corrigir o problema, reimplante o aplicativo.
1. Seu grupo do Auto Scaling não inclui nenhuma instância que esteja no estado `InService`. Nesse cenário, quando você tenta fazer uma implantação em toda a frota, a implantação falha com a mensagem de erro acima porque CodeDeploy precisa de pelo menos uma instância para estar no `InService` estado. Há muitos motivos pelos quais você pode não ter instâncias no estado `InService`. Alguns deles incluem:
+ Você programou (ou configurou manualmente) o tamanho do grupo do Auto Scaling para ser `0`.
+ O ajusta de escala automático detectou instâncias defeituosas do EC2 (por exemplo, as instâncias do EC2 tiveram falhas de hardware), então cancelou todas elas, sem deixar nenhuma no estado `InService`.
+ Durante um evento de expansão horizontal de `0` até`1`, CodeDeploy implantou uma revisão anteriormente bem-sucedida (chamada de *última revisão bem-sucedida*) que não estava íntegra desde a última implantação. Isso fez com que a implantação na instância escalonada falhasse, o que, por sua vez, fez com que o ajuste de escala automático cancelasse a instância, sem deixar nenhuma instância no estado `InService`.
Se você achar que não tem instâncias no estado `InService`, solucione o problema conforme descrito no procedimento a seguir, [To troubleshoot the error if there are no instances in the InService state](#ToTroubleshootIfNoInServiceInstances).
**Para solucionar o erro se não houver instâncias no estado InService**
1. No console do Amazon EC2, verifique a configuração de **Capacidade desejada**. Se for zero, defina-a como um número positivo. Aguarde até que a instância apareça como `InService`, o que significa que a implantação foi bem-sucedida. Você corrigiu o problema e pode pular as etapas restantes desse procedimento de solução de problemas. Para obter informações sobre como definir a configuração de **Capacidade desejada**, consulte [Definindo limites de capacidade em seu grupo do Auto Scaling](https://docs.aws.amazon.com/autoscaling/ec2/userguide/asg-capacity-limits.html) no *Guia do usuário do Amazon EC2 Auto Scaling*.
1. Se o ajuste de escala automático continuar tentando lançar novas instâncias do EC2 para atingir a capacidade desejada, mas nunca conseguir atingir a escala horizontal, geralmente é devido a uma falha no gancho do ciclo de vida do ajuste de escala automático. Solucione esse problema da seguinte maneira:
1. Para verificar qual evento de gancho do ciclo de vida do ajuste de escala automático está falhando, consulte [Como verificar uma ação de escala em um grupo do Auto Scaling](https://docs.aws.amazon.com/autoscaling/ec2/userguide/as-verify-scaling-activity.html) no Guia do usuário do Amazon EC2 Auto Scaling.
1. Se o nome do gancho com falha for`CodeDeploy-managed-automatic-launch-deployment-hook-DEPLOYMENT_GROUP_NAME`, acesse CodeDeploy, encontre o grupo de implantação e encontre a implantação com falha que foi iniciada pelo Auto Scaling. Em seguida, investigue por que a implantação falhou.
1. Se você entender por que a implantação falhou (por exemplo, CloudWatch alarmes estavam ocorrendo) e puder corrigir o problema sem alterar a revisão, faça isso agora.
1. Se, após a investigação, você determinar que CodeDeploy a *última revisão bem-sucedida* não está mais íntegra e que não há nenhuma instância íntegra em seu grupo de Auto Scaling, você está em um cenário de impasse na implantação. Para resolver esse problema, você deve corrigir a CodeDeploy revisão incorreta removendo temporariamente o gancho de ciclo CodeDeploy de vida do grupo Auto Scaling e, em seguida, reinstalando o gancho e reimplantando uma nova (boa) revisão. Para obter instruções, consulte:
+ [To fix the deployment deadlock issue (CLI)](#ToFixDeployDeadlockCLI)
+ [To fix the deployment deadlock issue (console)](#ToFixDeployDeadlockConsole)
**Para corrigir o problema de impasse de implantação (CLI)**
1. (Opcional) Bloqueie os CI/CD pipelines que estão causando o CodeDeploy erro para que implantações inesperadas não ocorram enquanto você corrige esse problema.
1. Anote sua configuração atual do Auto Scaling **DesiredCapacity**:
`aws autoscaling describe-auto-scaling-groups --auto-scaling-group-name ASG_NAME`
Talvez seja necessário reduzir para esse número no final deste procedimento.
1. Defina sua configuração de Auto Scaling **DesiredCapacity**como. `1` Isso é opcional se a capacidade desejada for maior do que `1` no início. Ao reduzi-la para `1`, a instância levará menos tempo para provisionar e implantar posteriormente, o que acelera a solução de problemas. Se a capacidade desejada do ajuste de escala automático foi originalmente definida como `0`, você deve aumentá-la para `1`. Isso é obrigatório.
escalonamento automático da AWS set-desired-capacity -- --desired-capacity 1 auto-scaling-group-name *ASG\$1NAME*
**nota**
As etapas restantes desse procedimento pressupõem que você tenha definido seu **DesiredCapacity**`1`.
Nesse momento, o ajuste de escala automático tenta escalar para uma instância. Então, como o gancho CodeDeploy adicionado ainda está presente, CodeDeploy tenta implantar; a implantação falha; o Auto Scaling cancela a instância; e o Auto Scaling tenta relançar uma instância para atingir a capacidade desejada de uma, o que novamente falha. Você está em um ciclo de cancelamento e reinicialização.
1. Cancele o registro do grupo do Auto Scaling do grupo de implantação:
**Atenção**
O comando a seguir iniciará uma nova instância do EC2 sem nenhum software nela. Antes de executar o comando, verifique se uma instância `InService` do ajuste de escala automático que não executa nenhum software é aceitável. Por exemplo, certifique-se de que o balanceador de carga associado à instância não esteja enviando tráfego para esse host sem software.
**Importante**
Use o CodeDeploy comando mostrado abaixo para remover o gancho. Não remova o gancho por meio do serviço Auto Scaling, pois a remoção não será reconhecida pelo. CodeDeploy
`aws deploy update-deployment-group --application-name APPLICATION_NAME --current-deployment-group-name DEPLOYMENT_GROUP_NAME --auto-scaling-groups`
Depois que o comando é executado, ocorre o seguinte:
1. CodeDeploy cancela o registro do grupo Auto Scaling do grupo de implantação.
1. CodeDeploy remove o gancho do ciclo de vida do Auto Scaling do grupo Auto Scaling.
1. Como o hook que estava causando uma falha na implantação não está mais presente, o ajuste de escala automático cancela a instância EC2 existente e inicia imediatamente uma nova para escalar até a capacidade desejada. A nova instância deve entrar no estado `InService` em breve. A nova instância não inclui software.
1. Espere que a instância EC2 entre em um estado `InService`. Para verificar seu estado, use o seguinte comando:
`aws autoscaling describe-auto-scaling-groups --auto-scaling-group-names ASG_NAME --query AutoScalingGroups[0].Instances[*].LifecycleState`
1. Adicione o hook de volta à instância do EC2:
**Importante**
Use o CodeDeploy comando mostrado abaixo para adicionar o gancho. Não use o serviço Auto Scaling para adicionar o gancho, pois a adição não será reconhecida pelo. CodeDeploy
`aws deploy update-deployment-group --application-name APPLICATION_NAME --current-deployment-group-name DEPLOYMENT_GROUP_NAME --auto-scaling-groups ASG_NAME`
Depois que o comando é executado, ocorre o seguinte:
1. CodeDeploy reinstala o gancho do ciclo de vida do Auto Scaling na instância do EC2
1. CodeDeploy registra novamente o grupo Auto Scaling com o grupo de implantação.
1. Crie uma implantação em toda a frota com o Amazon S3 GitHub ou a revisão que você sabe que está íntegra e deseja usar.
Por exemplo, se a revisão for um arquivo.zip em um bucket do Amazon S3 chamado `my-revision-bucket` com uma chave de objeto `httpd_app.zip`, digite o seguinte comando:
`aws deploy create-deployment --application-name APPLICATION_NAME --deployment-group-name DEPLOYMENT_GROUP_NAME --revision "revisionType=S3,s3Location={bucket=my-revision-bucket,bundleType=zip,key=httpd_app.zip}"`
Como agora há uma instância `InService` no grupo do Auto Scaling, essa implantação deve funcionar e você não deve mais ver o erro *A implantação falhou porque nenhuma instância foi encontrada para seu grupo de implantação*.
1. Depois que a implantação for bem-sucedida, escale seu grupo do Auto Scaling de volta para a capacidade original, caso você tenha escalado anteriormente:
`aws autoscaling set-desired-capacity --auto-scaling-group-name ASG_NAME --desired-capacity ORIGINAL_CAPACITY`
**Para corrigir o problema de impasse de implantação (console)**
1. (Opcional) Bloqueie os CI/CD pipelines que estão causando o CodeDeploy erro para que implantações inesperadas não ocorram enquanto você corrige esse problema.
1. Acesse o console do Amazon EC2 e anote a configuração de **Capacidade desejada** do ajuste de escala automático. Talvez seja necessário reduzir para esse número no final deste procedimento. Para obter informações sobre como encontrar essa configuração, consulte [Como definir limites de capacidade em seu grupo do Auto Scaling](https://docs.aws.amazon.com/autoscaling/ec2/userguide/asg-capacity-limits.html).
1. Defina o número desejado de instâncias do EC2 como `1`:
Isso é opcional se a capacidade desejada for maior do que `1` no início. Ao reduzi-la para `1`, a instância levará menos tempo para provisionar e implantar posteriormente, o que acelera a solução de problemas. Se a **Capacidade desejada** do ajuste de escala automático foi originalmente definida como `0`, você deve aumentá-la para `1`. Isso é obrigatório.
**nota**
As etapas restantes desse procedimento pressupõem que você tenha definido a **capacidade desejada** como `1`.
1. Abra o console do Amazon EC2 em [https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/)e escolha **Auto Scaling Groups** no painel de navegação.
1. Escolha a região apropriada.
1. Acesse o grupo do Auto Scaling problemático.
1. Em **Detalhes do grupo**, escolha **Editar**.
1. Defina a **Capacidade desejada** como **1**.
1. Selecione **Atualizar**.
1. Cancele o registro do grupo do Auto Scaling do grupo de implantação:
**Atenção**
As subetapas a seguir iniciarão uma nova instância do EC2 sem nenhum software nela. Antes de executar o comando, verifique se uma instância `InService` do ajuste de escala automático que não executa nenhum software é aceitável. Por exemplo, certifique-se de que o balanceador de carga associado à instância não esteja enviando tráfego para esse host sem software.
1. Abra o CodeDeploy console em [https://console.aws.amazon.com/codedeploy/](https://console.aws.amazon.com/codedeploy/).
1. Escolha a região apropriada.
1. No painel de navegação, escolha **Aplicativos**.
1. Escolha o nome do seu CodeDeploy aplicativo.
1. Escolha o nome do seu grupo CodeDeploy de implantação.
1. Escolha **Editar**.
1. Em **Configuração do ambiente**, desmarque **grupos do Amazon EC2 Auto Scaling**.
**nota**
O console não permite que você salve a configuração se não houver uma configuração de ambiente definida. Para ignorar a verificação, adicione temporariamente uma tag de `EC2` ou `On-premises` que você sabe que não será resolvida em nenhum host. Para adicionar uma tag, selecione **instâncias do Amazon EC2** ou **instância on-premises** e adicione uma **chave** de tag de **EC2** ou **On-premises**. Você pode deixar a tag **Value** vazia.
1. Escolha **Salvar alterações**.
Depois de concluir essas subetapas, o seguinte vai acontecer:
1. CodeDeploy cancela o registro do grupo Auto Scaling do grupo de implantação.
1. CodeDeploy remove o gancho do ciclo de vida do Auto Scaling do grupo Auto Scaling.
1. Como o hook que estava causando uma falha na implantação não está mais presente, o ajuste de escala automático cancela a instância EC2 existente e inicia imediatamente uma nova para escalar até a capacidade desejada. A nova instância deve entrar no estado `InService` em breve. A nova instância não inclui software.
1. Espere que a instância EC2 entre em um estado `InService`. Para verificar seu estado:
1. Abra o console do Amazon EC2 em [https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/).
1. No painel de navegação, escolha ** Groups Auto Scaling**.
1. Escolha seu grupo do Auto Scaling.
1. No painel de conteúdo, escolha a guia **Gerenciamento de instância**.
1. Em **Instâncias**, verifique se a coluna **Ciclo de vida** indica **InService**ao lado da instância.
1. Registre novamente o grupo Auto Scaling com CodeDeploy o grupo de implantação usando o mesmo método usado para removê-lo:
1. Abra o CodeDeploy console em [https://console.aws.amazon.com/codedeploy/](https://console.aws.amazon.com/codedeploy/).
1. Escolha a região apropriada.
1. No painel de navegação, escolha **Aplicativos**.
1. Escolha o nome do seu CodeDeploy aplicativo.
1. Escolha o nome do seu grupo CodeDeploy de implantação.
1. Escolha **Editar**.
1. Em **Configuração do ambiente**, selecione **grupos do Amazon EC2 Auto Scaling** e selecione seu grupo do Auto Scaling na lista.
1. Em **Instâncias do Amazon EC2** ou **Instâncias on-premises**, encontre a tag que você adicionou e remova-a.
1. Desmarque a caixa de seleção ao lado de **Instâncias do Amazon EC2** ou **Instâncias on-premises**.
1. Escolha **Salvar alterações**.
Essa configuração reinstala o gancho do ciclo de vida no grupo do Auto Scaling.
1. Crie uma implantação em toda a frota com o Amazon S3 GitHub ou a revisão que você sabe que está íntegra e deseja usar.
Por exemplo, se a revisão for um arquivo.zip em um bucket do Amazon S3 chamado `my-revision-bucket` com uma chave de objeto de `httpd_app.zip`, faça o seguinte:
1. No CodeDeploy console, na página **Grupo de Implantação**, escolha **Criar implantação**.
1. Em **Tipo de revisão**, escolha **Meu aplicativo está armazenado no Amazon S3**.
1. Para **Local de revisão**, escolha `s3://my-revision-bucket/httpd_app.zip`.
1. Em **Tipo de arquivo de revisão**, selecione `.zip`.
1. Escolha **Criar implantação**.
Como agora há uma instância `InService` no grupo do Auto Scaling, essa implantação deve funcionar e você não deve mais ver o erro *A implantação falhou porque nenhuma instância foi encontrada para seu grupo de implantação*.
1. Depois que a implantação for bem-sucedida, escale seu grupo do Auto Scaling de volta para a capacidade original, caso você tenha escalado anteriormente:
1. Abra o console do Amazon EC2 em [https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/)e escolha **Auto Scaling Groups** no painel de navegação.
1. Escolha a região apropriada.
1. Vá para seu grupo do Auto Scaling.
1. Em **Detalhes do grupo**, escolha **Editar**.
1. Configure a **Capacidade desejada** de volta ao valor original.
1. Selecione **Atualizar**.
# Códigos de erro para o AWS CodeDeploy
Este tópico fornece informações de referência sobre erros do CodeDeploy.
****
| Código de erro | Descrição |
| --- | --- |
| `AGENT_ISSUE` | A implantação falhou por causa de um problema com o agente do CodeDeploy. Certifique-se de que o agente esteja instalado e em execução em todas as instâncias neste grupo de implantação. Saiba mais: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/pt_br/codedeploy/latest/userguide/error-codes.html) |
| `AUTO_SCALING_IAM_ROLE_PERMISSIONS` | O perfil de serviço associada ao seu grupo de implantação não tem a permissão necessária para realizar operações no seguinte serviço da AWS. Saiba mais: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/pt_br/codedeploy/latest/userguide/error-codes.html) |
| `HEALTH_CONSTRAINTS` | A implantação geral falhou porque muitas instâncias individuais falharam na implantação, poucas instâncias íntegras estão disponíveis para implantação ou algumas instâncias no seu grupo de implantação estão apresentando problemas. Saiba mais: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/pt_br/codedeploy/latest/userguide/error-codes.html) |
| `HEALTH_CONSTRAINTS_INVALID` | A implantação não pode ser iniciada porque o número mínimo de instâncias íntegras, definido pela configuração de implantação, não está disponível. Você pode reduzir o número necessário de instâncias íntegras, atualizando sua configuração de implantação ou aumentando o número de instâncias nesse grupo de implantação. Saiba mais: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/pt_br/codedeploy/latest/userguide/error-codes.html) |
| `IAM_ROLE_MISSING` | A implantação falhou porque nenhuma função de serviço existe com o nome de função de serviço especificado para o grupo de implantação. Verifique se você está usando o nome da função de serviço correto. Saiba mais: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/pt_br/codedeploy/latest/userguide/error-codes.html) |
| `IAM_ROLE_PERMISSIONS` | O CodeDeploy não tem as permissões necessárias para assumir um perfil, ou o perfil do IAM que você está usando não lhe dá permissão para realizar operações em um serviço da AWS. Saiba mais: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/pt_br/codedeploy/latest/userguide/error-codes.html) |
| `NO_INSTANCES` | Isso pode ser causado por uma das situações a seguir. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/pt_br/codedeploy/latest/userguide/error-codes.html) Saiba mais: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/pt_br/codedeploy/latest/userguide/error-codes.html) |
| `OVER_MAX_INSTANCES` | A implantação falhou porque mais instâncias estão direcionadas para implantação do que o permitido para a sua conta. Para reduzir o número de instâncias direcionadas para essa implantação, atualize as configurações de tag desse grupo de implantação ou exclua algumas das instâncias direcionadas. Como alternativa, você pode entrar em contato com AWS Support para solicitar um aumento de limites. Saiba mais: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/pt_br/codedeploy/latest/userguide/error-codes.html) |
| `THROTTLED` | A implantação falhou porque foram feitas mais solicitações do que o permitido para o AWS CodeDeploy para uma função do IAM. Tente reduzir o número de solicitações. Saiba mais: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/pt_br/codedeploy/latest/userguide/error-codes.html) |
| `UNABLE_TO_SEND_ASG` | A implantação falhou porque o grupo de implantação não está configurado corretamente com seu grupo do Amazon EC2 Auto Scaling. No console do CodeDeploy, exclua o grupo do Amazon EC2 Auto Scaling do grupo de implantação e, em seguida, adicione-o novamente. Saiba mais: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/pt_br/codedeploy/latest/userguide/error-codes.html) |
## Tópicos relacionados
[Solução de problemas CodeDeploy](troubleshooting.md)