Версия: 22.1
Cloud-init - это инструмент, который широко используется в экосистеме облачных вычислений для настройки виртуальных машин при их первоначальном запуске. Он обеспечивает автоматизацию процесса настройки операционной системы и приложений на виртуальной машине, что позволяет создавать и масштабировать инфраструктуру облачных вычислений более эффективно.
Контактная информация:
Официальный сайт
Лицензия:
GPL3
Полный список доступных параметров конфигурации: Cloud-init documentation
Основной файл конфигурации —
/etc/cloud/cloud.cfg
. При необходимости дополнительные *.cfg файлы для загрузки можно разместить в формате/etc/cloud/cloud.cfg.d
. Все их содержимое будет объединено.
Конфигурация по умолчанию, поставляемая с Cloud-init 19.3 и более поздних версий, должна работать «из коробки» с большинством основных облачных сред. Следует выполнить следующее:
В зависимости от варианта использования может потребоваться адаптировать конфигурацию по умолчанию.
Конфигурация по умолчанию включает следующее содержимое:
users:
- default
Пользователи, которых необходимо добавить в систему.
Имя default
— это ссылка на default_user
раздел system_info
, но синтаксис поддерживает настройку произвольных пользователей с множеством опций. Первый пользователь в этом списке будет рассматриваться как "пользователь по умолчанию" другими модулями, например, тем, который настраивает SSH-ключи, передаваемые из облачной среды.
disable_root: true
Отключить доступ к SSH для root. Также можно удалить пароль пользователя root на образе облачной системы.
# passwd -d root
system_info:
default_user:
name: superadmin
lock_passwd: true
gecos: arch Cloud User
groups: [wheel, adm]
sudo: ["ALL=(ALL) NOPASSWD:ALL"]
shell: /bin/bash
Это спецификация пользователя дистрибутива по умолчанию:
adm
и wheel
;sudo
использование без пароляСледует обратить внимание, что указанный здесь пользователь будет создан только в том случае, если в приведенный выше раздел включен специальный пользователь «по умолчанию» users:(или этот раздел полностью опущен).
Источники данных определяют, как метаданные экземпляра извлекаются во время загрузки. Это зависит от облачной среды (OpenStack, AWS, OpenNebula и т. д.), в которой запускается экземпляр. Внутри это преобразуется в соответствующий модуль, который реализует несколько методов, определенных в общем интерфейсе.
В конфигурации по умолчанию источники данных не указаны, а это означает, что Cloud-init попытается автоматически определить облачную среду. Однако некоторые среды не могут быть обнаружены или для работы может потребоваться специальная настройка. В этом случае используемые источники данных могут быть явно указаны и настроены. Следует обратиться к списку известных источников данных в документации.
Пример добавления списка источников данных, которые будут использоваться в /etc/cloud/cloud.cfg
:
datasource_list: [ NoCloud, ConfigDrive, OpenNebula, Azure, AltCloud, OVF, MAAS, GCE, OpenStack, CloudSigma, Ec2, CloudStack, None ]
Это указывает Cloud-init, какие модули загружать при попытке загрузки метаданных экземпляра. При желании для каждого источника данных могут быть переданы дополнительные параметры конфигурации следующим образом:
datasource:
OpenStack:
metadata_urls: [ 'http://169.254.169.254:80' ]
dsmode: net
Приведенная выше конфигурация указывает источнику данных OpenStack использовать URL-адрес http://169.254.169.254:80
для загрузки метаданных и запуска после инициализации сети, оба из которых являются поведением по умолчанию и могут быть опущены.
Cloud-init поставляется с набором модулей, которые можно включить или отключить в конфигурации.
Тот факт, что модуль включен, обычно не означает, что он действительно что-то будет делать. Однако он проверит, была ли передана какая-либо соответствующая ему конфигурация, например, из облачной среды через источник данных. Только тогда он попытается действовать. Таким образом, включение всех модулей обычно помогает максимизировать совместимость с облачными средами. Тем не менее, модули, о которых известно, что они не нужны, можно удалить из конфигурации, например, для сокращения времени запуска. Сloud-init analyze можно использовать на загруженном экземпляре, чтобы увидеть, сколько времени было потрачено на отдельные модули.
Некоторые модули сообщают Cloud-init, для каких дистрибутивов они проверены. Даже если указать, что их необходимо запустить, они откажутся запускаться, если дистрибутив, указанный в cloud.cfg
, не является одним из проверенных дистрибутивов для этого модуля. Если нужно переопределить это поведение, чтобы все равно запустить модуль на UBlinux, следует добавить модуль в раздел unverified_modules
в конфигурации облака, например:
unverified_modules: ['ssh-import-id']
Пакет cloud-init
предоставляет четыре systemd.service
, два systemd.target
и systemd.generator
, зависимости которых организованы таким образом, что они активируются в следующем порядке:
Дополнительную информацию см. также в документации по этапам загрузки Cloud-init.
mkdir cloud-init-example
cd cloud-init-example
Скопировать или скачать в этот каталог подготовленный образ виртуальной машины с поддержкой cloud-init.
Далее следует описать данные для cloud-init в конфигурационном файле формата yaml. Для этого необходимо создать файл "user-data.yaml"
и добавить параметры конфигурации.
Пример минимальной конфигурации, задающей только ключ для пользователя root. Вместо <YOUR_PUBLIC_KEY> нужно подставить публичный ключ:
#cloud-config
users:
- name: root
ssh_authorized_keys:
- <YOUR_PUBLIC_KEY>
cloud-localds my-seed.img user-data.yaml
Для преобразования конфигурационного файла в метаданные потребуется программа cloud-localds из пакета cloud-utils.
Для использования kvm пользователь должен быть в группе vmusers.
qemu -machine accel=kvm -m 2G -cpu host -smp 2 -drive file=alt-sisyphus-cloud-x86_64.qcow2,if=virtio -drive file=my-seed.img,if=virtio,format=raw,force-share=on,read-only=on -daemonize -display none -nic user,hostfwd=tcp::22222-:22
ssh root@localhost -p 22222
Установить можно пакетом:
Для установки следует воспользоваться утилитой "Установка и удаление программ".
Пакет, необходимый для установки:
Внимание! Если система загружена в режиме полного сохранения, то внесенные изменения в систему будут сохранены после перезагрузки.
Если режим загрузки другой, то рекомендуется воспользоваться утилитой "Сохранение изменений" до перезагрузки системы.