Risoluzione dei problemi di provisioning delle macchine virtuali con cloud-init

Attenzione

Questo articolo fa riferimento a CentOS, una distribuzione di Linux che ha raggiunto lo stato di fine del servizio (EOL). Valutare le proprie esigenze e pianificare di conseguenza. Per ulteriori informazioni, consultare la Guida alla fine del ciclo di vita di CentOS.

Si applica a: ✔️ macchine virtuali di Linux ✔️ set di scalabilità flessibili

Se sono state create immagini personalizzate generalizzate, usando cloud-init per eseguire il provisioning, ma si è scoperto che la macchina virtuale non è stata creata correttamente, è necessario risolvere i problemi relativi alle immagini personalizzate.

Alcuni esempi di problemi relativi al provisioning:

• La macchina virtuale si blocca durante la creazione per 40 minuti e la creazione della macchina virtuale è contrassegnata come non riuscita.
• CustomData non viene elaborato.
• Il disco temporaneo non riesce a montare.
• Gli utenti non vengono creati o si verificano problemi di accesso degli utenti.
• La rete non è configurata correttamente.
• Errori di scambio di file o partizioni.

Questo articolo illustra come risolvere i problemi relativi a cloud-init. Per altri dettagli, vedere approfondimenti su cloud-init.

Passaggio 1: Testare la distribuzione senza customData

Cloud-init può accettare customData, che viene passato a esso, quando viene creata la macchina virtuale. Prima di tutto è necessario assicurarsi che questo non causi problemi con le distribuzioni. Provare a effettuare il provisioning della macchina virtuale senza passare alcuna configurazione. Se il provisioning della macchina virtuale non riesce, continuare con la procedura seguente, se si rileva che la configurazione passata non viene applicata al passaggio 4.

Passaggio 2: Esaminare i requisiti dell'immagine

La causa principale dell'errore di provisioning delle macchine virtuali è che l'immagine del sistema operativo non soddisfa i prerequisiti per l'esecuzione in Azure. Assicurarsi che le immagini siano preparate correttamente prima di tentare di eseguirne il provisioning in Azure.

Gli articoli seguenti illustrano i passaggi per preparare varie distribuzioni linux supportate in Azure:

• Distribuzioni basate su CentOS
• Debian Linux
• Flatcar Container Linux
• Oracle Linux
• Red Hat Enterprise Linux
• SLES e openSUSE
• Ubuntu
• Altro: Distribuzioni non approvate

Per le immagini cloud-init di Azure supportate, le distribuzioni Linux hanno già tutti i pacchetti e le configurazioni necessari per eseguire correttamente il provisioning dell'immagine in Azure. Se la macchina virtuale non riesce a creare dalla propria immagine curata, provare un'immagine di Azure Marketplace supportata già configurata per cloud-init, con l'opzione facoltativa customData. Se funziona customData correttamente con un'immagine di Azure Marketplace, è probabile che si verifichi un problema con l'immagine curata.

Passaggio 3: Raccogliere ed esaminare i log delle macchine virtuali

Quando il provisioning della macchina virtuale non riesce, Azure visualizzerà lo stato di "creazione", per 20 minuti e quindi riavvia la macchina virtuale e attenderà altri 20 minuti prima di contrassegnare la distribuzione della macchina virtuale come non riuscita, prima di contrassegnarla con un OSProvisioningTimedOut errore.

Mentre la macchina virtuale è in esecuzione, saranno necessari i log dalla macchina virtuale per capire perché il provisioning non è riuscito. Per comprendere il motivo per cui il provisioning delle macchine virtuali non è riuscito, non arrestare la macchina virtuale. Mantenere la macchina virtuale in esecuzione. È necessario mantenere la macchina virtuale non riuscita in uno stato di esecuzione per raccogliere i log. Per raccogliere i log, usare uno dei metodi seguenti:

• Abilitare Diagnostica di avvio prima di creare la macchina virtuale e quindi visualizzarli durante l'avvio.

• Console seriale

• Eseguire AZ VM Repair per collegare e montare il disco del sistema operativo usando chroot, che consentirà di raccogliere questi log:

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

In alternativa, è possibile creare manualmente una macchina virtuale di ripristino usando il portale di Azure. Per altre informazioni, vedere Risolvere i problemi di una macchina virtuale Linux collegando il disco del sistema operativo a una macchina virtuale di ripristino usando il portale di Azure.

Per iniziare la risoluzione dei problemi iniziale, iniziare con i log cloud-init e comprendere dove si è verificato l'errore, quindi usare gli altri log per approfondire e fornire informazioni aggiuntive.

• /var/log/cloud-init.log
• /var/log/cloud-init-output.log
• Log seriali/di avvio

In tutti i log avviare la ricerca di "Failed", "WARNING", "WARN", "err", "error", "ERROR". È consigliabile impostare la configurazione per ignorare le ricerche con distinzione tra maiuscole e minuscole.

Suggerimento

Se si risoluzione dei problemi relativi a un'immagine personalizzata, è consigliabile aggiungere un utente durante l'immagine. Se il provisioning non riesce a impostare l'utente amministratore, è comunque possibile accedere al sistema operativo.

Analisi dei log

Ecco altri dettagli su cosa cercare in ogni log cloud-init.

/var/log/cloud-init.log

Per impostazione predefinita, tutti gli eventi cloud-init con priorità di debug o superiore vengono scritti in /var/log/cloud-init.log. In questo modo vengono forniti log dettagliati di ogni evento che si è verificato durante l'inizializzazione di cloud-init.

Ad esempio:

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

Dopo aver trovato un errore o un avviso, leggere all'indietro nel log di cloud-init per comprendere il tentativo di cloud-init prima di raggiungere l'errore o l'avviso. In molti casi cloud-init eseguirà comandi del sistema operativo o eseguirà operazioni di provisioning prima dell'errore, che può fornire informazioni dettagliate sul motivo per cui gli errori sono stati visualizzati nei log. L'esempio seguente mostra che cloud-init ha tentato di montare un dispositivo subito prima che si verifichi un errore.

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 si ha accesso alla console seriale, è possibile provare a eseguire di nuovo il comando che cloud-init stava tentando di eseguire.

La registrazione per /var/log/cloud-init.log può anche essere riconfigurata all'interno di /etc/cloud/cloud.cfg.d/05_logging.cfg. Per altri dettagli sulla registrazione di cloud-init, vedere la documentazione di cloud-init.

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

È possibile ottenere informazioni da stdout e durante le fasi di cloud-initstderr. Questo comporta in genere informazioni sulla tabella di routing, informazioni di rete, informazioni stdout sulla verifica della chiave host SSH e stderr per ogni fase di cloud-init, insieme al timestamp per ogni fase. Se necessario, stderr la stdout registrazione può essere riconfigurata da /etc/cloud/cloud.cfg.d/05_logging.cfg.

Log seriali/di avvio

Cloud-init presenta più dipendenze, che sono documentate nei prerequisiti necessari per le immagini in Azure, ad esempio rete, archiviazione, possibilità di montare un ISO e montare e formattare il disco temporaneo. Uno di questi può generare errori e causare l'esito negativo di cloud-init. Ad esempio, se la macchina virtuale non riesce a ottenere un lease DHCP, cloud-init avrà esito negativo.

Se non è ancora possibile isolare il motivo per cui cloud-init non è riuscito a eseguire il provisioning, è necessario comprendere quali fasi cloud-init e quando vengono eseguiti i moduli. Per altre informazioni, vedere Approfondimento su cloud-init .

Passaggio 4: Esaminare il motivo per cui la configurazione non viene applicata

Non tutti gli errori in cloud-init generano un errore irreversibile di provisioning. Ad esempio, se si usa il runcmd modulo in una configurazione cloud-init, un codice di uscita diverso da zero dal comando in esecuzione causerà l'esito negativo del provisioning della macchina virtuale. Ciò è dovuto al fatto che viene eseguito dopo la funzionalità di provisioning principale che si verifica nelle prime 3 fasi di cloud-init. Per risolvere i problemi relativi al motivo per cui la configurazione non è stata applicata, esaminare i log nel passaggio 3 e i moduli cloud-init manualmente. Ad esempio:

• runcmd - gli script vengono eseguiti senza errori? Eseguire manualmente la configurazione dal terminale per assicurarsi che vengano eseguite come previsto.
• Installazione di pacchetti: la macchina virtuale ha accesso ai repository di pacchetti?
• È anche necessario controllare la configurazione dei customData dati fornita alla macchina virtuale, che si trova in /var/lib/cloud/instances/<unique-instance-identifier>/user-data.txt.

Passaggi successivi

Se non è ancora possibile isolare il motivo per cui cloud-init non ha eseguito la configurazione, è necessario esaminare più attentamente cosa accade in ogni fase cloud-init e quando i moduli vengono eseguiti. Per altre informazioni, vedere Approfondimento sulla configurazione di cloud-init.