Phenquestions
1. Что оно делает?
Вы когда-нибудь задумывались, как провайдеры VPS настраивают ваши виртуальные машины, добавляют ваши SSH-ключи, создают пользователей и устанавливают пакеты каждый раз, когда вы запускаете новую виртуальную машину в «облаке»? Что ж, ответ для большинства поставщиков - cloud-init. Большинство ОС и дистрибутивов поставляют образы виртуальных дисков с соответствующими ОС, установленными в образе. Установка очень минимальна и может служить шаблоном для корневой файловой системы ОС. Сопровождающие ОС также достаточно любезны, чтобы предоставить образ виртуального диска для всех различных форматов, от необработанных образов дисков до qcow2 и даже vmdk, vdi и vhd.
В образе также предустановлен один дополнительный пакет - cloud-init. Задача cloud-init - инициализировать виртуальная машина (обычно в рамках службы облачного хостинга, такой как DigitalOcean, AWS или Azure) обращается к хостинг-провайдеру источник данных и получить информацию о конфигурации, которую он затем использует для настройки виртуальной машины.
Информация о конфигурации может включать данные пользователя такие как ключи SSH, имя хоста экземпляра, пользователи и пароли вместе с любой другой произвольной командой, которую пользователь хочет запустить.
2. Проблема с Cloud-Init
Cloud-init - отличный инструмент, если вы пользователь облака, если вы разворачиваете виртуальные машины или контейнеры, и ваш облачный провайдер достаточно любезен, чтобы попросить у вас облачную конфигурацию, это здорово! С помощью файла конфигурации облака, также известного как ваши пользовательские данные, вы можете добавлять пользователей, запускать произвольные команды, устанавливать пакеты прямо во время создания виртуальной машины. Процесс можно повторять снова и снова, без многократного набора утомительных команд. Скоро у вас будет парк виртуальных машин с идентичной конфигурацией.
Однако, если вы копнете немного глубже и увидите, как делается колбаса, вы начнете сомневаться в некоторых аспектах cloud-init. Например, по умолчанию источник данных похож на конечную точку REST, и они, по сути, жестко запрограммированы в самом пакете cloud-init. Конечно, вы можете настроить источник данных самостоятельно, но этот процесс сложен и требует много времени. Документация для этого практически отсутствует.
Официальная документация - это не что иное, как руководство пользователя для конечных пользователей, использующих уже существующие облачные сервисы. Он не говорит вам, как вы можете настроить свой собственный источник данных cloud-init, если вы являетесь новым поставщиком. Даже документация для конечных пользователей оставляет желать лучшего, и я бы порекомендовал людям использовать вместо этого отличный учебник DigitalOcean.
Что еще хуже, пользователям с домашними лабораториями виртуализации и небольшим запуском VPS трудно извлечь выгоду из этих легких облачных образов. Вы не можете запустить виртуальную машину из этих шаблонов без источника данных cloud-init или какого-либо хакерского метода, который сложно автоматизировать и масштабировать. Другими словами, вы даже не можете игнорировать cloud-init, если не хотите создавать свои собственные шаблоны.
В классическом стиле systemd он освобождается от своих предопределенных ролей и начинает возиться с сетью и другими частями ОС, что сбивает пользователей с толку. Он входит в состав Ubuntu 18.04 серверный ISO, который не имеет абсолютно никакого смысла (по крайней мере, для меня).
3. Обходной путь для домашних лабораторий
Не говоря уже о разглагольствованиях, мне все еще приходится иметь дело с cloud-init в повседневном использовании. У меня очень минимальная установка Debian 9 на оборудовании x86_64, которое я использую в качестве гипервизора KVM. Я действительно хотел использовать образы дисков qcow2, которые поставляются Ubuntu и CentOS. В этих образах дисков предустановлена ОС, и для их использования вам просто необходимо:
- Скопируйте их как образ виртуального жесткого диска вашей виртуальной машины.
- Измените виртуальный размер корневой файловой системы до желаемого размера (рекомендуется не менее 10 ГБ). Это не увеличит физический размер вашей виртуальной машины, но образ диска может со временем расти по мере того, как виртуальная машина добавляет к нему больше данных.
- Настройте виртуальные машины с помощью cloud-init. Минимальное требование - установить пароль пользователя root или ключи SSH, но вы можете делать почти все, что умеет cloud-init.
Выполняются следующие шаги:
- Загрузите облачный образ вашей любимой ОС и сохраните его в каталоге / var / lib / libvirt / boot:
$ curl -O https: // изображения-облака.убунту.com / xenial / текущий / xenial-server-cloudimg-
amd64-disk1.img
$ cd / var / lib / libvirt / изображений
- Создайте пустой виртуальный жесткий диск желаемого размера и разверните в него загруженный образ qcow2. Мне нравится хранить жесткие диски виртуальной машины в каталоге / var / lib / libvirt / images /, вы можете выбрать другой каталог. Что бы вы ни выбрали, запустите следующие команды в том же каталоге:
размер виртуального диска 8 ГБ
$ virt-resize --expand / dev / sda1 / var / lib / libvirt / boot / xenial-server-
cloudimg-amd64-disk1.img
./ myVM.qcow2
- Создание файлов cloud-init. Это файлы пользовательских данных и метаданных:
идентификатор-экземпляра: myVM
локальное имя хоста: myVM
Пользовательские данные $ vim
# cloud-config
пользователи:
- имя: корень
chpasswd:
список: |
корень: myPassword
срок действия: Ложь
Единственный пользователь, который у меня есть, - это пользователь root. Если вы не упомянули ни одного пользователя, то пользователь по умолчанию с именем убунту создается. Имя пользователя по умолчанию отличается от одной ОС к другой, поэтому я рекомендую указать пользователя, даже если это просто корень. Следующая часть файла пользовательских данных сообщает Cloud-init настроить пароль для всех пользователей, которым вы хотите назначить пароль. Опять же, я просто устанавливаю пароль только для пользователя root, и это мой пароль. Убедитесь, что между двоеточием и строкой пароля нет пробела.
Еще лучше, вы можете использовать SSH-ключи вместо жестко запрограммированных паролей.
Пользовательские данные $ vim# cloud-config
пользователи:
- имя: корень
ssh_pwauth: Верно
ssh_authorized_keys:
- ssh-rsa
- Вставьте файлы пользовательских данных и метаданных в iso.
Убедитесь, что файл cidata-myVM.iso находится в / var / lib / libvirt / images /
- Перейдите в каталог / var / lib / libvirt / images и инициализируйте виртуальную машину с помощью команды virt-install: $ virt-install --import --name myVM --memory 2048 --vcpus 2 --cpu host
--диск myVM.qcow2, формат = qcow2, bus = virtio --disk myVM-cidata.iso, device = cdrom
--сетевой мост = virbr0, модель = virtio --os-type = linux
--os-вариант = ubuntu16.04 - ноавтоконсольТеперь вы можете попробовать войти в виртуальную машину, используя команду virsh console myVM и используя имя пользователя root и соответствующий пароль для входа. Чтобы выйти из консоли, просто введите Ctrl +]
Заключение
Облачные образы, которые поставляет большинство поставщиков, действительно эффективны с точки зрения использования ресурсов, а также они кажутся очень быстрыми и отзывчивыми. Тот факт, что нам нужно иметь дело с неудобной конфигурацией cloud-init в качестве отправной точки, только мешает сообществу принять KVM и связанные с ним технологии.
Сообщество может многому научиться на том, как Docker создает и отправляет свои образы. Ими действительно легко управлять как в качестве работающих контейнеров, так и в виде шаблонов, которые легко распространять и использовать.z
