|
| 1 | +--- |
| 2 | +title: 6. Troubleshooting cloud-init |
| 3 | +author: Wale Soyinka |
| 4 | +contributors: Steven Spencer, Ganna Zhyrnova |
| 5 | +tags: |
| 6 | + - cloud-init |
| 7 | + - rocky linux |
| 8 | + - cloud |
| 9 | + - automation |
| 10 | + - troubleshooting |
| 11 | +--- |
| 12 | + |
| 13 | +## Troubleshooting cloud-init |
| 14 | + |
| 15 | +In qualsiasi sistema complesso e automatizzato, prima o poi qualcosa andrà storto. Quando una configurazione `cloud-init` fallisce, sapere come diagnosticare sistematicamente il problema è una competenza essenziale. Questo capitolo è una guida all'analisi forense di `cloud-init` e tratta sia le tecniche di risoluzione dei problemi in guest che quelle in host. |
| 16 | + |
| 17 | +## 1. Toolkit per il troubleshooting in-guest |
| 18 | + |
| 19 | +Quando è possibile accedere a un'istanza in esecuzione, `cloud-init` fornisce diversi comandi e registri per mostrare cosa è successo. |
| 20 | + |
| 21 | +### Punto 1: Il comando status (`cloud-init status`) |
| 22 | + |
| 23 | +Questo è il tuo primo punto di riferimento. Fornisce un riepilogo di alto livello dello stato di `cloud-init`. |
| 24 | + |
| 25 | +- **Verifica il completamento di `cloud-init`:** `cloud-init status` |
| 26 | + (Se l'esecuzione ha avuto esito positivo, verrà visualizzato `status: done`) |
| 27 | + |
| 28 | +- _Attendere il completamento di `cloud-init`:_\* `cloud-init status --wait` |
| 29 | + (Questo è utile negli script per mettere in pausa l'esecuzione fino al completamento di `cloud-init`) |
| 30 | + |
| 31 | +### Punto 2: Il log principale (`/var/log/cloud-init.log`) |
| 32 | + |
| 33 | +Questo file è la principale fonte di verità: una registrazione dettagliata e cronologica di ogni fase e modulo. Quando si ha bisogno di sapere _esattamente_ cosa è successo, guardare qui. Cercando in questo file `ERROR` o `WARNING` spesso si arriva direttamente al problema. |
| 34 | + |
| 35 | +### Pilastro 3: Il log di output (`/var/log/cloud-init-output.log`) |
| 36 | + |
| 37 | +Questo log registra l'intero `stdout` e `stderr` di tutti gli script eseguiti da `cloud-init` (ad esempio, da `runcmd`). Se un modulo è stato eseguito ma lo script al suo interno non ha funzionato, il messaggio di errore sarà presente in questo file. |
| 38 | + |
| 39 | +**Hands-on: debug di un comando `runcmd` non funzionante** |
| 40 | + |
| 41 | +1. Creare un file `user-data.yml` con un comando `runcmd` che contiene un errore nascosto: |
| 42 | + |
| 43 | + ```bash |
| 44 | + cat <<EOF > user-data.yml |
| 45 | + #cloud-config |
| 46 | + runcmd: |
| 47 | + - [ ls, /non-existent-dir ] |
| 48 | + EOF |
| 49 | + ``` |
| 50 | +
|
| 51 | +2. Avviare una VM con questi dati. `cloud-init status` riporterà `status: done` perché il modulo `runcmd` stesso è stato eseguito correttamente. |
| 52 | +
|
| 53 | +3. Tuttavia, `/var/log/cloud-init-output.log` conterrà l'errore effettivo del comando `ls`, mostrando cosa non ha funzionato: |
| 54 | +
|
| 55 | + ``` |
| 56 | + ls: cannot access '/non-existent-dir': No such file or directory |
| 57 | + ``` |
| 58 | +
|
| 59 | +## 2) Troubleshooting lato host con `libguestfs-tools` |
| 60 | +
|
| 61 | +A volte, una VM non riesce ad avviarsi completamente, rendendo inutili gli strumenti in-guest. In questi casi, è possibile diagnosticare i problemi ispezionando l'immagine del disco della VM direttamente dall'host utilizzando la potente suite `libguestfs-tools` (installabile con `sudo dnf install libguestfs-tools`). |
| 62 | +
|
| 63 | +### `virt-cat`: Lettura dei file da un disco guest |
| 64 | +
|
| 65 | +`virt-cat` consente la lettura dei file dall'interno dell'immagine disco di una VM senza montarla. Questo è perfetto per recuperare i file di log da un'istanza che non si avvia. |
| 66 | +
|
| 67 | +```bash |
| 68 | +# Dal host, leggere il file cloud-init.log dal disco della VM. |
| 69 | +sudo virt-cat -a /path/to/your-vm-disk.qcow2 /var/log/cloud-init.log |
| 70 | +``` |
| 71 | +
|
| 72 | +### `virt-inspector`: Ispezione approfondita del sistema |
| 73 | +
|
| 74 | +`virt-inspector` genera un report XML dettagliato del sistema operativo, delle applicazioni e della configurazione di una macchina virtuale. Questo è incredibilmente potente per l'analisi automatizzata. |
| 75 | +
|
| 76 | +- **Ottienere un rapporto completo:** |
| 77 | +
|
| 78 | + ```bash |
| 79 | + sudo virt-inspector -a your-vm-disk.qcow2 > report.xml |
| 80 | + ``` |
| 81 | +
|
| 82 | +- **Eseguire una query mirata:** È possibile convogliare il file XML a `xmllint` per estrarre informazioni specifiche. Questo esempio verifica la versione installata di `cloud-init` all'interno dell'immagine: |
| 83 | +
|
| 84 | + ```bash |
| 85 | + sudo virt-inspector -a your-vm-disk.qcow2 | xmllint --xpath "//application[name='cloud-init']/version/text()" - |
| 86 | + ``` |
| 87 | +
|
| 88 | +## 3. Errori comuni e come evitarli |
| 89 | +
|
| 90 | +### Errore 1: Errori YAML e di schema |
| 91 | +
|
| 92 | +I YAML non validi sono la causa più comune di errori. Un problema più complesso è rappresentato da un file YAML sintatticamente valido che viola la struttura prevista da `cloud-init` (ad esempio, un errore di battitura nel nome di un modulo). |
| 93 | +
|
| 94 | +- **Soluzione:** Utilizza il comando `cloud-init schema` per convalidare la configurazione _prima_ dell'avvio. Rileverà sia gli errori YAML che quelli strutturali. |
| 95 | +
|
| 96 | + ```bash |
| 97 | + # Convalidate il vostro file di user-data rispetto allo schema ufficiale |
| 98 | + cloud-init schema --config-file user-data.yml |
| 99 | + ``` |
| 100 | +
|
| 101 | + Se il file è valido, verrà visualizzato il messaggio “Valid cloud-config: user-data.yml”. In caso contrario, fornirà errori dettagliati. |
| 102 | +
|
| 103 | +### Errore 2: moduli dipendenti dalla rete non funzionanti |
| 104 | +
|
| 105 | +Se non si riesce a connettere alla rete, moduli come `packages` non funzioneranno. Controllare la configurazione di rete e la fase `Network` in `/var/log/cloud-init.log`. |
| 106 | +
|
| 107 | +## 4. Controllo dell'esecuzione di `cloud-init` |
| 108 | +
|
| 109 | +- **Forzare una riesecuzione:** per testare le modifiche su una VM in esecuzione, eseguire `sudo cloud-init clean --logs` seguito da `sudo reboot`. |
| 110 | +- **Disabilitazione di `cloud-init`:** per impedire l'esecuzione di `cloud-init` agli avvii successivi, creare un file sentinella: `sudo touch /etc/cloud/cloud-init.disabled`. |
| 111 | +- **Eseguire ad ogni avvio (`bootcmd`):** Utilizzare il modulo `bootcmd` per gli script che devono essere eseguiti ad ogni singolo avvio. Questo è raro ma utile per alcune diagnosi. |
| 112 | +
|
| 113 | +## Il passo successivo |
| 114 | +
|
| 115 | +Ora si dispone di una potente serie di strumenti per la risoluzione dei problemi sia sul lato ospite che sul lato host. Nel capitolo finale esamineremo il progetto `cloud-init` stesso, preparandovi ad esplorarne il codice sorgente e a contribuire alla comunity. |
0 commit comments