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á.
# Pilhas de solução OpsWorks de problemas
**Importante**
O AWS OpsWorks Stacks serviço chegou ao fim da vida útil em 26 de maio de 2024 e foi desativado para clientes novos e existentes. É altamente recomendável que os clientes migrem suas cargas de trabalho para outras soluções o mais rápido possível. Se você tiver dúvidas sobre migração, entre em contato com a AWS Support equipe no [AWS re:POST](https://repost.aws/) ou por meio do Premium [AWS Support](https://aws.amazon.com/support).
Esta seção contém alguns problemas comuns do OpsWorks Stacks e suas soluções.
**Topics**
+ [Não é possível gerenciar instâncias](#w2ab1c14c77c17b9b9)
+ [Depois de uma execução do Chef, as instâncias não serão inicializadas](#w2ab1c14c77c17b9c11)
+ [Todas as instâncias de uma camada falham na verificação de integridade do Elastic Load Balancing](#common-issues-troubleshoot-health)
+ [Não consigo me comunicar com um balanceador de carga do Elastic Load Balancing](#w2ab1c14c77c17b9c15)
+ [Uma instância no local importada deixa de concluir a configuração do volume após uma reinicialização](#w2ab1c14c77c17b9c17)
+ [Um volume EBS não é anexado novamente após uma reinicialização](#common-issues-troubleshoot-ebs)
+ [Não é possível excluir security groups do OpsWorks Stacks](#common-issues-troubleshoot-booting-secgroup)
+ [Excluiu acidentalmente um grupo de segurança OpsWorks do Stacks](#common-issues-troubleshoot-booting-secgroup-delete)
+ [Log do Chef encerra abruptamente](#common-issues-troubleshoot-log-terminates)
+ [O livro de receitas não é atualizado](#common-issues-troubleshoot-update)
+ [As instâncias permanecem presas no status de inicialização](#common-issues-troubleshoot-booting)
+ [Instâncias reiniciam inesperadamente](#common-issues-troubleshoot-restart)
+ [Processos `opsworks-agent` em execução em instâncias](#common-issues-troubleshoot-agent)
+ [Comandos execute\$1recipes inesperados](#common-issues-troubleshoot-unexpected)
## Não é possível gerenciar instâncias
**Problema:** você não é mais capaz de gerenciar uma instância que foi gerenciável no passado. Em alguns casos, os logs podem mostrar um erro semelhante ao seguinte.
```
Aws::CharlieInstanceService::Errors::UnrecognizedClientException - The security token included in the request is invalid.
```
**Causa:** isso poderá ocorrer se um recurso externo ao OpsWorks do qual a instância dependa tiver sido editado ou excluído. Estes são exemplos de alterações feitas no recurso que podem parar a comunicação com uma instância.
+ Um usuário ou função do IAM associado à instância foi excluído acidentalmente, fora do OpsWorks Stacks. Isso causa uma falha de comunicação entre o OpsWorks agente que está instalado na instância e o serviço OpsWorks Stacks. O usuário do associado a uma instância é obrigatório durante todo o ciclo de vida da instância.
+ Editar as configurações de volume ou armazenamento enquanto uma instância permanece off-line pode deixar uma instância ingerenciável.
+ Adicionar EC2 instâncias a um ELB manualmente. OpsWorks reconfigura um load balancer atribuído do Elastic Load Balancing sempre que uma instância entra ou sai do estado on-line. OpsWorks considera apenas as instâncias que conhece como membros válidos; as instâncias que são adicionadas fora ou por algum outro processo são removidas. OpsWorks Todas as demais instâncias são removidas.
**Solução:** não exclua usuários do IAM ou perfis de que as instâncias dependam. Se possível, só edite configurações de volume ou armazenamento enquanto as instâncias dependentes estiverem em execução. Use OpsWorks para gerenciar o balanceador de carga ou as associações EIP das instâncias. OpsWorks Quando você estiver registrando uma instância, para ajudar a evitar problemas no gerenciamento de instâncias registradas caso o usuário seja excluído acidentalmente, em vez disso, adicione o parâmetro `--use-instance-profile` ao comando `register` para usar o perfil de instância interno da instância.
## Depois de uma execução do Chef, as instâncias não serão inicializadas
**Problema:** No Chef 11.10 ou anterior, as pilhas configuradas para usar livros de receitas personalizados, depois de uma execução do Chef que usou livros de receitas da comunidade, as instâncias não serão inicializadas. As mensagens de log podem informar que as receitas deixaram de ser compiladas ("Erro na compilação da receita") ou não podem ser carregadas porque não conseguem encontrar uma dependência.
**Causa:** A causa mais provável é que o livro de receitas personalizado ou da comunidade não dá suporte à versão do Chef usada pela pilha. Alguns livros de receitas populares da comunidade, como `[apt](https://supermarket.chef.io/cookbooks/apt)` e `[build-essential](https://supermarket.chef.io/cookbooks/build-essential/versions/3.2.0)`, têm problemas de compatibilidade conhecidos com o Chef 11.10.
**Solução:** Em OpsWorks pilhas com a configuração **Usar livros de receitas personalizados do Chef ativada, os livros de receitas** personalizados ou comunitários devem sempre oferecer suporte à versão do Chef que sua pilha usa. Fixe os livros de receitas da comunidade em uma versão (ou seja, defina o número da versão do livro de receitas como uma versão específica), que seja compatível com a versão do Chef configurada nas configurações da pilha. Para encontrar uma versão do livro de receitas da comunidade compatível, visualize o log de alterações de um livro de receitas não compilado e só use a versão mais recente do livro de receitas para a qual a pilha dará suporte. Para fixar uma versão do livro de receitas, especifique um número de versão exato no Berksfile do repositório do livro de receitas personalizado. Por exemplo, .`cookbook 'build-essential', '= 3.2.0'`
## Todas as instâncias de uma camada falham na verificação de integridade do Elastic Load Balancing
**Problema:** você anexa um balanceador de carga do Elastic Load Balancing a uma camada do servidor de aplicações, mas todas as instâncias falham na verificação de integridade.
**Causa:** ao criar um balanceador de carga do Elastic Load Balancing, você deve especificar o caminho de ping que o balanceador de carga chama para determinar se a instância é íntegra. Não se esqueça de especificar um caminho de ping que seja apropriado para a aplicação; o valor padrão é /index.html. Caso a aplicação não inclua um `index.html`, você deve especificar um caminho apropriado, ou a verificação de integridade falhará. Por exemplo, o PHPApp aplicativo Simple usado em [Conceitos básicos das pilhas Linux do Chef 11](gettingstarted.md) não usa index.html; o caminho de ping apropriado para esses servidores é /.
**Solução:** Edite o caminho de ping do balanceador de carga. Para obter mais informações, consulte [Elastic Load Balancing](https://docs.aws.amazon.com/ElasticLoadBalancing/latest/DeveloperGuide/gs-ec2classic.html)
## Não consigo me comunicar com um balanceador de carga do Elastic Load Balancing
**Problema:** você cria um balanceador de carga do Elastic Load Balancing e o anexa a uma camada do servidor de aplicações, mas ao clicar no nome DNS ou no endereço IP do balanceador de carga para executar a aplicação, você recebe um erro informando que o servidor remoto não está respondendo.
**Causa:** caso a pilha esteja em execução em uma VPC padrão, ao criar um balanceador de carga do na região, você deve especificar um grupo de segurança. O security group deve ter regras de entrada que permitem o tráfego de entrada pelo endereço IP. Caso você especifique **default VPC security group**, a regra de entrada padrão não aceitará nenhum tráfego de entrada.
**Solução:** Edite as regras de entrada do security group para aceitar tráfego de entrada por endereços IP apropriados.
1. Clique em **Security Groups** no painel [de navegação do EC2 console Amazon](https://console.aws.amazon.com/ec2/).
1. Selecione o security group do balanceador de carga.
1. Clique em **Edit** na guia **Inbound**.
1. Adicione uma regra de entrada com **Source** definido como um CIDR apropriado.
Por exemplo, a especificação de **Anywhere** define o CIDR como 0.0.0.0/0, que leva o balanceador de carga a aceitar o tráfego de entrada de qualquer endereço IP.
## Uma instância no local importada deixa de concluir a configuração do volume após uma reinicialização
**Problema:** você reinicia uma EC2 instância que importou para o OpsWorks Stacks e as exibições do console OpsWorks Stacks **falharam** como status da instância. Isso pode ocorrer em instâncias do Chef 11 ou do Chef 12.
**Causa: **O OpsWorks Stacks talvez não consiga anexar um volume à instância durante o processo de configuração. Uma causa possível é que o OpsWorks Stacks substitui a configuração do volume na instância quando você executa o comando `setup`.
**Solução:** abra a página **Details** da instância e verifique a configuração do volume na área **Volumes**. Você só pode alterar a configuração do volume quando a instância está no estado **stopped**. Certifique-se de que todo volume tenha um ponto de montagem e um nome especificados. Confirme se você forneceu o ponto de montagem correto em sua configuração no OpsWorks Stacks antes de reiniciar a instância.
## Um volume EBS não é anexado novamente após uma reinicialização
**Problema:** Você usa o EC2 console da Amazon para conectar um volume do Amazon EBS a uma instância, mas quando você reinicializa a instância, o volume não está mais conectado.
**Causa:** OpsWorks As pilhas podem reconectar somente os volumes do Amazon EBS que ela conhece, que estão limitados ao seguinte:
+ Volumes que foram criados pelo OpsWorks Stacks.
+ Os volumes da conta que você registrou explicitamente com uma pilha usando a página **Resources**.
**Solução:** gerencie seus volumes do Amazon EBS somente usando o console, a API ou a CLI do OpsWorks Stacks. Se você quiser usar um dos volumes do Amazon EBS da conta com uma pilha, use a página **Recursos** da pilha para registrar o volume e anexá-lo a uma instância. Para obter mais informações, consulte [Gerenciamento de recursos](resources.md).
## Não é possível excluir security groups do OpsWorks Stacks
**Problema:** depois de excluir uma pilha, restam vários grupos de segurança de OpsWorks pilhas que não podem ser excluídos.
**Causa:** Os security groups devem ser excluídos em uma ordem específica.
**Solução:** Primeiro, certifique-se de que nenhuma instância esteja usando os security groups. Em seguida, exclua qualquer um dos seguintes security groups, caso eles existam, na seguinte ordem:
1. AWS- OpsWorks -Servidor em branco
1. AWS- OpsWorks -Servidor-mestre de monitoramento
1. Servidor mestre de banco de dados OpsWorks da AWS
1. AWS- OpsWorks -Memcached-Server
1. AWS- OpsWorks -Servidor personalizado
1. AWS- OpsWorks -NodeJS-App-Server
1. Servidor de aplicativos AWS- OpsWorks -PHP
1. Servidor de aplicativos AWS- OpsWorks -Rails
1. AWS- OpsWorks -Servidor web
1. AWS- OpsWorks -Servidor padrão
1. Servidor AWS- OpsWorks -LB
## Excluiu acidentalmente um grupo de segurança OpsWorks do Stacks
**Problema:** você excluiu um dos grupos de segurança do OpsWorks Stacks e precisa recriá-lo.
**Causa:** Esses security groups normalmente são excluídos por acidente.
**Solução:** O grupo recriado deve ser uma cópia exata do original, inclusive a mesma capitalização para o nome do grupo. Em vez de recriar manualmente o grupo, a abordagem preferida é para o OpsWorks Stacks realizar a tarefa para você. Basta criar uma nova pilha na mesma região da AWS — e VPC, se OpsWorks presente — e o Stacks recriará automaticamente todos os grupos de segurança integrados, incluindo aquele que você excluiu. Você pode então excluir a pilha se não tiver mais uso para ela; os security groups permanecerão.
## Log do Chef encerra abruptamente
**Problema:** Um log do Chef é encerrado abruptamente; o final do log não indica uma execução bem-sucedida ou exibe uma exceção e um rastreamento da pilha.
**Causa:** Esse comportamento costuma ser causado por memória inadequada.
**Solução:** Crie uma instância maior e use o comando `run_command` da CLI do agente para reexecutar as receitas. Para obter mais informações, consulte [Execução de receitas](troubleshoot-debug-cli.md#troubleshoot-debug-cli-recipes).
## O livro de receitas não é atualizado
**Problema:** você atualizou seus livros de receitas, mas as instâncias da pilha continuam executando as receitas antigas.
**Causa:** o OpsWorks Stacks armazena livros de receitas em cada instância e executa receitas do cache, não do repositório. Quando você inicia uma nova instância, o OpsWorks Stacks baixa seus livros de receitas do repositório para o cache da instância. No entanto, caso você modifique depois os livros de receitas personalizados, o OpsWorks Stacks não atualiza automaticamente os caches das instâncias online.
**Solução:** execute o [comando Atualizar pilha de livros de receitas para direcionar explicitamente as OpsWorks pilhas](workingstacks-commands.md) a atualizar os caches de livros de receitas de suas instâncias on-line.
## As instâncias permanecem presas no status de inicialização
**Problema:** Quando você reinicia uma instância, ou a correção automática é reiniciada automaticamente, a operação de inicialização para no status `booting`.
**Causa:** Uma causa possível desse problema é a configuração da VPC, inclusive uma VPC padrão. As instâncias devem sempre ser capazes de se comunicar com o serviço OpsWorks Stacks, o Amazon S3 e os repositórios de pacotes, livros de receitas e aplicativos. Se, por exemplo, você remover um gateway padrão de uma VPC padrão, as instâncias perderão a conexão com o serviço OpsWorks Stacks. Como o OpsWorks Stacks não consegue mais se comunicar com o [agente](troubleshoot-debug-cli.md) da instância, ele trata a instância como falhada e a [cura automaticamente](workinginstances-autohealing.md). No entanto, sem uma conexão, o OpsWorks Stacks não pode instalar um agente de instância na instância recuperada. Sem um agente, o OpsWorks Stacks não pode executar as receitas de configuração na instância, portanto, a operação de inicialização não pode progredir além do status de “inicialização”.
**Solução:** Modifique a configuração da VPC, de maneira que as instâncias tenham a conectividade necessária.
## Instâncias reiniciam inesperadamente
**Problema:** Uma instância interrompida reinicia inesperadamente.
**Causa 1:** Se você ativou a [recuperação automática](workinginstances-autohealing.md) para suas instâncias, o OpsWorks Stacks realiza periodicamente uma verificação de saúde nas EC2 instâncias associadas da Amazon e reinicia as que não estão íntegras. Se você interromper ou encerrar uma instância OpsWorks gerenciada pelo Stacks usando o EC2 console, a API ou a CLI da Amazon, o Stacks não será notificado. OpsWorks Em vez disso, ele irá considerar a instância parada como não íntegra e iniciá-la automaticamente.
**Solução:** Gerencie apenas as instâncias do usando a API ou a CLI do console do OpsWorks Stacks. Se você usar o OpsWorks Stacks para interromper ou excluir uma instância, ela não será reiniciada. Para obter mais informações, consulte [Descreve como iniciar, parar e reiniciar instâncias 24/7](workinginstances-starting.md) e [Excluindo instâncias do OpsWorks Stacks](workinginstances-delete.md).
**Causa 2:** As instâncias podem falhar por vários motivos. Se você tiver a recuperação automática ativada, o OpsWorks Stacks reinicia automaticamente as instâncias com falha.
**Solução:** Essa é uma operação normal; não há necessidade de fazer nada, a menos que você não queira que o OpsWorks Stacks reinicie as instâncias com falha. Neste caso, você deve desativar a correção automática.
## Processos `opsworks-agent` em execução em instâncias
**Problema:** Diversos processos `opsworks-agent` são executados nas instâncias. Por exemplo:
```
aws 24543 0.0 1.3 172360 53332 ? S Feb24 0:29 opsworks-agent: master 24543
aws 24545 0.1 2.0 208932 79224 ? S Feb24 22:02 opsworks-agent: keep_alive of master 24543
aws 24557 0.0 2.0 209012 79412 ? S Feb24 8:04 opsworks-agent: statistics of master 24543
aws 24559 0.0 2.2 216604 86992 ? S Feb24 4:14 opsworks-agent: process_command of master 24
```
**Causa:** Estes são os processos legítimos necessários à operação normal do agente. Eles realizam tarefas como o processamento de implantações e o reenvio de mensagens keep-alive para o serviço.
**Solução:** Este é o comportamento normal. Não pare esses processos, pois isso comprometerá a operação do agente.
## Comandos execute\$1recipes inesperados
**Problema:** a seção **Logs** na página de detalhes de uma instância inclui comandos `execute_recipes` inesperados. Comandos `execute_recipes` inesperado também podem ser exibidos nas páginas **Stack** e **Deployments**.
**Causa:** Este problema normalmente é causado por alterações feitas na permissão. Quando você altera as permissões SSH ou sudo de um usuário ou grupo, o OpsWorks Stacks é executado `execute_recipes` para atualizar as instâncias da pilha e também aciona um evento Configure. Outra fonte do comando `execute_recipes` é a atualização do agente da instância pelo OpsWorks Stacks.
**Solução:** Esta é uma operação normal. Não há necessidade de fazer nada.
Para ver quais ações um comando `execute_recipes` realizou, vá até a página **Deployments** e clique no time stamp do comando. Isso abre a página de detalhes do comando, que lista as principais receitas que foram executadas. Por exemplo, a página de detalhes a seguir é de um comando `execute_recipes` que executou `ssh_users` para atualizar as permissões SSH.
![\[Command details page showing successful execution of Recipes and ssh_users on php-app1.\]](http://docs.aws.amazon.com/pt_br/opsworks/latest/userguide/images/command_details.png)
Para ver todos os detalhes, clique em **show** na coluna **Log** do comando para exibir o log do Chef associado. Pesquise no registro por**Run List**. OpsWorks As receitas de manutenção de pilhas estarão abaixo`OpsWorks Custom Run List`. Por exemplo, esta é a lista de execuções do comando `execute_recipes` mostrado na captura de tela anterior e que mostra todas as receitas associadas ao comando.
```
[2014-02-21T17:16:30+00:00] INFO: OpsWorks Custom Run List: ["opsworks_stack_state_sync",
"ssh_users", "test_suite", "opsworks_cleanup"]
```