Pilhas de solução AWS 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 ou por meio do Premium AWS Support.

Esta seção contém alguns problemas comuns do AWS OpsWorks Stacks e suas soluções.

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 AWS 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 AWS OpsWorks Stacks. Isso causa uma falha de comunicação entre o AWS OpsWorks agente que está instalado na instância e o serviço AWS 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 instâncias do EC2 a um ELB manualmente. AWS OpsWorks reconfigura um load balancer atribuído do Elastic Load Balancing toda vez que uma instância entra ou sai do estado on-line. AWS 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. AWS 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 AWS OpsWorks para gerenciar o balanceador de carga ou as associações EIP das instâncias. AWS 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 e build-essential, têm problemas de compatibilidade conhecidos com o Chef 11.10.

Solução: Em AWS 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, a aplicação SimplePHPApp usado em Conceitos básicos das pilhas Linux do Chef 11 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

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. No painel de navegação do console do Amazon EC2, clique em Grupos de segurança.

2. Selecione o security group do balanceador de carga.

3. Clique em Edit na guia Inbound.

4. 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 instância do EC2 que você importou para o AWS OpsWorks Stacks, e as exibições do console AWS OpsWorks Stacks falharam como status da instância. Isso pode ocorrer em instâncias do Chef 11 ou do Chef 12.

Causa: O AWS OpsWorks Stacks talvez não consiga anexar um volume à instância durante o processo de configuração. Uma causa possível é que o AWS 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 AWS OpsWorks Stacks antes de reiniciar a instância.

Um volume EBS não é anexado novamente após uma reinicialização

Problema: você pode usar o console do Amazon EC2 para anexar um volume do Amazon EBS a uma instância, mas quando você reinicia a instância, o volume não está mais conectado.

Causa: AWS 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 AWS 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 AWS 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 ter mais informações, consulte Gerenciamento de recursos.

Não é possível excluir security groups do AWS OpsWorks Stacks

Problema: depois de excluir uma pilha, restam vários grupos de segurança de AWS 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

2. AWS- OpsWorks -Servidor-mestre de monitoramento

3. Servidor mestre de banco de dados OpsWorks da AWS

4. AWS- OpsWorks -Memcached-Server

5. AWS- OpsWorks -Servidor personalizado

6. AWS- OpsWorks -NodeJS-App-Server

7. Servidor de aplicativos AWS- OpsWorks -PHP

8. Servidor de aplicativos AWS- OpsWorks -Rails

9. AWS- OpsWorks -Servidor web

10. AWS- OpsWorks -Servidor padrão

11. Servidor AWS- OpsWorks -LB

Excluiu acidentalmente um grupo de segurança AWS OpsWorks do Stacks

Problema: você excluiu um dos grupos de segurança do AWS 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 AWS OpsWorks Stacks realizar a tarefa para você. Basta criar uma nova pilha na mesma região da AWS — e VPC, se AWS 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 ter mais informações, consulte Execução de receitas.

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 AWS 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 AWS 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 AWS 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 AWS OpsWorks pilhas 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 AWS 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 AWS OpsWorks Stacks. Como o AWS OpsWorks Stacks não consegue mais se comunicar com o agente da instância, ele trata a instância como falhada e a cura automaticamente. No entanto, sem uma conexão, o AWS OpsWorks Stacks não pode instalar um agente de instância na instância recuperada. Sem um agente, o AWS 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: caso você tenha ativado a correção automática para as instâncias, o AWS OpsWorks Stacks realiza periodicamente uma verificação de integridade nas instâncias do Amazon EC2 associadas e reinicia as que não forem íntegras. Se você interromper ou encerrar uma instância AWS OpsWorks gerenciada pelo Stacks usando o console, a API ou a CLI do Amazon EC2, o Stacks não será notificado. AWS 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 AWS OpsWorks Stacks. Se você usar o AWS 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 e Excluindo instâncias do AWS OpsWorks Stacks.

Causa 2: As instâncias podem falhar por vários motivos. Se você tiver a recuperação automática ativada, o AWS 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 AWS 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_recipes 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 AWS 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 AWS 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.

Para ver todos os detalhes, clique em show na coluna Log do comando para exibir o log do Chef associado. Pesquise no registro porRun List. AWS OpsWorks As receitas de manutenção de pilhas estarão abaixoOpsWorks 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"]