Resolver problemas de aprovisionamento de VMs com o cloud-init

Atenção

Este artigo faz referência ao CentOS, uma distribuição Linux com status de Fim de Vida (EOL). Por favor, considere o seu uso e planeje de acordo. Para obter mais informações, consulte as diretrizes de Fim da Vida Útil do CentOS.

Aplica-se a: ✔️ Linux VMs ✔️ Conjuntos de escala flexível

Se você estiver criando imagens personalizadas generalizadas, usando cloud-init para fazer provisionamento, mas descobriu que a VM não foi criada corretamente, 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.
• O disco efêmero não consegue montar.
• 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 ou partição de troca.

Este artigo orienta você sobre como solucionar problemas de inicialização na nuvem. Para obter detalhes mais detalhados, consulte Cloud-init deep dive.

Etapa 1: Testar a implantação sem customData

Cloud-init pode aceitar customData, que é passado para ele, quando a VM é 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 consegue provisionar, continue com as etapas abaixo, se você achar que a configuração que você está passando não está sendo aplicada, vá para a etapa 4.

Etapa 2: Revisar os requisitos de imagem

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

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

• Distribuições baseadas em CentOS
• Debian Linux
• Flatcar Container Linux
• Oracle Linux
• Red Hat Enterprise Linux
• SLES e openSUSE
• Ubuntu
• Outros: Distribuições Não Aprovadas pelo Azure

Para as imagens de inicialização na nuvem do Azure com suporte, as distribuições 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 selecionada, tente uma imagem do Azure Marketplace com suporte que já esteja configurada para inicialização na nuvem, com seu opcional customData. Se o customData funciona corretamente com uma imagem do Azure Marketplace, provavelmente há um problema com sua imagem selecionada.

Etapa 3: Coletar e revisar logs de VM

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

Enquanto a VM estiver em execução, você precisará dos logs da VM para entender por que o provisionamento falhou. Para entender por que o provisionamento da 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 dos seguintes métodos:

• Habilite o Diagnóstico de Inicialização antes de criar a VM e, em seguida, visualize-os durante a inicialização.

• Consola de Série

• Execute o AZ VM Repair para anexar e montar o disco do sistema operacional usando chroot, o que permitirá que você colete esses 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*

Nota

Como alternativa, você pode criar uma VM de resgate manualmente usando o portal do Azure. Para obter mais informações, consulte Solucionar problemas de uma VM 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 inicial, comece com os logs de inicialização na nuvem e entenda onde ocorreu a falha e, em seguida, use os outros logs para aprofundar e fornecer informações adicionais.

• /var/log/cloud-init.log
• /var/log/cloud-init-output.log
• Registos de série/arranque

Em todos os logs, comece a procurar por "Failed", "WARNING", "WARN", "err", "error", "ERROR". Recomenda-se definir a configuração para ignorar pesquisas que diferenciam maiúsculas de minúsculas.

Gorjeta

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

Analisando os logs

Aqui estão mais detalhes sobre o que procurar em cada log de inicialização na nuvem.

/var/log/cloud-init.log

Por padrão, todos os eventos cloud-init com prioridade de depuração ou superior são gravados em /var/log/cloud-init.log. Isso fornece logs detalhados de todos os eventos que ocorreram durante a inicialização do 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 cloud-init para entender o que cloud-init estava tentando antes de acertar o erro ou aviso. Em muitos casos, o cloud-init terá executado comandos do sistema operacional ou realizado operações de provisionamento antes do erro, o que pode fornecer informações sobre por que os erros apareceram nos logs. O exemplo a seguir mostra que o cloud-init tentou montar um dispositivo antes que ele atingisse 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 executar.

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

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

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

Registos de série/arranque

O Cloud-init tem várias dependências, elas estão documentadas nos pré-requisitos necessá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 fazer com que o cloud-init falhe. Por exemplo, se a VM não puder obter uma concessão DHCP, o cloud-init falhará.

Se você ainda não puder isolar por que o cloud-init falhou no provisionamento, precisará entender quais estágios do cloud-init e quando os módulos são executados. Consulte Aprofundando-se no cloud-init para obter mais detalhes.

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

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

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

Próximos passos

Se você ainda não conseguir isolar por que o cloud-init não executou a configuração, precisará examinar mais de perto o que acontece em cada estágio do cloud-init e quando os módulos são executados. Consulte Aprofundando-se na configuração cloud-init para obter mais informações.