Що таке cloud-init і навіщо він потрібен

cloud-init — стандартний інструмент для автоматичного налаштування сервера під час першого запуску. Він читає конфігурацію, передану під час створення VPS (так званий user-data), і на її основі створює користувачів, встановлює пакети, прописує SSH-ключі та виконує довільні команди — усе це без ручного входу на сервер після його створення.

Сенс у тому, щоб не повторювати ті самі кроки після першого підключення до VDS по SSH: базовий захист, потрібних користувачів і оновлення системи застосовують автоматично ще до першого логіна.

Де шукати cloud-init на вже створеному VPS

Більшість актуальних образів Ubuntu і Debian у хостинг-провайдерів уже включають cloud-init. Перевірити наявність і версію допоможе команда:

cloud-init --version
systemctl status cloud-init

Файли конфігурації, застосовані під час створення сервера, зберігаються в /var/lib/cloud/instance/, а сирі дані, передані панеллю керування — в /var/lib/cloud/instance/user-data.txt. Це стане в пригоді, коли треба з'ясувати, що саме виконалося під час старту сервера.

Структура user-data: мінімальний робочий приклад

Конфігурація cloud-init пишеться у форматі YAML і обов'язково починається з рядка #cloud-config у першому рядку файлу. Мінімальний приклад, який оновлює пакети і задає часовий пояс:

#cloud-config
package_update: true
package_upgrade: true
timezone: Europe/Berlin

Відступи в YAML важливі: застосовуйте пробіли, а не табуляцію, інакше конфігурація не спрацює, і в логах з'явиться помилка парсингу.

Створення користувача, SSH-ключів і пакетів

Повніший приклад створює непривілейованого користувача з доступом по sudo, додає його публічний SSH-ключ і встановлює потрібні пакети:

#cloud-config
users:
  - name: deploy
    groups: sudo
    shell: /bin/bash
    sudo: 'ALL=(ALL) NOPASSWD:ALL'
    ssh_authorized_keys:
      - ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAA... user@laptop

packages:
  - nginx
  - fail2ban
  - unattended-upgrades

runcmd:
  - systemctl enable fail2ban
  - systemctl start fail2ban

Секція runcmd виконує довільні shell-команди після встановлення пакетів — туди ж додають базові кроки зі статті про перші кроки після купівлі VDS, щоб сервер був захищений одразу після створення.

Як передати user-data під час створення сервера

У панелі керування хостинг-провайдера під час замовлення VPS зазвичай є поле "User data" або "Cloud-init script" на кроці налаштування сервера — туди вставляють весь YAML-файл цілком. Коли сервер створюється через CLI-утиліту хмари, файл передають окремим прапорцем, наприклад:

--user-data-file ./cloud-config.yaml

Важливо: user-data за замовчуванням застосовується лише під час першого запуску інстансу. Повторне передавання конфігурації на вже працюючому сервері вимагає примусового скидання стану cloud-init командою cloud-init clean і перезавантаження — робіть це свідомо, повторний запуск здатен перестворити користувачів або перевстановити пакети.

Відлагодження: коли cloud-init не спрацював

Коли після створення сервера очікувані зміни не застосувалися, дивіться логи виконання:

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

Другий файл містить саме вивід команд з runcmd та встановлення пакетів — там зазвичай видно конкретну помилку. Чек-лист:

Перевірте відступи і синтаксис YAML — одна зайва табуляція ламає весь файл.
Переконайтеся, що перший рядок файлу — точно #cloud-config.
Дивіться обидва логи: cloud-init.log для процесу і cloud-init-output.log для виводу команд.
Після ручного відкриття портів у файрволі звіртеся зі статтею про налаштування UFW на VDS, коли runcmd змінював правила фільтрації.
Для повторного застосування конфігурації застосовуйте cloud-init clean і перезавантаження, а не ручне редагування системи.

cloud-init: автоналаштування VPS під час створення