Cloud-init в Debian и Ubuntu: datasource, сеть и безопасное отключение

Зачем вообще нужен cloud-init и почему он «мешает»

cloud-init — стандартный механизм первичной инициализации виртуальных машин и облачных образов. Он читает метаданные провайдера (datasource), применяет сеть, задаёт hostname, добавляет SSH-ключи, создаёт пользователей и может выполнять команды на первом старте.

На «боевом» сервере cloud-init начинает мешать, когда продолжает считать себя источником истины и переигрывает то, что вы меняете руками. Самый частый сценарий: вы правите сеть, перезагружаетесь — и настройки откатываются; либо на Ubuntu Server вы правите netplan, а затем видите новый сгенерированный файл и неожиданно меняется схема сети.

Ниже — практический план: как понять активный datasource, где смотреть конфиги, что именно делает cloud-init network, как разрулить netplan и cloud-init, как корректно сделать cloud-init disable (частично или полностью), и как не потерять доступ по SSH во время сетевых изменений.

Как устроен cloud-init: стадии и источники данных

cloud-init работает по стадиям. Упрощённо это выглядит так:

• init — поиск и выбор datasource, базовая подготовка;
• config — применение конфигурации (пользователи, SSH, файлы, пакеты);
• final — финальные шаги (скрипты, сообщения, дополнительные действия).

Ключевая мысль: cloud-init берёт данные из datasource (NoCloud, ConfigDrive, OpenStack, EC2 и т. п.) и на их основе применяет настройки, включая сеть. Если datasource выбран «не тот» или метаданные не соответствуют вашему текущему состоянию — после reboot вы получите «сброс» к тому, что cloud-init считает правильным.

Где обычно лежит конфигурация:

• /etc/cloud/cloud.cfg — базовый конфиг (править его напрямую стоит только в крайнем случае);
• /etc/cloud/cloud.cfg.d/ — drop-in файлы для переопределений (это нормальная точка для админских правок).

Как понять, какой datasource сейчас используется

Перед любыми изменениями проверьте текущее состояние cloud-init и активный datasource:

cloud-init status --long
cloud-init query datasource
cloud-init query --all | head

Полезно посмотреть журналы стадий:

journalctl -u cloud-init -u cloud-config -u cloud-final --no-pager

И факты cloud-init, сохранённые на диске:

ls -la /var/lib/cloud/
cat /var/lib/cloud/instance/datasource

Если вы используете шаблоны/«золотые» образы, cloud-init становится критичным элементом процесса. В этом случае пригодится отдельная практика подготовки образов: как собирать golden image с cloud-init и не ловить сюрпризы.

cloud-init и сеть: почему настройки откатываются

Самая болезненная часть — сеть. На Ubuntu Server по умолчанию сеть управляется netplan, и cloud-init может генерировать netplan-конфиг из метаданных. Итог: вы правите один YAML, а cloud-init при следующей загрузке создаёт или обновляет другой — и сеть «переезжает».

В Debian варианты зависят от версии и образа: может быть ifupdown, systemd-networkd или иногда netplan. Но логика одна: если cloud-init управляет сетью, он будет продолжать применять конфигурацию из datasource.

Где cloud-init хранит сетевую конфигурацию и как он её применяет

На Ubuntu Server чаще всего встречаются:

• /etc/netplan/50-cloud-init.yaml — сгенерированный netplan-файл;
• /run/netplan/ — временные артефакты применения;
• логи: /var/log/cloud-init.log и /var/log/cloud-init-output.log.

Если в системе есть /etc/netplan/50-cloud-init.yaml, это практически прямое подтверждение сценария «netplan + cloud-init»: сеть описана метаданными и сгенерирована автоматически.

Проверка:

ls -la /etc/netplan/
cat /etc/netplan/50-cloud-init.yaml

Если рендер — systemd-networkd, добавьте быструю диагностику:

networkctl list
networkctl status

Почему опасно «просто перезапустить сеть» по SSH

Любой перезапуск сети на удалённой машине может оборвать SSH. Даже «правильный» конфиг может не примениться из-за имени интерфейса, маршрута по умолчанию, DNS или конфликтующих YAML в netplan.

Планируйте сетевые изменения так, будто вы потеряете доступ: держите под рукой консоль провайдера, используйте пробное применение, и только затем делайте reboot.

На Ubuntu Server для безопасного применения есть встроенный механизм:

sudo netplan try

Он применяет конфигурацию и ждёт подтверждения. Если подтверждения нет — откатывает, что часто спасает от «самоотключения» сервера.

Облачный VDS-сервер в России

Аренда виртуальных серверов с моментальным развертыванием инфраструктуры от 195₽ / мес

Подробнее

Как правильно отключить cloud-init и не сломать сервер

Под «cloud-init disable» обычно подразумевают два разных сценария: перестать управлять сетью или выключить cloud-init целиком. Правильный выбор зависит от того, используете ли вы провайдерские метаданные для SSH-ключей, hostname и автоматизации.

Вариант 1: отключить управление сетью, но оставить cloud-init для остального

Это самый безопасный и популярный вариант, если вам нужна стабильная сеть, но вы не хотите «ломать» остальные функции cloud-init (например, добавление ключей при пересоздании).

Создайте drop-in файл в /etc/cloud/cloud.cfg.d/, который отключает сетевую конфигурацию:

sudo tee /etc/cloud/cloud.cfg.d/99-disable-network-config.cfg > /dev/null <<'EOF'
network:
  config: disabled
EOF

Дальше сеть становится вашей зоной ответственности (netplan/systemd-networkd/ifupdown — что используется в системе).

Если в системе уже есть /etc/netplan/50-cloud-init.yaml, обычно действуют так:

1. Создают свой файл, например /etc/netplan/01-netcfg.yaml.
2. Проверяют его через netplan try.
3. После успешного применения переименовывают или удаляют 50-cloud-init.yaml, чтобы не было конфликтов по приоритетам.

Важно: netplan читает несколько файлов, а итоговый результат может зависеть от их порядка и пересечений. Держите конфигурацию однозначной.

Вариант 2: полное отключение cloud-init

Если вы уверены, что cloud-init больше не нужен на этом сервере (и вы не используете образ как шаблон), можно отключить его полностью маркером:

sudo touch /etc/cloud/cloud-init.disabled

Дополнительно можно выключить сервисы (на разных версиях набор юнитов может отличаться):

sudo systemctl disable --now cloud-init.service cloud-config.service cloud-final.service cloud-init-local.service

Проверка:

cloud-init status --long
systemctl status cloud-init.service --no-pager

Нюанс: полное отключение cloud-init может лишить вас удобных функций при клонировании/восстановлении (hostname, пересоздание SSH host keys, применение метаданных провайдера). Если это VDS, который вы планируете клонировать или разворачивать массово, чаще разумнее отключать только сеть.

Netplan и cloud-init: как перейти на ручной netplan без сюрпризов

Если цель — чтобы netplan был полностью вашим, используйте последовательность, которая минимизирует риск потери доступа:

1. Зафиксируйте текущую рабочую конфигурацию (IP/маска/шлюз/DNS), желательно в отдельной заметке.
2. Отключите управление сетью cloud-init через network: config: disabled.
3. Создайте собственный netplan YAML с понятным приоритетом (например, 01-netcfg.yaml).
4. Примените через netplan try и подтвердите.
5. Только после этого уберите 50-cloud-init.yaml, если он конфликтует или стал лишним.

Пример минимального netplan для статического IPv4 (адаптируйте интерфейс и адреса):

sudo tee /etc/netplan/01-netcfg.yaml > /dev/null <<'EOF'
network:
  version: 2
  renderer: networkd
  ethernets:
    eth0:
      dhcp4: false
      addresses:
        - 203.0.113.10/24
      routes:
        - to: default
          via: 203.0.113.1
      nameservers:
        addresses:
          - 1.1.1.1
          - 8.8.8.8
EOF

Безопасное применение:

sudo netplan try

Затем финальное:

sudo netplan apply

Что означает «после reboot сеть сбрасывается» в мире cloud-init

В связке Ubuntu Server + cloud-init обычно «сброс» происходит из-за двух механизмов:

• cloud-init заново применяет сетевую конфигурацию из datasource;
• netplan подхватывает сгенерированный файл и пересобирает конфигурацию сети.

Чтобы добиться поведения «как настроил — так и будет после reboot», выберите одну модель:

• либо cloud-init — источник истины (правки делаются через user-data/метаданные datasource);
• либо сеть выведена из-под контроля cloud-init (и вы управляете netplan вручную).

Промежуточный вариант «подправил руками, но cloud-init активен и верит метаданным» почти гарантирует сюрпризы после перезагрузки.

Как сбросить состояние cloud-init и заставить его переинициализироваться

Иногда нужно наоборот: вы изменили метаданные или datasource и хотите, чтобы cloud-init отработал заново. Для этого сбрасывают состояние:

sudo cloud-init clean

Более «жёстко», вместе с логами:

sudo cloud-init clean --logs

Далее перезагрузка:

sudo reboot

Осторожно: это может поменять сеть и пользователей. На сервере с доступом только по SSH заранее обеспечьте консольный доступ у провайдера.

/etc/cloud/cloud.cfg.d: практические паттерны для админов

Каталог /etc/cloud/cloud.cfg.d/ — нормальная точка для управляемых изменений (в отличие от прямой правки /etc/cloud/cloud.cfg). Хорошие привычки:

• Делайте одно изменение — один файл (например, 99-disable-network-config.cfg только про сеть).
• Используйте предсказуемые имена и приоритеты (например, 90-* для провайдерского, 99-* для локального).
• После правок сверяйте «фактическую» картину через cloud-init query.

Посмотреть, что cloud-init считает текущим набором значений:

cloud-init query --all | sed -n '1,160p'

Надежные SSL-сертификаты

Мы предлагаем широкий спектр SSL-сертификатов от GlobalSign по самым низким ценам. Поможем с покупкой и установкой SSL бесплатно!

Подробнее

Datasource: типовые проблемы и быстрая диагностика

Понимание datasource — ключ к предсказуемому поведению cloud-init. Типовые симптомы проблем:

• cloud-init долго висит на старте, ожидая метаданные;
• после reboot применяются «не те» сеть/hostname/ключи;
• в логах видно перебор разных datasource.

Быстрая диагностика:

cloud-init status --long
cloud-init query datasource
grep -n "DataSource" /var/log/cloud-init.log | tail -n 50

Иногда помогает ограничить список datasource в конфиге, чтобы ускорить загрузку и убрать ложные срабатывания. Но это настройка строго под платформу: если «отрезать» единственный рабочий источник метаданных, можно получить загрузку без нужной конфигурации.

Чек-лист: безопасные изменения cloud-init на проде

• Сначала проверьте состояние: cloud-init status --long и активный datasource.
• Если меняете сеть на Ubuntu — применяйте через netplan try и подтверждайте только после проверки.
• Правки делайте drop-in файлами в /etc/cloud/cloud.cfg.d/, а не в базовом /etc/cloud/cloud.cfg.
• Если сервер должен быть «стабильным», чаще всего достаточно отключить только сеть: network: config: disabled.
• Если готовите шаблон, заранее решите, что должно меняться при клонировании, и не отключайте cloud-init «на автомате».

Короткие ответы на частые вопросы

Ubuntu Server: почему появляется 50-cloud-init.yaml?

Потому что cloud-init сгенерировал netplan-конфиг из метаданных активного datasource. Это нормальное поведение для облачных образов. Если хотите ручное управление — отключите network config в cloud-init и заведите собственный netplan.

Можно ли отключить cloud-init «навсегда»?

Да: маркер /etc/cloud/cloud-init.disabled плюс отключение сервисов systemd. Но оцените последствия для клонирования/восстановления и работы с метаданными провайдера.

Как понять, что cloud-init больше не трогает сеть?

После добавления network: config: disabled проверьте, что после reboot не пересоздаётся /etc/netplan/50-cloud-init.yaml и не меняются IP/маршруты. Дополнительно просмотрите /var/log/cloud-init.log на предмет сетевых действий.