cloud-init в Azure — автоматизация создания VM

Зачем использовать cloud-init для автоматизации создания ВМ?

cloud-init — это инструмент автоматизации развертывания, поддерживаемый Canonical (разработчики Ubuntu) и принимаемый большинством провайдеров облачных услуг (Azure, AWS, Linode и другие). Он выполняет начальную настройку гостевой ОС: создание пользователей, добавление SSH‑ключей, установку пакетов, запись файлов и выполнение команд.

Кратко о принципе: вы пишете YAML‑скрипт с модулями cloud‑init, загружаете его в поле «Custom data» при создании VM, и cloud‑init выполняет инструкции при первом запуске.

Преимущества:

• Повторяемость: одна и та же конфигурация на сотнях ВМ.
• Скорость: меньше ручных кликов и ошибок.
• Централизация: конфигурация хранится в виде кода.

Важно: cloud-init работает не только в облаке — его можно использовать для виртуальных сред (VirtualBox, KVM, VMware) и на on‑prem серверах.

Шаг 1: Создание cloud-init скрипта

cloud-init использует модули для настройки разных частей системы. Примеры модулей:

• users — создание учётных записей
• write_files — запись файлов в файловую систему
• runcmd — запуск команд после инициализации
• packages, package_update, package_upgrade — работа с пакетами

Ниже — пример полного скрипта, который создаёт пользователя, добавляет SSH‑ключ, устанавливает пакеты, пишет файлы и включает UFW. Замените SSH‑ключ на свой и при необходимости смените имя пользователя.

vim: syntax=yaml  
  
# Add system users here  
users:  
  - name: mwiza  
  groups: users, sudo  
  shell: /bin/bash  
  gecos: mwiza  
  plain_text_passwd: Live-laugh-love12345G123  
  lock_passwd: false  
  ssh_authorized_keys:  
    - ssh-ed25519 BSHSDSDS3NzaC1sdfSDGSDSDJ1KSDB:PWELJWEEWeKBrkXWbLJBs;ldfkagfafk===C6li71Ra6i+NKkajdfi userkey@email.com  
  
# Install, update, and upgrade packages  
package_upgrade: true  
package_update: true  
package_reboot_if_require: true  
  
packages:  
  - traceroute  
  - net-tools  
  - fail2ban  
  
# Set locales  
locale: en_UK  
timezone: Etc/UTC  
keyboard:  
  layout: nb  
  
write_files:  
- path: /etc/salt/minion.d/master_ip_port.conf  
content: |  
master: salt  
master_port: 4506  
publish_port: 4505  
- path: /home/mwiza/cloud-init.txt  
content: |  
created by cloud-init in azure  
  
# Running Bash commands to configure software and services  
runcmd:  
  - ufw enable  
  - ufw allow ssh  
  - ufw allow 80  
  - systemctl enable ufw  
  
# Power off the VM after initialization is finalized  
shutdown: poweroff

Примечание: YAML чувствителен к отступам. Ошибки в отступах приведут к тому, что cloud‑init не распознает блоки.

Шаг 2: Создание ресурса виртуальной машины в Azure

1. Войдите в портал Azure (или создайте пробный аккаунт на azure.microsoft.com).
2. На главной странице нажмите Создать ресурс (Create a resource). Выберите Виртуальная машина (Virtual Machine).
3. Заполните параметры: имя ВМ, регион, ресурсную группу, тип диска, размер и пр.
4. В разделе «Authentication» выберите метод аутентификации. Автор рекомендует использование SSH‑ключей. Для простоты можно выбрать пароль, но безопаснее — ключи.

Важно: используйте осмысленные имена ресурсов и лейблы, чтобы потом легко управлять инвентарём.

Шаг 3: Добавление cloud-init скрипта в Azure

Перейдите на вкладку Advanced при создании VM. В поле «Custom data» вставьте ваш YAML‑скрипт. Это поле подхватит данные, и cloud‑init выполнит их при первом старте ОС.

Нажмите Review + create. Azure выполнит проверку валидности. Если проверки пройдены — создайте ВМ.

Шаг 4: Подключение к виртуальной машине и проверка

1. В обзоре ВМ найдите публичный IP и подключитесь по SSH: ssh user@PUBLIC_IP
2. Проверьте наличие созданных файлов, например:

ls -la /home/mwiza
cat /home/mwiza/cloud-init.txt

3. Убедитесь, что пакеты установлены (для Debian/Ubuntu):

sudo apt list --installed | grep fail2ban

4. Проверьте статус UFW:

sudo ufw status

5. Посмотрите логи cloud-init для детальной диагностики:

cat /var/log/cloud-init.log

Если что‑то пошло не так, логи помогут понять на каком этапе произошла ошибка.

Практическая методология (мини‑SOP) для развертывания через cloud-init

1. Разработайте базовый cloud‑init шаблон в репозитории (git). Храните его под версионным контролем.
2. Тестируйте в локальной VM (VirtualBox/KVM) перед запуском в облаке.
3. При каждом изменении создавайте ветку и прогоняйте проверку на тестовой ВМ.
4. Внедряйте через CI/CD (пример: при мердже в main — автоматически создаётся тестовая ВМ и прогоняются acceptance тесты).
5. Документируйте изменения и храните примеры использования в README.

Роль‑ориентированные чек‑листы

Администратор:

• Создать и проверить cloud‑init шаблон
• Убедиться, что SSH‑ключи корректны
• Настроить мониторинг и бэкап

DevOps инженер:

• Интегрировать cloud‑init в pipeline
• Автоматизировать тесты и откат
• Следить за совместимостью образов ОС

Офицер по безопасности:

• Проверить отсутствие plain‑text паролей
• Отключить SSH по паролю
• Проверить правила фаервола и fail2ban

Важно: избегайте хранения чувствительных данных в открытом виде в cloud‑init. Для секретов используйте Vault или Key Vault и подтягивайте их при первом запуске.

Критерии приёмки

• VM стартует без ошибок cloud‑init
• Ожидаемый пользователь создан и имеет sudo
• SSH‑ключ работает без запроса пароля
• Ожидаемые пакеты установлены
• UFW активирован и открыты нужные порты
• /var/log/cloud-init.log не содержит критических ошибок

Когда cloud-init не подходит (ограничения)

• Windows‑специфичные настройки. cloud‑init может работать на некоторых образах Windows, но это не основной сценарий.
• Сильная зависимость от конкретного образа ОС: некоторые кастомные образы могут не иметь cloud‑init или иметь его отключённым.
• Секреты и чувствительные данные: хранение паролей в явном виде небезопасно.

Альтернативы и дополняющие инструменты:

• Packer — для создания кастомных образов с предустановленным ПО.
• Configuration management (Ansible, Salt, Puppet) — для более сложной конфигурации после initial boot.
• Cloud‑provider tooling (Azure Resource Manager, ARM templates, Terraform) — для инфраструктуры как кода.

Тест‑кейсы и приёмочные проверки

1. Создать тестовую ВМ с шаблоном cloud‑init — убедиться, что она доходит до рабочего состояния.
2. Проверить idempotency: повторный запуск тех же инструкций не должен ломать систему.
3. Проверить восстановление: симулировать ошибку в скрипте и убедиться, что логи покажут причину.
4. Проверить безопасность: попытаться подключиться по паролю, если пароли должны быть отключены.

Безопасность и соответствие (GDPR, секреты)

• Не храните персональные данные или секреты в явном виде в cloud‑init. Используйте Azure Key Vault или HashiCorp Vault для управления секретами.
• Отключайте SSH‑аутентификацию по паролю и используйте ключи с passphrase.
• Логи cloud‑init могут содержать чувствительные данные — настраивайте ротацию и права доступа к логам.

Набор полезных хелперов — «cheat sheet»

Команды для отладки:

• Просмотр логов: cat /var/log/cloud-init.log
• Проверка статуса systemd‑unit: systemctl status cloud‑init
• Повторный запуск cloud‑init: sudo cloud-init clean && sudo cloud-init init && sudo cloud-init modules –mode=config

Советы по YAML:

• Используйте 2 пробела для отступов.
• Проверяйте синтаксис через yamllint.

Краткая галерея крайних случаев

• Образ без cloud‑init: скрипт игнорируется — проверяйте документацию образа.
• Неправильные отступы YAML: скрипт не выполняется; ошибки видны в логах.
• Сетевые политики блокируют исходящие запросы: скрипты, которые подтягивают пакеты, падают.

1‑строчный глоссарий

• cloud‑init: инструмент для автоматической начальной настройки Linux‑VM.
• Custom data: поле при создании VM в Azure, куда вставляют cloud‑init YAML.
• idempotency: способность повторного выполнения сценария без изменения результата.

Часто задаваемые вопросы

Можно ли использовать cloud‑init для Windows?

Некоторые образы Windows поддерживают cloud‑init, но это редкий сценарий. Для Windows обычно применяют средства Windows‑specific или провайдера.

Как передавать секреты безопасно?

Используйте Azure Key Vault или HashiCorp Vault. Вы можете подтянуть секрет в рантайме через безопасные вызовы, а не хранить в YAML.

Нужно ли перезагружать VM после cloud‑init?

Иногда требуются перезагрузки при установке ядра или комплексных пакетов. cloud‑init может инициировать перезагрузку автоматически.

Резюме

cloud‑init — простой и мощный инструмент для автоматизации создания и начальной настройки Linux‑виртуальных машин в Azure и других средах. Он повышает повторяемость и снижает ручной труд. Для безопасного и надёжного использования храните шаблоны в контроле версий, тестируйте в локальной среде и интегрируйте в CI/CD.