Solução de problemas de provisionamento de VM com cloud-init

Cuidado

Este artigo faz referência ao CentOS, uma distribuição do Linux que está se aproximando do status de EOL (fim da vida útil). Considere seu uso e planeje adequadamente. Para obter mais informações, veja as Diretrizes sobre fim da vida útil do CentOS.

Aplica-se a: ✔️ VMs do Linux ✔️ Conjuntos de dimensionamento flexíveis

Se você estiver criando imagens personalizadas generalizadas, usando cloud-init para fazer o provisionamento, mas tiver constatado que a VM não foi criada corretamente, você precisará solucionar problemas de suas imagens personalizadas.

Alguns exemplos de problemas com o provisionamento:

• A VM fica presa na “criação” por 40 minutos e a criação da VM é marcada como falha.
• CustomData não é processado.
• Falha na montagem do disco efêmero.
• Os usuários não são criados ou há problemas de acesso do usuário.
• A rede não está configurada corretamente.
• Falhas de arquivo de permuta ou de partição.

Este artigo orienta você sobre como solucionar problemas de cloud-init. Para obter mais detalhes, confira Detalhamento de cloud-ini.

Etapa 1: Testar a implantação sem customData

O cloud-init pode aceitar customData, que é passado para ele quando a VM for criada. Primeiro, você deve garantir que isso não esteja causando problemas com implantações. Tente provisionar a VM sem passar por nenhuma configuração. Se você achar que a VM não está provisionada, continue com as etapas abaixo, se achar que a configuração que está passando não está sendo aplicada, vá para a etapa 4.

Etapa 2: Examinar os requisitos de imagem

A principal causa da falha de provisionamento da VM é que a imagem do sistema operacional não atende aos pré-requisitos para execução no Azure. Verifique se suas imagens estão adequadamente preparadas antes de tentar provisioná-las no Azure.

Os artigos a seguir ilustram as etapas para preparar várias distribuições do Linux com suporte no Azure:

• Distribuições com base em CentOS
• Debian Linux
• Flatcar Container Linux
• Oracle Linux
• Red Hat Enterprise Linux
• SLES e openSUSE
• Ubuntu
• Outros: Distribuições não endossadas

Para as imagens do cloud-init do Azure com suporte, as distribuições do Linux já têm todos os pacotes e configurações necessários para provisionar corretamente a imagem no Azure. Se você achar que sua VM não está conseguindo criar a partir de sua própria imagem organizada, experimente uma imagem do Azure Marketplace com suporte que já esteja configurada para cloud-init, com o customData opcional. Se o customData funcionar corretamente com uma imagem do Azure Marketplace, provavelmente haverá um problema com a imagem organizada.

Etapa 3: Coletar e examinar os logs da VM

Quando a VM não puder ser provisionada, o Azure mostrará o status “criando” por 20 minutos, e reinicializará a VM e aguardará mais 20 minutos antes de finalmente marcar a implantação da VM como com falha, antes de finalmente marcá-la com um erro OSProvisioningTimedOut.

Enquanto a VM estiver em execução, você precisará dos logs da VM para entender por que houve falha no provisionamento. Para entender por que o provisionamento de VM falhou, não pare a VM. Mantenha a VM em execução. Você precisará manter a VM com falha em um estado de execução para coletar logs. Para coletar os logs, use um destes métodos:

• Habilite o diagnóstico de inicialização antes de criar a VM e, em seguida, exiba-o durante a inicialização.

• Console serial

• Execute AZ VM Repair para anexar e montar o disco do sistema operacional, usando chroot, o que permitirá que você colete estes logs:

sudo cat /rescue/var/log/cloud-init*
sudo cat /rescue/var/log/waagent*
sudo cat /rescue/var/log/syslog*
sudo cat /rescue/var/log/rsyslog*
sudo cat /rescue/var/log/messages*
sudo cat /rescue/var/log/kern*
sudo cat /rescue/var/log/dmesg*
sudo cat /rescue/var/log/boot*

Observação

Como alternativa, você pode criar uma VM de resgate manualmente usando o portal do Azure. Para obter mais informações, confira Solucionar problemas de uma VM do Linux anexando o disco do sistema operacional a uma VM de recuperação usando o portal do Azure.

Para iniciar a solução de problemas, comece com os logs de cloud-init e entenda onde a falha ocorreu, use os outros logs para aprofundar-se e fornecer informações adicionais.

• /var/log/cloud-init.log
• /var/log/cloud-init-output.log
• Logs de série/inicialização

Em todos os logs, comece a procurar "Falha", "AVISO", "AVIS", "err", "erro", "ERRO". É recomendável definir a configuração para ignorar pesquisas que diferenciam maiúsculas de minúsculas.

Dica

Se você estiver solucionando problemas de uma imagem personalizada, considere adicionar um usuário durante a imagem. Se o provisionamento falhar ao definir o usuário administrador, você ainda poderá fazer logon no sistema operacional.

Como analisar os logs

Aqui estão mais detalhes sobre o que procurar em cada log do cloud-init.

/var/log/cloud-init.log

Por padrão, todos os eventos cloud-init com uma prioridade de depuração ou superior são gravados no /var/log/cloud-init.log. Isso fornece logs detalhados de cada evento ocorrido durante a inicialização de cloud-init.

Por exemplo:

2019-10-10 04:51:25,321 - util.py[DEBUG]: Failed mount of '/dev/sr0' as 'auto': Unexpected error while running command.
Command: ['mount', '-o', 'ro,sync', '-t', 'auto', u'/dev/sr0', '/run/cloud-init/tmp/tmpLIrklc']
Exit code: 32
Reason: -
Stdout:
Stderr: mount: unknown filesystem type 'udf'
2020-01-31 00:21:53,352 - DataSourceAzure.py[WARNING]: /dev/sr0 was not mountable

Depois de encontrar um erro ou aviso, leia para trás no log de inicialização de nuvem para entender o que a cloud-init estava tentando antes de atingir o erro ou o aviso. Em muitos casos, o cloud-init terá comandos do sistema operacional executados ou executará operações de provisionamento anteriores ao erro, o que pode fornecer informações sobre por que os erros apareciam nos logs. O exemplo a seguir mostra que a cloud-init tentou montar um dispositivo imediatamente antes de clicar em um erro.

2019-10-10 04:51:24,010 - util.py[DEBUG]: Running command ['mount', '-o', 'ro,sync', '-t', 'auto', u'/dev/sr0', '/run/cloud-init/tmp/tmpXXXXX'] with allowed return codes [0] (shell=False, capture=True)

Se você tiver acesso ao Console Serial, poderá tentar executar novamente o comando que cloud-init estava tentando realizar.

O registro em log para /var/log/cloud-init.log também pode ser reconfigurado em /etc/cloud/cloud.cfg.d/05_logging.cfg. Para obter mais detalhes de registro do cloud-init, confira a documentação do cloud-init.

/var/log/cloud-init-output.log

Você pode obter informações do stdout e stderr durante os estágios de cloud-init. Isso normalmente envolve informações de tabela de roteamento, informações de rede, informações de verificação de chave de host SSH stdout e stderr para cada estágio de cloud-init, juntamente com o carimbo de data/hora de cada estágio. Se desejar, os registros em log stderr e stdout podem ser reconfigurados de /etc/cloud/cloud.cfg.d/05_logging.cfg.

Logs de série/inicialização

O cloud-init tem várias dependências, elas são documentadas em pré-requisitos obrigatórios para imagens no Azure, como rede, armazenamento, capacidade de montar um ISO e montar e formatar o disco temporário. Qualquer um deles pode gerar erros e causar falha em cloud-init. Por exemplo, se a VM não puder obter uma concessão DHCP, cloud-init falhará.

Se ainda não for possível isolar por que cloud-init falhou ao provisionar, você precisará entender os estágios de cloud-init e quando os módulos são executados. Confira Detalhamento do cloud-init para obter mais detalhes.

Etapa 4: Investigar por que a configuração não está sendo aplicada

Nem toda falha em cloud-init resulta em uma falha de provisionamento fatal. Por exemplo, se você estiver usando o módulo runcmd em uma configuração de inicialização de nuvem, um código de saída diferente de zero do comando que está sendo executado fará com que o provisionamento da VM falhe. Isso ocorre porque ele é executado após a funcionalidade de provisionamento principal que ocorre nos três primeiros estágios de cloud-init. Para solucionar problemas de por que a configuração não foi aplicada, examine os logs da Etapa 3 e os módulos de cloud-init manualmente. Por exemplo:

• runcmd ꟷ os scripts são executados sem erros? Execute a configuração manualmente do terminal para garantir que elas sejam executadas conforme o esperado.
• Instalação de pacotes ꟷ a VM tem acesso aos repositórios de pacotes?
• Você também deve verificar a configuração de dados de customData fornecida para a VM, que está localizada em /var/lib/cloud/instances/<unique-instance-identifier>/user-data.txt.

Próximas etapas

Se você ainda não puder isolar por que cloud-init não executou a configuração, precisará verificar mais detalhadamente o que acontece em cada estágio de cloud-init e quando os módulos são executados. Confira Detalhamento da configuração de cloud-init para saber mais.