Что такое cloud init

cloud-init support for virtual machines in Azure

Applies to: вњ”пёЏ Linux VMs вњ”пёЏ Flexible scale sets

This article explains the support that exists for cloud-init to configure a virtual machine (VM) or virtual machine scale sets at provisioning time in Azure. These cloud-init configurations are run on first boot once the resources have been provisioned by Azure.

VM Provisioning is the process where the Azure will pass down your VM Create parameter values, such as hostname, username, password etc., and make them available to the VM as it boots up. A ‘provisioning agent’ will consume those values, configure the VM, and report back when completed.

Azure supports two provisioning agents cloud-init, and the Azure Linux Agent (WALA).

cloud-init overview

cloud-init is a widely used approach to customize a Linux VM as it boots for the first time. You can use cloud-init to install packages and write files, or to configure users and security. Because cloud-init is called during the initial boot process, there are no additional steps or required agents to apply your configuration. For more information on how to properly format your #cloud-config files or other inputs, see the cloud-init documentation site. #cloud-config files are text files encoded in base64.

cloud-init also works across distributions. For example, you don’t use apt-get install or yum install to install a package. Instead you can define a list of packages to install. cloud-init automatically uses the native package management tool for the distro you select.

We are actively working with our endorsed Linux distro partners in order to have cloud-init enabled images available in the Azure Marketplace. These images will make your cloud-init deployments and configurations work seamlessly with VMs and virtual machine scale sets. Initially we collaborate with the endorsed Linux distro partners and upstream to ensure cloud-init functions with the OS on Azure, then the packages are updated and made publicly available in the distro package repositories.

There are two stages to making cloud-init available to the endorsed Linux distro OS’s on Azure, package support, and then image support:

Canonical

CentOS

OpenLogic is now Rogue Wave Software

Oracle

SUSE SLES

Debian

Currently Azure Stack will support the provisioning of cloud-init enabled images.

What is the difference between cloud-init and the Linux Agent (WALA)?

WALA is an Azure platform-specific agent used to provision and configure VMs, and handle Azure extensions.

We are enhancing the task of configuring VMs to use cloud-init instead of the Linux Agent in order to allow existing cloud-init customers to use their current cloud-init scripts, or new customers to take advantage of the rich cloud-init configuration functionality. If you have existing investments in cloud-init scripts for configuring Linux systems, there are no additional settings required to enable cloud-init process them.

cloud-init cannot process Azure extensions, so WALA is still required in the image to process extensions, but will need to have its provisioning code disabled, for endorsed Linux distros images that are being converted to provision by cloud-init, they will have WALA installed, and setup correctly.

cloud-init configurations applied to VMs do not have time constraints and will not cause a deployment to fail by timing out. This is not true for WALA, if you change the WALA defaults to process custom-data, it cannot exceed the total VM provisioning time allowance of 40mins, if so, the VM Create will fail.

cloud-init VM provisioning without a UDF driver

Beginning with cloud-init 21.2, you can use cloud-init to provision a VM in Azure without a UDF driver. If a UDF driver isn’t available in the image, cloud-init uses the metadata that’s available in the Azure Instance Metadata Service to provision the VM. Note that this option works only for SSH key and user data. To pass in a password or custom data to a VM during provisioning, you must use a UDF driver.

Deploying a cloud-init enabled Virtual Machine

Deploying a cloud-init enabled virtual machine is as simple as referencing a cloud-init enabled distribution during deployment. Linux distribution maintainers have to choose to enable and integrate cloud-init into their base Azure published images. Once you have confirmed the image you want to deploy is cloud-init enabled, you can use the Azure CLI to deploy the image.

The first step in deploying this image is to create a resource group with the az group create command. An Azure resource group is a logical container into which Azure resources are deployed and managed.

The following example creates a resource group named myResourceGroup in the eastus location.

The next step is to create a file in your current shell, named cloud-init.txt and paste the following configuration. For this example, create the file in the Cloud Shell not on your local machine. You can use any editor you wish. Enter sensible-editor cloud-init.txt to create the file and see a list of available editors. Choose #1 to use the nano editor. Make sure that the whole cloud-init file is copied correctly, especially the first line:

cloud-init has multiple input types, cloud-init will use first line of the customData/userData to indicate how it should process the input, for example #cloud-config indicates that the content should be processed as a cloud-init config.

Press Ctrl + X to exit the file, type y to save the file, and press Enter to confirm the file name on exit.

The final step is to create a VM with the az vm create command.

You can also deploy a cloud-init enabled VM by passing the parameters in ARM template.

Troubleshooting cloud-init

Not every module failure results in a fatal cloud-init overall configuration failure. For example, using the runcmd module, if the script fails, cloud-init will still report provisioning succeeded because the runcmd module executed.

For more details of cloud-init logging, refer to the cloud-init documentation

Next steps

For cloud-init examples of configuration changes, see the following documents:

Источник

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, то он может выполнять действия описанные в пользовательских данных, игнорируя настройки сервиса метаданных.

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

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

Источник

Руководство. Настройка виртуальной машины Linux при первой загрузке с помощью cloud-init в Azure

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

В рамках предыдущего руководства вы узнали, как применить протокол SSH к виртуальной машине и установить nginx. Для быстрого и согласованного создания виртуальных машин, как правило, применяются средства автоматизации. Наиболее распространенный подход к настройке виртуальной машины при первой загрузке — использование cloud-init. Из этого руководства вы узнаете, как выполнить следующие задачи:

Обзор cloud-Init

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

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

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

Создание файла конфигурации cloud-init

Чтобы посмотреть, как работает cloud-init, создайте виртуальную машину для установки сервера NGINX и запуска простого приложения Node.js Hello World. Приведенная ниже конфигурация cloud-init устанавливает требуемые пакеты, создает приложение Node.js, а затем инициализирует и запускает это приложение.

Чтобы узнать больше о параметрах конфигурации cloud-init, ознакомьтесь с примерами конфигурации cloud-init.

Создание виртуальной машины

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

Чтобы разрешить передачу веб-трафика для виртуальной машины, откройте порт 80 для Интернета командой az vm open-port.

Тестирование веб-приложения

Внедрение сертификатов из Key Vault

В этом дополнительном разделе описывается, как безопасно хранить сертификаты в Azure Key Vault и внедрять их во время развертывания виртуальных машин. Вместо того, чтобы использовать пользовательский образ со встроенными сертификатами, можно использовать этот процесс, чтобы обеспечить внедрение наиболее актуальных сертификатов в виртуальную машину при ее первом запуске. При этом сертификат никогда не покидает платформу Azure и не предоставляется в сценарии, журнале командной строки или шаблоне.

Azure Key Vault защищает криптографические ключи и секреты, в том числе сертификаты и пароли. Key Vault помогает оптимизировать управление ключами и позволяет поддерживать контроль над ключами, которые предоставляют доступ к вашим данным и шифруют их. В этом сценарии вводятся некоторые понятия Key Vault, относящиеся к созданию и использованию сертификата. Впрочем, это не все общие сведения о том, как использовать Key Vault.

Далее описывается, как:

создать Azure Key Vault;

Сначала создайте Key Vault командой az keyvault create и включите его использование при развертывании виртуальной машины. У каждого Key Vault должно быть уникальное имя в нижнем регистре. Замените mykeyvault в следующем примере собственным уникальным именем Key Vault.

Создание сертификата и его сохранение в Key Vault

Для использования в рабочей среде следует импортировать действительный сертификат, подписанный доверенным поставщиком, выполнив команду az keyvault certificate import. В следующем примере в этом руководстве показано, как можно командой az keyvault certificate create создать самозаверяющий сертификат, использующий политику сертификата по умолчанию.

Подготовка сертификата для использования с виртуальной машиной

Чтобы использовать сертификата во время создания виртуальной машины, получите идентификатор сертификата, выполнив команду az keyvault secret list-versions. Виртуальной машине требуется сертификат в определенном формате, чтобы вставить его во время загрузки. Поэтому преобразуйте сертификат с помощью команды az vm secret format. Следующий пример присваивает переменным результаты этих команд, чтобы их было удобно использовать в дальнейшем.

Создание конфигурации cloud-init для защиты сервера NGINX

Создание безопасной виртуальной машины

Чтобы разрешить безопасную передачу веб-трафика для виртуальной машины, откройте порт 443 для Интернета командой az vm open-port.

Тестирование защищенного веб-приложения

На экране отобразятся защищенный сайт NGINX и приложение Node.js, как в показано следующем примере.

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

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

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

Источник

Русские Блоги

[Воспроизведено] Введение в Cloud-init и классические сценарии приложений

Cloud-init введение и классические сценарии приложений

I. принцип работы cloud-init

Краткое введение

Для реализации настройки экземпляра cloud-init выполняет задачи в 4 этапа:

Во время установки cloud-init задачи, выполняемые на этих 4 этапах, регистрируются в системе как службы. Например, в среде systemd мы видим службы, соответствующие этим 4 этапам:

локальная фаза

В качестве первого этапа выполнения cloud-init в настоящее время экземпляр не знает, как настроить сетевую карту, задача cloud-init состоит в том, чтобы получить информацию о конфигурации с диска конфигурации и затем записать ее в файл / etc / network / interfaces (если centos Напишите в / etc / sysconfig / network-scripts / ifcfg-xxx).
Если нет конфигурационного диска, настройте все сетевые карты на режим dhcp, Это очень важный шаг: только после правильной настройки сетевой карты можно получить метаданные.
О локальном этапе Следующий раздел будет подробно проанализирован с помощью экспериментов.

init, config и заключительные этапы

При нормальных обстоятельствах сеть экземпляра была настроена, и метаданные были успешно получены до выполнения этих трех этапов. Файл конфигурации cloud-init /etc/cloud/cloud.cfg определяет задачи, выполняемые на каждом из трех этапов, и задачи задаются в виде модулей.

Экземпляр Настоящие настройки выполняются этими модулями. Модуль решает, какую работу по настройке следует выполнить, а метаданные определяют конечный результат настройки.
Например, если в файле cloud.cfg указан модуль set_hostname, это означает, что cloud-int будет устанавливать имя хоста экземпляра, а также то, какое имя хоста специально задается именем хоста в метаданных Параметр решения. Некоторые модули имеют поведение по умолчанию, такое как growpart. Если оно не указано в метаданных, оно автоматически развернется / разделится

2. Типичное применение cloud-init (установить hostanme, установить начальный пароль пользователя, установить программное обеспечение)

Установить имя хоста

Описание выглядит следующим образом:
cloud-init Только данные, начинающиеся с ** # cloud-config **, читаются, поэтому обязательно пишите эту строку правильно.
hostname: my1.cloudman.ccСкажите cloud-init установить имя хоста вmy1.cloudman.cc。
manage_etc_hosts: trueСкажите cloud-init обновить файл / etc / hosts.

Следующий вопрос:
Как передать эту информацию в cloud-init?
Есть несколько способов:

Пользовательский начальный пароль пользователя

Официальное облачное изображение может войти только по ssh ключу по умолчанию.
Мы можем использовать модуль set-passwords, чтобы установить пароли для пользователей и разрешить ввод пароля. Сценарий, который необходимо передать, выглядит следующим образом:

Описание выглядит следующим образом:
Пароли пользователя root и ubuntu установлены на 123456.
ssh_pwauth включает пароль для входа.

Проверка SSH после запуска экземпляра:

Пользователь Ubuntu успешно вошел в систему с паролем ssh и может переключиться на root с паролем.

Установите программное обеспечение

Описание выглядит следующим образом:
apt указывает местоположение источника установки, здесь http://1.2.3.4.
Если это источник yum, укажите его в модуле yum_repos. Для конкретного использования см. официальную документацию веб-сайта.
Пакеты определяют пакеты, которые необходимо установить, а также могут указывать конкретные версии.
Экземпляр После запуска вы можете видеть, что источник установки в /etc/apt/sources.list обновлен до http://1.2.3.4.

Поскольку http://1.2.3.4 не является допустимым источником apt, установка определенно завершится неудачно, информацию об ошибках можно увидеть в /var/log/cloud-init.log.

Хотя это не удалось, мы можем по крайней мере определить следующие вещи:
Переданный скрипт действителен, и cloud-init действительно пытается установить указанное программное обеспечение.
/var/log/cloud-init.log полностью запишет все подробности операции cloud-init и является наиболее важным инструментом для отладки.

Источник

Углубленное изучение cloud-init

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

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

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

Знакомство с конфигурациями cloud-init

Настройка виртуальной машины для работы на платформе означает, что инструменту cloud-init, как получателю образа, необходимо применить несколько конфигураций. Основные конфигурации, с которыми вы будете взаимодействовать, — это User data (customData), которые поддерживают несколько форматов. Дополнительные сведения см. в документации по форматам пользовательских данных Cloud-init 21,2. Вы также можете добавлять и запускать скрипты (/var/lib/cloud/scripts) для дополнительной настройки, как описано ниже в этой статье.

Некоторые конфигурации уже заложены в образы Azure Marketplace, которые входят в состав cloud-init, например:

Облачный источник данных — cloud-init содержит код, который может взаимодействовать с облачными платформами, которые называются «источниками данных». При создании виртуальной машины из образа cloud-init в Azure cloud-init загружает источник данных Azure, который будет взаимодействовать с конечными точками метаданных Azure, чтобы получить конфигурацию виртуальной машины.

Конфигурация среды выполнения (/run/cloud-init)

Этапы загрузки cloud-init (конфигурация обработки)

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

Этап генерации. Запускается системный генератор cloud-init, который определяет, что cloud-init следует включить в цели загрузки, и, если все корректно настроено, он включает cloud-init.

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

Этап инициализации сloud-init (сеть). Сеть должна работать, а также должны быть созданы сведения о таблице маршрутов и сетевой карте. На этом этапе будут запущены модули, перечисленные в cloud_init_modules /etc/cloud/cloud.cfg. Будет подключена виртуальная машина в Azure, временный диск будет отформатирован, имя узла будет задано вместе с другими задачами.

Ниже представлены некоторые из модулей cloud_init_modules :

После этого этапа сloud-init сообщит платформе Azure о том, что виртуальная машина успешно подготовлена. Возможно, некоторые модули завершились сбоем, но не все сбои модулей приводят к сбою подготовки.

Этап настройки Cloud-init. на этом этапе будут запущены модули, указанные и перечисленные в/ЕТК/Клауд/Клауд.КФГ.

Заключительный этап Cloud-init: на этом заключительном этапе будут запущены модули в, перечисленные в/ЕТК/Клауд/Клауд.КФГ. Здесь приведены модули, которые необходимо запускать в конце процесса загрузки, такие как установка пакета, запуск сценариев и т. д.

Источник