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

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

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

Источник

☁️ Удалить 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 🙂

Источник

Ubuntu Documentation

Summary

cloud-init is the Ubuntu package that handles early initialization of a cloud instance. It is installed in the official Ubuntu live server images since the release of 18.04, Ubuntu Cloud Images and also in the official Ubuntu images available on EC2.

cloud-init’s behavior can be configured via user-data. User-data is passed to cloud-init by the user to the cloud provider at launch time, usually as a parameter in the CLI, template, or cloud portal used to launch an instance.

User Data Input Formats

User data that will be acted upon by cloud-init must be in one of the following types:

Gzip Compressed Content

content found to be gzip compressed will be uncompressed. The uncompressed data will then be used as if it were not compressed. Compression of data is useful because user-data is limited to 16384 bytes 1

User-Data Script

begins with: » #!» or » Content-Type: text/x-shellscript»
script will be executed at «rc.local-like» level during first boot. rc.local-like means «very late in the boot sequence»

Include File

begins with » #include» or » Content-Type: text/x-include-url»
This content is a «include» file. The file contains a list of urls, one per line. Each of the URLs will be read, and their content will be passed through this same set of rules. Ie, the content read from the URL can be gzipped, mime-multi-part, or plain text

Cloud Config Data

begins with » #cloud-config» or » Content-Type: text/cloud-config»
This content is «cloud-config» data. See the examples for a commented example of supported config formats.

Upstart Job

begins with » #upstart-job» or » Content-Type: text/upstart-job»
Content is placed into a file in /etc/init, and will be consumed by upstart as any other upstart job.

Cloud Boothook

begins with » #cloud-boothook» or » Content-Type: text/cloud-boothook»

This content is «boothook» data. It is stored in a file under /var/lib/cloud and then executed immediately.
This is the earliest «hook» available. Note, that there is no mechanism provided for running only once. The boothook must take care of this itself. It is provided with the instance id in the environment variable «INSTANCE_ID». This could be made use of to provide a ‘once-per-instance’
Only available in 10.10 or later (cloud-init 0.5.12 and later)

Part Handler

begins with » #part-handler» or » Content-Type: text/part-handler»

This is a ‘part-handler’. It will be written to a file in /var/lib/cloud/data based on its filename. This must be python code that contains a list_types method and a handle_type method. Once the section is read the ‘list_types’ method will be called. It must return a list of mime-types that this part-handler handlers.
The ‘handle_type’ method must be like:

Cloud-init will then call the ‘handle_type’ method once at begin, once per part received, and once at end. The ‘ begin ‘ and ‘ end ‘ calls are to allow the part handler to do initialization or teardown.
There is an example at doc/examples/part-handler.txt. Also this blog post offers another example

User-Data Scripts

As popularized by alestic.com, user-data scripts are a convenient way to do something on first boot of a launched instance. This input format is accepted to cloud-init and handled as you would expect. The script will be invoked at an «rc.local» like point in the boot sequence.

After running the above, you can expect that /root/output.txt will contain the desired text.

Cloud Config Syntax

The file must be valid yaml syntax.

Here are some simple examples of what can be done with cloud-config syntax:

run ‘apt-get upgrade’ on first boot

enable byobu by default for all system users

import ssh keys for launchpad user ‘smoser’ and add his ppa

run a few commands on first boot
The output of these commands will appear in console output

Multipart Input

A single format of user data might not be enough to accomplish what you want. For example, you may want to insert an upstart job and also run a user-data script.

There is a tool in cloud-utils’s bin/ directory called ‘write-mime-multipart’ which can aid creating mime multipart content.

Consider the following example:

Now, given the files above in the current directory, you can do:

600799 makes boothook get read as a user script

More information

Examples of user-data for cloud-init can be seen in the Github examples directory.

Using cloud-init with example clouds:

Footnotes

CloudInit (последним исправлял пользователь danielbowers 2021-07-25 16:34:51)

The material on this wiki is available under a free license, see Copyright / License for details
You can contribute to this wiki, see Wiki Guide for details

Источник

Поддержка 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 см. в следующих документах:

Источник

Администрирование и не только

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

Страницы

среда, 24 марта 2021 г.

Руководство администратора Proxmox VE R 6.0 Глава 10.8

Виртуальные машины Qemu/KVM

Поддержка Cloud-Init

Многие дистрибутивы Linux предоставляют готовые к использованию образы Cloud-Init, в основном предназначенные для OpenStack. Эти образы также будут работать с Proxmox VE. Несмотря на то, что получение таких готовых образов может показаться удобным, мы как правило рекомендуем подготавливать образы самостоятельно. Преимущество в том, что вы будете точно знать, что вы установили, и это поможет вам позже легко настроить образ в соответствии с вашими требованиями.

После создания такого образа Cloud-Init мы рекомендуем преобразовать его в шаблон виртуальной машины. С шаблоном ВМ, вы можете быстро создавать связанные клоны, так что это быстрый метод развертывания новых экземпляров виртуальных машин. Вам только необходимо настроить сеть (и, возможно, ключи ssh) перед запуском новой виртуальной машины.

Мы рекомендуем использовать аутентификацию на основе ключей SSH для входа на виртуальные машины, предоставленные Cloud-Init. Также возможно установить пароль, но это не так безопасно, как использование аутентификации на основе ключа SSH, потому что Proxmox VE приходится хранить зашифрованную версию этого пароля в данных Cloud-Init.

Proxmox VE создает образ ISO для передачи данных Cloud-Init в ВМ. Для этого всем Cloud-Init ВМ должен быть назначен привод CDROM. Также многие образы Cloud-Init предполагают наличие последовательной консоли, поэтому рекомендуется добавить последовательную консоль и использовать ее в качестве дисплея для этих виртуальных машин.

Источник