Облако init ubuntu что это такое

Обновлено: 21.11.2024

Давайте вернемся к файлу wordpress.yaml, но на этот раз рассмотрим только строки, отличные от сценария Bash.

Следующая строка представляет собой пару "ключ-значение" YAML, где ключ package_update и значение true . Это сообщает cloud-init, что он должен обновить список пакетов на виртуальной машине. Следующая строка package_upgrade: true указывает, что cloud-init должен затем обновить пакеты (например, sudo apt upgrade в Ubuntu). Cloud-init умеет обновлять пакеты в разных операционных системах Linux. В Ubuntu, как мы делали ранее, sudo apt upgrade обновляет пакеты, но, например, в CentOS команда yum update . Cloud-init знает, как выполнять задачи в различных операционных системах Linux, поэтому ваши файлы конфигурации облака будут работать в разных операционных системах (хотя ваши сценарии Bash могут и не работать). Следующая строка packges: является ключом (или именем) для следующей последовательности, в которой перечислены имена пакетов, которые вы хотите установить. Хотя установка этих пакетов не зависит от операционной системы, имена пакетов часто не зависят от операционной системы. Этот список пакетов должен показаться вам знакомым по нашим предыдущим ручным установкам Apache, MySQL и PHP.

На данный момент в этом файле конфигурации облака осталось только две последовательности: последовательность write_files и последовательность runcmd. Последовательность write_files сообщает cloud-init, какие файлы создавать. Свойства файла задаются набором сопоставлений для различных «файловых» элементов в последовательности. Ключ содержимого указывает, каким должно быть содержимое файла. В этом случае мы использовали блочное форматирование, упомянутое ранее, чтобы иметь несколько строк в содержимом файла. Ключ пути указывает местоположение, в котором должен быть создан файл, включая имя файла. Наконец, ключ разрешений указывает, какие разрешения должен иметь файл. В этом случае файлу было предоставлено разрешение 0755, которое соответствует -rwxr-xr-x (см. этот веб-сайт для получения подробной информации о числовых представлениях разрешений файла).

Последовательность runcmd перечисляет последовательность команд для запуска. Обратите внимание, что может быть важно, в каком порядке выполняются команды, и последовательности YAML учитывают порядок элементов в последовательности, поэтому команды, перечисленные первыми, будут выполняться первыми. Первая и единственная команда — это bash /tmp/bootstrap-wp.sh, которая запускает сценарий bash, созданный с помощью элемента write_files. Несмотря на то, что последовательности write_files и runcmd являются частью набора сопоставлений, порядок которых не обязательно соблюдается, cloud-init выполняет действия, обеспечивающие создание файлов и установку пакетов перед выполнением команд.

На этом этапе мы должны понимать все части файла конфигурации облака wordpress.yaml, включая скрипт Bash для установки и настройки WordPress на нашей виртуальной машине.

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

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

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

Что такое облачная инициализация?

Cloud-init — это служба, используемая для настройки операционных систем на базе Linux в облаке. Он позволяет настраивать виртуальные машины, предоставляемые облачным поставщиком, путем изменения общей конфигурации ОС при загрузке. Canonical изначально разработала cloud-init для Ubuntu, но расширила его до большинства основных операционных систем Linux и FreeBSD. Сегодня он официально поддерживает 8 операционных систем Unix: Ubuntu, Arch Linux, CentOS, Red Hat, FreeBSD, Fedora, Gentoo Linux и openSUSE.

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

У большинства поставщиков эта служба предустановлена ​​в образах ОС Unix. При создании виртуальной машины с помощью панели инструментов поставщика облачных услуг у вас, скорее всего, будет раздел cloud-init или пользовательских данных для указания желаемой конфигурации.

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

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

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

Это достигается за счет выполнения сценариев, чаще всего из файла конфигурации облака. Поэтому, чтобы изменить какие-либо настройки по умолчанию, вам необходимо отредактировать файл конфигурации облака в образе виртуальной машины. Это файл YAML, который следует основным правилам синтаксиса YAML, таким как:

  • Отношения между элементами определяются отступами с пробелами.
  • Символ вертикальной черты (|) перед текстом указывает на то, что его следует интерпретировать как есть.
  • Текстовые блоки имеют отступ.
  • Дефис (-) в начале обозначает элементы списка.
  • Для создания элементов ассоциативного массива используется двоеточие (:) + пробел + значение.

Вы можете добавить файл конфигурации облака:

  1. В интерфейсе уровня управления при выборе дополнительных параметров. У провайдера будет параметр cloud-init или User data, куда вы можете вставить файл конфигурации.
  2. Через файл в объекте JSON в запросе API.

Возможности облачной инициализации

Служба cloud-init используется для различных целей, в том числе:

  • Добавление пользователей и групп.
  • Запись произвольных файлов.
  • Добавление репозиториев YUM.
  • Выполнение команд при первой загрузке.

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

Добавить пользователей и группы с помощью cloud-init

Чтобы добавить пользователей и группы на виртуальную машину во время подготовки, используйте следующий синтаксис в файле конфигурации облака:

Вам не нужно включать все параметры при добавлении нового пользователя. Перечисленные выше конфигурации применяются, только если пользователь является новым. Если пользователь уже существует, система изменяет только следующие параметры:

Запись произвольных файлов

Вы можете записывать произвольные файлы, используя синтаксис конфигурации yaml. Содержимое может быть закодировано (base64 или gzip) и указано в виде простого текста или двоичного кода. Перед записью данных по определенному пути они декодируются. Модуль поддерживает все дистрибутивы и имеет частотный модуль один раз на экземпляр.

Примечание. При работе с двоичными данными обязательно используйте расширение . бинарная опция yaml.

Чтобы записать произвольные файлы с помощью cloud-init, используйте следующий синтаксис:

Добавление репозиториев YUM

Возможно, вам потребуется настроить репозиторий yum, чтобы убедиться, что вы используете правильные пакеты для установки нужного программного обеспечения. Используйте cloud-init, чтобы добавить конфигурации репозитория yum в систему. Файл конфигурации добавляется в /etc/yum.repos.d.

Чтобы добавить конфигурацию репозитория yum, используйте следующий синтаксис:

Выполнение команд при первой загрузке

Для запуска произвольных команд в начале процесса загрузки можно использовать модуль bootcmd или runcmd.

bootcmd запускает определенные команды при каждой загрузке после запуска загрузочного хука. Он поддерживает все дистрибутивы и принимает команды, указанные в виде списков или строк. Синтаксис:

runcmd запускает команду только при первой загрузке. Он может выполнять команды, указанные в виде списков или строк. Все команды должны быть в синтаксисе yaml (поэтому обязательно заключайте в кавычки любые проблемные символы). Синтаксис:

Как в следующем примере:

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

Если у вас уже есть предварительно сгенерированные закрытые ключи SSH, вы можете сохранить их на сервере. Cloud-init поддерживает криптосистемы с открытым ключом RSA, DSA и ECDS. Обязательно обращайте внимание на форматирование при добавлении ключей SSH — используйте разрывы строк, блоки, ключи вертикальной черты и всегда указывайте НАЧАЛЬНЫЙ ЗАКРЫТЫЙ КЛЮЧ и КОНЕЦ ЗАКРЫТОГО КЛЮЧА.

Настройка локали

Чтобы настроить и применить системный языковой стандарт для всей системы, используйте модуль cc_locale. Используйте следующую схему конфигурации для определения:

Определить имя хоста

С помощью cloud-init вы можете указать имя хоста и полное доменное имя (полное доменное имя). Есть несколько способов сделать это:

  • Укажите полное доменное имя с помощью ключа fqdn.
  • Определите имя хоста с помощью ключа имени хоста.
  • Используйте ключ имени хоста для определения полного доменного имени (не рекомендуется).
  • Используйте как ключ имени хоста, так и ключ полного доменного имени.

Ключи конфигурации для определения имени хоста включают:

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

cloud-init — это пакет Ubuntu, который обеспечивает раннюю инициализацию облачного экземпляра.Он устанавливается в официальные образы серверов Ubuntu с момента выпуска 18.04, облачные образы Ubuntu, а также в официальные образы Ubuntu, доступные на EC2.

  • установка языкового стандарта по умолчанию
  • настройка имени хоста
  • сгенерировать закрытые ключи ssh
  • добавление ключей ssh ​​в .ssh/authorized_keys пользователя, чтобы они могли войти в систему
  • настройка временных точек подключения

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

Форматы ввода пользовательских данных

  • Этот список правил применяется к каждой части этого файла, состоящего из нескольких частей. Используя файл mime-multi, пользователь может указать более одного типа данных. Например, можно указать как сценарий данных пользователя, так и тип облачной конфигурации.

Это "частичный обработчик". Он будет записан в файл в /var/lib/cloud/data на основе имени файла. Это должен быть код Python, содержащий метод list_types и метод handle_type. Как только раздел будет прочитан, будет вызван метод list_types. Он должен возвращать список MIME-типов, которые обработчики этого частичного обработчика.
Метод handle_type должен быть таким:

Скрипты пользовательских данных

Как популяризировал alestic.com, скрипты пользовательских данных — это удобный способ сделать что-то при первой загрузке запущенного экземпляра. Этот входной формат принимается cloud-init и обрабатывается так, как вы ожидаете. Сценарий будет запущен в точке, подобной "rc.local", в последовательности загрузки.

После выполнения вышеуказанного вы можете ожидать, что /root/output.txt будет содержать нужный текст.

Синтаксис Cloud Config

  • apt upgrade следует запускать при первой загрузке
  • следует использовать другое подходящее зеркало
  • необходимо добавить дополнительные подходящие источники
  • необходимо импортировать определенные ключи ssh

Файл должен иметь допустимый синтаксис yaml.

Составной ввод

Единого формата пользовательских данных может быть недостаточно для достижения желаемого. Например, вы можете вставить задание выскочки, а также запустить сценарий пользовательских данных.

В каталоге bin/ cloud-utils есть инструмент под названием write-mime-multipart, который может помочь в создании MIME-контента, состоящего из нескольких частей.

Рассмотрите следующий пример:

Теперь, учитывая указанные выше файлы в текущем каталоге, вы можете сделать следующее:

  • ключи smoser, импортированные пользователями ubuntu ~/.ssh/authorized_keys . Обратите внимание, что я не указал «--key» в командной строке, так как он не нужен. Вместо этого были импортированы мои ключи панели запуска.
  • принадлежащий root файл в /var/lib/cloud/data/user-data.txt, содержащий сжатые gzip пользовательские данные.
  • файл, принадлежащий root, в /var/lib/cloud/data/user-data.txt.i, содержащий постобработанные пользовательские данные (несжатые, с разрешенными включениями).
  • файл '/var/lib/cloud/data/user-data.txt.i'

Подробнее

Примеры пользовательских данных для cloud-init можно увидеть в каталоге примеров Github.

Возникли проблемы? Мы хотели бы помочь!

Где журналы?¶

Cloud-init использует для входа два файла:

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

Учтите, что каждый раз при загрузке системы к файлам в /var/log добавляются новые журналы. Таким образом, в файлах может быть несколько загрузочных данных.

Просматривая эти журналы, ищите ошибки или обратные трассировки Python, чтобы проверить наличие ошибок.

Где файлы конфигурации?¶

Конфигурация Cloud-init предоставляется в двух местах:

  • /etc/cloud/cloud.cfg
  • /etc/cloud/cloud.cfg.d/*.cfg

Эти файлы могут определять модули, которые запускаются во время инициализации экземпляра, источники данных для оценки при загрузке и другие параметры.

Где находятся файлы данных?¶

В каталоге /var/lib/cloud/ есть два важных подкаталога:

экземпляр¶

Каталог /var/lib/cloud/instance — это символическая ссылка, указывающая на самый последний использованный каталог с идентификатором экземпляра. Эта папка содержит информацию, полученную cloud-init из источников данных, включая данные о поставщиках и пользователях. Это может быть полезно для проверки правильности передачи данных.

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

Наконец, загрузочный файл — это последнее, что делает cloud-init.

Каталог /var/lib/cloud/data содержит информацию о предыдущей загрузке:

  • instance-id : идентификатор экземпляра, обнаруженный cloud-init. Изменение этого файла не имеет никакого эффекта.
  • result.json : файл json покажет как источник данных, используемый для настройки экземпляра, так и наличие ошибок.
  • status.json : файл json показывает используемый источник данных и разбивку всех четырех модулей, если возникли какие-либо ошибки, а также время запуска и остановки.

Какой источник данных я использую?¶

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

Чтобы узнать, какой источник данных используется, выполните команду cloud-id:

Если идентификатор облака не соответствует ожидаемому, запуск сценария ds-identify в режиме отладки и указание его в сообщении об ошибке может помочь в решении любых проблем:

Параметр force позволяет запустить команду еще раз, поскольку экземпляр уже запущен. Другие варианты увеличивают детализацию журналов и помещают журналы в STDERR.

Как повторно запустить обнаружение источника данных и облачную инициализацию?¶

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

Для этого принудительно перезапустите ds-identify, очистите все журналы и повторно запустите cloud-init:

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

Как я могу отлаживать свои пользовательские данные?¶

Две наиболее распространенные проблемы с пользовательскими данными, которые также связаны с конфигурацией облака:

Для проверки вашего YAML у нас есть короткий скрипт с именем validate-yaml.py, который может проверять ваши пользовательские данные в автономном режиме.

Еще один вариант — запустить на экземпляре следующее для отладки пользовательских данных, предоставленных системе:

Поскольку запуск экземпляров в облаке может стоить денег и занять немного больше времени, иногда проще запускать экземпляры локально с помощью Multipass или LXD:

Многопроходная¶

Multipass – это кроссплатформенный инструмент для запуска виртуальных машин Ubuntu в Linux, Windows и macOS.

Когда пользователь запускает Multipass VM, пользовательские данные можно передать, добавив флаг –cloud-init и соответствующий файл YAML, содержащий пользовательские данные:

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

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

LXD предлагает упрощенный пользовательский интерфейс для использования системных контейнеров Linux. С помощью LXD пользователь может пройти:

  • данные пользователя
  • данные поставщика
  • метаданные
  • конфигурация сети

Следующее инициализирует контейнер с данными пользователя:

Чтобы избежать дополнительных команд, это также можно сделать при запуске:

Наконец, можно настроить профиль с конкретными данными, если пользователю нужно запускать его несколько раз:

Приведенные выше примеры показывают, как передавать пользовательские данные. Чтобы передать другие типы данных конфигурации, используйте параметр конфигурации, указанный ниже:

Дополнительную информацию о значениях конфигурации см. в документации по конфигурации экземпляра LXD, а дополнительную информацию о пользовательской конфигурации сети см. в документе «Настраиваемая сетевая конфигурация LXD».

облачные локалды¶

Команда cloud-localds из пакета cloud-utils создает диск с предоставленными пользователем данными. Источник данных NoCloud позволяет пользователям предоставлять свои собственные пользовательские данные, метаданные или сетевую конфигурацию непосредственно экземпляру без запуска сетевой службы. Это полезно, например, для запуска локальных облачных образов с помощью QEMU.

Ниже приведен пример создания локального диска с помощью команды cloud-localds:

Полученный файл seed.img затем можно передать в облачный образ, содержащий cloud-init. Ниже приведен пример передачи seed.img с помощью QEMU:

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

Для дополнительной настройки пользователи могут указать гораздо более подробную конфигурацию, включая конфигурацию сети и метаданные:

Подробнее о формате и конфигурации сетевой конфигурации см. на странице Networking Config Version 2. Чтобы узнать больше о возможных значениях метаданных, посетите страницу NoCloud.

Где я могу узнать больше?¶

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

CloudInit – это процесс, включенный в последних изображениях DigitalOcean, который может извлекать и обрабатывать информацию из метаданных. Когда дроплет загружается в первый раз, программа CloudInit выполняет сценарий, найденный в поле пользовательских данных, предоставляя пользователям возможность автоматизировать первоначальную настройку своих серверов.

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

Вы можете ввести !ref в этой текстовой области, чтобы быстро найти наш полный набор руководств, документации и предложений на рынке и вставить ссылку!

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

Насколько я помню, DigitalOcean использует его для настройки изображений и моментальных снимков. Если вы не собираетесь использовать сервис моментальных снимков/резервного копирования, то его можно безопасно удалить.

Удаление пакета не должно привести к удалению каких-либо других пакетов или основных зависимостей. При тестировании на Ubuntu 16.04 удаляется только один пакет.

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

Тем не менее, странно, что dist-upgrade оставляет пакет зависшим. Я протестировал два дроплета, и ни у одного из них не осталось или не зависло ни одного пакета, ядра или чего-то еще.

Обычно я запускаю полный пакет при первоначальном развертывании:

Или, если вы предпочитаете использовать apt-get :

16.04/16.10 теперь используют apt, который я считаю более полезным, поскольку он сокращает команды (хотя я в основном использую скрипты bash).

При первом развертывании дроплета рядом с флажком «Данные пользователя» можно передать bash-скрипт службе, которая затем запустится во время начального развертывания. Это позволяет вам выполнить первоначальную настройку сервера без входа в терминал. Это более полезно, если вы используете API как часть автоматического развертывания, хотя это также может быть быстрым способом просто настроить нужные вещи из панели управления.

Если вам не нужно удалить его, безопасно оставить его как есть. На самом деле это не занимает много места на диске или не использует большое количество ЦП или ОЗУ (если вообще использует).

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

Стандартная команда обновления:

… не будет обновлять основные пакеты, которые могут изменить функциональность. Например, если вы использовали PHP 7.0, а PHP 7.1 также был в репозиториях, базовая команда обновления не обновит 7.0 до 7.1 или даже 8.0 (когда она будет выпущена), поскольку это выпуски основных версий. Однако он обновит 7.0.x до 7.0.1, 7.0.2 и т. д. То же самое для другого программного обеспечения.

Как правило, если вы не уверены на 100 %, что не столкнетесь с проблемами, связанными с новым ядром, новыми версиями программного обеспечения и т. д., вам не следует выполнять dist-upgrade . Хотя в целом это безопасно, с его помощью можно устанавливать основные выпуски версий.

Если вам абсолютно не нужно удалять его, можно безопасно оставить его как есть. На самом деле это не занимает много места на диске или не использует большое количество ЦП или ОЗУ (если вообще использует).

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

На самом деле «пакеты были сохранены» — это вывод dist-upgrade . Я всегда запускаю его, так как люблю жить на грани ;-)

Но эта особенность apt меня не интересует. В основном я хотел бы разобраться в самом пакете.

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

@jtittle Я понимаю преимущества подготовки, но на данный момент достаточно настроить сервер вручную. Если мои требования изменятся, я, скорее всего, пойду до конца и буду использовать NixOS + NixOps.

Я точно не держал пакет вручную. Может быть, он был помечен как удержанный во время обновления до пикантного? В любом случае, я переустановил его, и он больше не держится.

Читайте также: