Cloud init что это

Cloud-init: автоматическая установка hostname для виртуальной машины

Внутри каждого шаблона для виртуальной машины в Облаке КРОК установлен cloud-init. Это великолепный инструмент для автоматизации рутинных операций в процессе начального запуска вашей виртуальной машины. В этой статье я расскажу, как автоматизировать установку имени сервера (hostname).

Как работает cloud-init

В каждом публичном Облаке (AWS, GCP, Azure) или частном Облаке (OpenStack или CloudStack) есть так называемый сервис метаданных. Задача этого сервиса предоставлять виртуальной машине информацию об окружении, в котором она запущена. Эта информация обычно как минимум содержит в себе:

Например, ваша виртуальная машина может самостоятельно узнать собственный hostname следующим образом:

Cloud-init в свою очередь представляет собой набор скриптов, поддерживаемых сообществом в актуальном состоянии, который настраивает вашу виртуальную машину на основании информации из сервиса метаданных.

У сервиса метаданных есть одно интересное поле, которое может быть изменено в любой момент жизненного цикла виртуальной машины — «пользовательские данные» (user-data), доступное внутри виртуальной машины по адресу:

Пользовательские данные сервиса метаданных используются для всевозможной автоматизации ваших шаблонов, например, автоматическая установка в процессе запуска необходимого ПО, задания имени сервера, установка и запуск ПО управления изменениями в конфигурации, т.к. Chef, Puppet или Ansible и т.д.

Сloud-init работает следующим образом: он читает данные настроек «Пользовательских данных» и, если они заданы в формате, который понимает cloud-init, то он может выполнять действия описанные в пользовательских данных, игнорируя настройки сервиса метаданных.

Задание имени хоста при загрузке виртуальной машины

Простейший пример «Пользовательских данных» — это задание имени хоста при загрузке виртуальной машины. Для этого в процессе создания виртуальной машины задайте «Пользовательские данные» следующим образом:

Источник

Автоматизируем деплой в vCloud с помощью Terraform и cloud-init

Provisioning

Прежде чем перейдём к подготовке образа ВМ, поговорим немного про provisioning виртуалок.

Или. составлять скрипты и вставлять их в раздел Customization script, в случае с vCloud?

Cloud-init работает с instance-data, документом, состоящим из трёх компонент:

Cloud metadata, содержит важные данные от облака. Например, instance id, адреса сетевых интерфейсов, хостнеймы.

Vendor data (опционально), несёт в себе дополнительные настройки от облака. Например, каких пользователей пользователь через веб-формы облака приказал создать, или какие пакеты надо доустановить.

User data (опционально). По формату идентично vendor data, но юзердата состоит из YAML-а, который пользователь скармливает cloud-init в свободной форме.

Полный список встроенных в cloud-init возможностей конфигурации (или модулей) доступен тут.

VMware и cloud-init

Подготавливаем шаблон

Возьмём за основу Ubuntu 20.04.3.

Загружаем ISO

Заходим в vCloud Director, там открываем меню сверху слева и переходим в Libraries:

Из Libraries попадаем в Media & Other, где нажимаем на ADD:

В качестве каталога выбираем любой, в котором в принципе можно хранить образы, выбираем ISO-файл на локальном диске, name подставится автоматически.

Как только медиа загрузится (задача загрузки будет висеть в нижней части экрана, в Recent Tasks), создаём пустой vApp, цепляем к нему какую-нибудь routed-сетку, дальше создаём VM со следующими параметрами:

В принципе, главное, чтобы Memory было не меньше гигабайта, и чтобы Operating System было Ubuntu Linux (64-bit)

Установка и настройка дистрибутива

Дальше устанавливаем убунту как вам хочется, из скриншотов ограничусь одним-единственным:

После установки и ребута заходим в root shell, делаем там apt update-upgrade:

Теперь, собственно, подготовка образа к cloud-init.

Удаляем сетевые конфиги netplan и cloud-init, созданные установщиком, чтобы не мешались по дороге:

А также говорим cloud-init не пытаться перетянуть одеяло с vmware tools. Идея в том, чтобы сначала open-vm-tools задавал сетевые параметры, а cloud-init делал всё остальное:

Настраиваем cloud-init через dpkg так, чтобы был только OVF datasource. То есть кнопкой пробел снимаем все галочки, кроме той, что рядом с OVF:

Наконец, удаляем данные cloud-init, чтобы при следующей загрузке системы он повторно инициализировался. Бонусом можно удалить логи open-vm-tools, чтобы впоследствии их было проще читать:

Гасим виртуалку через poweroff и также делаем ей Power Off в vCloud. Теперь она готова к шаблонизации.

Создание шаблона в vCloud

Здесь всё просто: открываем Actions нашего vApp и жмём на Add to Catalog, в открывшейся форме выбираем нужный каталог, в имени пишем что-нибудь понятное, типа ubuntu-20-04, и в поле When using this template выбираем Customize VM settings.

Мой девопс делает вкуснейшие терраформ-модули

Берётся стабильный (1.0.4) терраформ, 0.14 не про него, на него ставится vcd-провайдер:

Создаёт в той же папке какой-нибудь простой userdata.yaml:

И посыпает виртуалкой:

И. Стоп, а вонища user data где?

Загадка о OVF-датасорсе cloud-init

Сейчас будет рассказ о том, почему, собственно, этот туториал и был написан.

Как нам передать user data в cloud-init?

В terraform-ресурсе vcd_vapp_vm есть такой аргумент, как guest_properties:

Один из ключей к разгадке получен. Значит, в виртуалку можно передать набор ключ-значение, осталось понять, какие именно ключи.

For further information see a full working example in cloud-init’s source code tree in doc/sources/ovf

Отлично, живой пример! Открываем сорцы, и.

Примеры от 12 года, разумеется, без терраформа или чего-то такого.

Если вы вобьёте в любимый поисковик «vmware cloud-init», то найдёте несколько статей в блогах про то, как накурить cloud-init в vSphere через проперти guestinfo.metadata и guestinfo.userdata.

То есть, мы должны соорудить что-то типа такого?

Нет. К сожалению, если засунуть YAML как guestinfo.userdata, то cloud-init поведёт себя так, словно ничего в OVF не обнаружил.

Днями и ночами я копался над этой загадкой, пока не сдался и не залез в исходники cloud-init. Тут мне пригодилось знание Python и хорошая структурированность кодовой базы cloud-init.

Открываем сорцы. Ищем строку guestinfo. Находим такую функцию:

Мимо. Хотя давайте из любопытства выполним команду:

Получим XML с набором данных, а также с пропертями типа таких:

Ага! Значит, cloud-init получает наш набор пропертей, но они его по какой-то причине не устраивают?

Ищем места вызова функции, находим одно:

В этом же куске кода есть вызов read_ovf_environment(). Посмотрим на него:

Ага! Значит, cloud-init вычитывает проперти password, seedfrom, local-hostname, public-keys, instance-id и наш драгоценный user-data!

Пробуем прописать такое в Terraform-ресурсе:

Делаем экспорт логина-пароля в шелл, terraform apply, смотрим, какой адрес у полученной виртуалки в vCloud, пингуем его и пробуем подключиться:

Всё! Мы получили работающий шаблон Ubuntu, который можно раскатать в облако на основе vCloud Director.

Если что-то не выходит, обратите внимание на следующие ресурсы:

Доклады и блогпосты для дополнительного изучения cloud-init

Источник

☁️ Удалить cloud-init из Ubuntu

Что такое cloud-init

Облачные образы являются шаблонами операционной системы, и каждый экземпляр начинается как идентичный клон любого другого экземпляра.

Именно пользовательские данные дают каждому экземпляру облака индивидуальность, а cloud-init – это инструмент, который автоматически применяет пользовательские данные к вашим экземплярам.

Cloud-init – это многофакторный пакет defacto, который выполняет раннюю инициализацию облачного экземпляра.

Тем не менее, он не требуется для установки, когда вы не собираетесь использовать его возможности или вообще не собираетесь его использовать, поскольку у этой системы возможно просто нет подключения к Интернету.

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

Для людей, которым нравится, когда их система загружается очень быстро, лучше всего просто удалить cloud-init.

Следующие инструкции достаточно просты и работают в любом случае:

Подождите, пока VM загрузится, а затем войдите.

Если вы пользователь sudo, то вы можете просто выполнять с sudo от своего пользователя.

Выполните следующую команду, чтобы очистить файл конфигурации 90_dpkg.cfg (значение None).

После этого вы можете удалить cloud-init.

После очистки просто удалите папки cloud-init и перезагрузите компьютер.

Вот и все, это самый простой способ удалить cloud-init из Ubuntu 🙂

Источник

Обновление и установка пакетов с помощью cloud-init на виртуальной машине Linux в Azure

Применимо к: ✔️ виртуальные машины Linux ✔️ гибкие масштабируемые наборы

В этой статье показано, как с помощью cloud-init обновлять пакеты на виртуальной машине или в масштабируемом наборе виртуальных машин в процессе подготовки в Azure. Эти скрипты cloud-init выполняются при первой загрузке, если в Azure подготовлены все нужные ресурсы. Дополнительные сведения о встроенной поддержке cloud-init в Azure и поддерживаемых дистрибутивах Linux см. в обзоре cloud-init.

Обновление виртуальной машины с помощью cloud-init

В этом примере мы будем использовать Azure Cloud Shell. Чтобы увидеть процесс обновления в действии, создайте файл с именем cloud_init_upgrade.txt и вставьте в него следующую конфигурацию:

Нажмите кнопку Попробовать в блоке кода ниже, чтобы открыть Cloud Shell. Чтобы создать файл и просмотреть список доступных редакторов в Cloud Shell, введите следующее:

Перед развертыванием необходимо создать группу ресурсов с помощью команды az group create. Группа ресурсов Azure является логическим контейнером, в котором происходит развертывание ресурсов Azure и управление ими. В следующем примере создается группа ресурсов с именем myResourceGroup в расположении eastus.

Подключитесь по протоколу SSH к общедоступному IP-адресу виртуальной машины, который указан в выходных данных предыдущей команды. Введите свой общедоступный IP-адрес в качестве значения для publicIpAddress, как показано здесь:

Запустите средство управления пакетами и проверьте наличие обновлений.

Дальнейшие действия

Дополнительные примеры изменения конфигурации с помощью cloud-init см. в следующих статьях:

Источник

Поддержка cloud-init для виртуальных машин в Azure

Применимо к: ✔️ виртуальные машины Linux ✔️ гибкие масштабируемые наборы

Из этой статьи можно узнать об имеющейся поддержке cloud-init для настройки виртуальной машины или масштабируемых наборов виртуальных машин во время подготовки в Azure. Эти настройки конфигурации cloud-init выполняются при первой загрузке, если в Azure подготовлены все нужные ресурсы.

Подготовка виртуальной машины — это процесс, при котором Azure передает значения параметров создания виртуальной машины, такие как имя узла, имя пользователя, пароль и т. д., и делает их доступными для виртуальной машины при загрузке. «Агент подготовки» принимает эти значения, настраивает виртуальную машину, а, закончив, передает отчет.

Azure поддерживает два агента подготовки — cloud-init и агент Linux для Azure (WALA).

Общие сведения о cloud-Init

Cloud-init — широко используемое средство для настройки виртуальной машины Linux при ее первой загрузке. Вы можете использовать cloud-init для установки пакетов, записи файлов или настройки пользователей и параметров безопасности. Так как cloud-init вызывается при начальной загрузке, к вашей конфигурации не нужно применять какие-либо дополнительные действия или агентов. Дополнительные сведения о том, как правильно отформатировать файлы, #cloud-config или другие входные данные, см. на сайте документации по cloud-init. Файлы #cloud-config — это текстовые файлы, закодированные в формате base64.

Кроме того, cloud-init работает с разными дистрибутивами. Например, для установки пакета не используется apt-get install или yum install. Вместо этого можно определить список пакетов для установки. Cloud-init автоматически использует собственный инструмент управления пакетами из выбранного дистрибутива.

Мы активно взаимодействуем с утвержденными партнерами, создающими дистрибутивы Linux, чтобы в Azure Marketplace присутствовали образы с поддержкой cloud-init. Эти образы обеспечивают бесперебойную работу развертываний и конфигураций cloud-init с виртуальными машинами и масштабируемыми наборами виртуальных машин. Сначала мы активно сотрудничаем с нашими утвержденными партнерами, работающими над дистрибутивами Linux, и вышестоящими источниками, чтобы обеспечить работу функций cloud-init с ОС в Azure, а затем пакеты обновляются и переводятся в открытый доступ через репозитории пакетов дистрибутивов.

Доступ к cloud-init доверенной ОС с дистрибутивом Linux в Azure предоставляется в два этапа — поддержка пакета и поддержка образа:

Canonical

CentOS

OpenLogic теперь носит название Rogue Wave Software.

Oracle;

SUSE SLES

Debian

deb10u1debian (поколение 2)debian-1010-cloudinit-gen20.20201013.422дада — поддержка из пакета версии: 20.2-2

В настоящее время Azure Stack поддерживает подготовку образов с поддержкой cloud-init.

Разница между cloud-init и агентом Linux (WALA)

WALA — это уникальный агент платформы Azure, использующийся для подготовки и настройки виртуальных машин и обработки расширений Azure.

Мы улучшили задачу настройки виртуальных машин для использования cloud-init вместо агента Linux таким образом, чтобы имеющиеся пользователи cloud-init смогли применять свои текущие скрипты cloud-init, а новые клиенты могли использовать преимущества функциональных возможностей cloud-init. Если у вас уже есть скрипты cloud-init для настройки систем Linux, то для включения их обработки с использованием cloud-init дополнительные параметры не требуются.

Cloud-init не может обрабатывать расширения Azure, поэтому для обработки расширений в образе должен присутствовать WALA, однако его код подготовки необходимо отключить, чтобы конвертируемые поддерживаемые дистрибутивы Linux могли подготовить cloud-init, а затем установить и правильно настроить WALA.

Конфигурация cloud-init применяется к виртуальным машинам без временных ограничений, которые не приведут к сбою развертывания по времени. К WALA это не относится. Если изменить значения WALA по умолчанию на пользовательские данные обработки, он не сможет превысить общую квоту времени подготовки виртуальной машины в 40 минут, и тогда операция создания виртуальной машины завершится ошибкой.

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

Начиная с cloud-init 21.2, можно использовать cloud-init для подготовки виртуальной машины в Azure без драйвера UDF. Если драйвер UDF в образе недоступен, cloud-init использует для подготовки виртуальной машины метаданные, доступные в Службе метаданных экземпляров Azure. Обратите внимание, что этот вариант применим только для ключа SSH и данных пользователя. Чтобы передать виртуальной машине пароль или пользовательские данные во время подготовки, необходимо использовать драйвер UDF.

Развертывание виртуальной машины с поддержкой cloud-init

Развертывать виртуальную машину с включенным cloud-init так же просто, как и ссылаться на распределение с включенным cloud-init во время развертывания. Распространители дистрибутивов Linux должны включать и интегрировать cloud-init в свои базовые опубликование образы Azure. Убедившись, что в образе, который нужно развернуть, включен cloud-init, вы можете использовать Azure CLI для его развертывания.

Первым шагом при развертывании образа является создание группы ресурсов с использованием команды az group create. Группа ресурсов Azure является логическим контейнером, в котором происходит развертывание ресурсов Azure и управление ими.

В следующем примере создается группа ресурсов с именем myResourceGroup в расположении eastus.

Последним шагом является создание виртуальной машины с использованием команды az vm create.

Вы также можете развернуть виртуальную машину с поддержкой cloud-init, передав параметры в шаблоне ARM.

Устранение неполадок cloud-init

Дополнительные сведения о журнале cloud-init см. в документации по cloud-init

Дальнейшие действия

Примеры изменения конфигураций с помощью cloud-init см. в следующих документах:

Источник