6. Виправлення неполадок cloud-init

Виправлення неполадок cloud-init¶

У будь-якій складній автоматизованій системі все зрештою піде не так. Коли конфігурація cloud-init дає збій, знання того, як систематично діагностувати проблему, є важливою навичкою. Цей розділ є вашим посібником з криміналістики «хмарної ініціалізації», що охоплює методи усунення несправностей як у гостьовій системі, так і на хості.

1. Набір інструментів для усунення неполадок у гостьовій системі¶

Коли ви можете отримати доступ до запущеного екземпляра, cloud-init надає кілька команд та журналів, щоб показати вам, що сталося.

Стовп 1: Команда cloud-init status¶

Це ваш перший порт заходу. Він надає загальний огляд стану cloud-init.

Перевірте завершення cloud-init: cloud-init status (У разі успішного виконання буде показано status: done)
Зачекайте завершення cloud-init: cloud-init status --wait (Це корисно в скриптах для призупинення виконання до завершення cloud-init)

Стовп 2: Головний журнал (`/var/log/cloud-init.log`)¶

Цей файл — золоте джерело істини: детальний, хронологічний запис кожного етапу та модуля. Коли вам потрібно точно дізнатися, що сталося, подивіться сюди. Пошук у цьому файлі за запитом «ПОМИЛКА» або «ПОПЕРЕДЖЕННЯ» часто безпосередньо приведе вас до проблеми.

Стовп 3: Журнал виводу (`/var/log/cloud-init-output.log`)¶

Цей журнал фіксує повні stdout та stderr усіх скриптів, виконаних cloud-init (наприклад, з runcmd). Якщо модуль запустився, але ваш скрипт у ньому завершився збоєм, повідомлення про помилку буде в цьому файлі.

Практичний досвід: налагодження невдалої команди runcmd

Створіть user-data.yml з runcmd, який містить незначну помилку:
```
cat <<EOF > user-data.yml
#cloud-config
runcmd:
  - [ ls, /non-existent-dir ]
EOF
```
Завантажте віртуальну машину з цими даними. cloud-init status повідомить status: done, оскільки сам модуль runcmd виконано успішно.
Однак, файл /var/log/cloud-init-output.log міститиме фактичну помилку команди ls, яка покаже, що сталося:
```
ls: cannot access '/non-existent-dir': No such file or directory
```

2) Виправлення неполадок на стороні хоста за допомогою `libguestfs-tools`¶

Іноді віртуальна машина не завантажується повністю, що робить інструменти гостьової системи марними. У цих випадках ви можете діагностувати проблеми, перевіривши образ диска віртуальної машини безпосередньо з хоста за допомогою потужного пакету libguestfs-tools (встановіть за допомогою sudo dnf install libguestfs-tools).

`virt-cat`: Читання файлів з гостьового диска¶

virt-cat дозволяє читати файли з образу диска віртуальної машини без його монтування. Це ідеально підходить для отримання файлів журналів з екземпляра, який не завантажується.

# З хоста прочитайте файл cloud-init.log з диска віртуальної машини.
sudo virt-cat -a /path/to/your-vm-disk.qcow2 /var/log/cloud-init.log

`virt-inspector`: Глибока перевірка системи¶

virt-inspector генерує детальний XML-звіт про операційну систему, програми та конфігурацію віртуальної машини. Це неймовірно потужний інструмент для автоматизованого аналізу.

Отримати повний звіт:

sudo virt-inspector -a your-vm-disk.qcow2 > report.xml

Виконайте цільовий запит: Ви можете передати XML-код до xmllint для отримання певної інформації. У цьому прикладі перевіряється встановлена версія cloud-init всередині образу:
```
sudo virt-inspector -a your-vm-disk.qcow2 | xmllint --xpath "//application[name='cloud-init']/version/text()" -
```

3. Поширені пастки та як їх уникнути¶

Пастка 1: Помилки YAML та схеми¶

Недійсний YAML є найпоширенішою причиною збоїв. Більш складна проблема — це синтаксично коректний YAML-файл, який порушує очікувану структуру cloud-init (наприклад, друкарська помилка в назві модуля).

Рішення: Використовуйте команду cloud-init schema для перевірки конфігурації перед завантаженням. Він виявляє як помилки YAML, так і структурні помилки.
```
# Validate your user-data file against the official schema
cloud-init schema --config-file user-data.yml
```

Якщо файл дійсний, буде надруковано Valid cloud-config: user-data.yml. Якщо ні, то буде надано детальну інформацію про помилки.

Пастка 2: Збій мережево-залежних модулів¶

Якщо мережа не вдається запуститися, такі модулі, як packages, не зможуть запуститися. Перевірте конфігурацію мережі та етап Network у /var/log/cloud-init.log.

4. Керування виконанням `cloud-init`¶

Примусовий повторний запуск: Щоб перевірити зміни на запущеній віртуальній машині, виконайте команду sudo cloud-init clean --logs, а потім sudo reboot.
Вимкнення cloud-init: Щоб запобігти запуску cloud-init під час наступних завантажень, створіть файл sentencel: sudo touch /etc/cloud/cloud-init.disabled.
Запуск під час кожного завантаження (bootcmd): Використовуйте модуль bootcmd для скриптів, які мають виконуватися під час кожного завантаження. Це трапляється рідко, але корисно для специфічної діагностики.

Що далі¶

Тепер ви оснащені надійним набором інструментів для усунення несправностей як у гостьовій системі, так і на хості. В заключному розділі ми розглянемо сам проєкт cloud-init, підготувавши вас до вивчення його вихідного коду та внесення вкладу в спільноту.

Author: Wale Soyinka

Contributors: Steven Spencer, Ganna Zhyrnova