Что такое 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 при создании сервера