Один из вопросов, который возникает при создании сервиса (в данном случае неважно, облако это или VDS) — как создавать клиентские машины.
Большинство наших конкурентов используют клонирование изображений, которое один раз устанавливается и настраивается системным администратором.
Мы используем чистую установку с нуля на каждой машине.
Ниже я попытаюсь объяснить, чем вызвано такое решение, каковы плюсы и минусы обоих подходов.
Как все начиналось.
Когда облако только обрело свои первые возможности, возникла задача автоматизации создания виртуальных машин.
Конечно, первое решение, лежащее на поверхности, было «взять и клонировать».
Благо там все сделано - одной командой (xe vm-clone).
Далее возникла необходимость настроить параметры сети, имя хоста и пароль root. Вся работа занимает полдня.
Ладно, два дня, включая ловлю блох.
Сделанный? Сделанный.
К счастью, эту версию не увидели даже бета-тестеры.
Проанализировав все негативные факторы клонирования диска, мы наконец пришли к идее «установки».
Процесс этот был, мягко говоря, тернистым и занял у меня около полутора месяцев, в течение которых мне пришлось очень глубоко изучить специфику каждого дистрибутива Linux. В результате наша существующая система шаблонов позволяет довольно легко менять настройки создаваемых машин, и весь процесс не привязан к какому-то мистическому «мастер-копии», священному и невероятно важному.
Что такое «чистая установка»? Это когда виртуальная машина создается с пустым диском, запускается специальное ядро со специальным initrd, внутри которого находится установщик (netinst).
К этому установщику присылается файл с ответами на вопросы (в каждом дистрибутиве свои).
Собственно, чем клонирование диска уже установленной ОС отличается от полной установки (речь, конечно, идет не о процессе, а о результате)?
- Уникальные ssh-ключи.
Да, каждый ssh-сервер имеет закрытый ключ, который должен быть уникальным на каждом сервере.
Этот ключ (в Debian/Ubuntu) генерируется во время установки (а не при первом запуске).
А если две клиентские виртуальные машины будут иметь один и тот же закрытый ключ, то это будет гигантская дыра в безопасности, поскольку сервер одного клиента может выдавать себя за сервер другого.
Точно то же самое относится и к сертификатам SSL и их закрытым ключам для Apache и других сервисов, использующих openssl.
- При установке SQL-сервера в Debian/Ubuntu в базе данных создается специальная учетная запись со случайно сгенерированным паролем, чтобы dpkg мог обновлять базы данных.
Пароль для этой учетной записи должен быть уникальным для каждой виртуальной машины.
Если это то же самое, это означает, что ваш «сосед по облаку» знает пароль администратора для вашего sql. Хороший? Не хорошо.
- Дата создания файлов.
При клонировании вы обнаружите, что дата создания образа относится к моменту его создания администратором облака.
А у некоторых файлов (если администратор выкатывает обновления) совсем другая дата.
Смертельно? Нет. Неприятно? Да.
- В лог-файлах содержится ненужная информация - посторонние логины в журнале авторизации, журнал установки вообще полон ерунды неизвестного происхождения.
- uuid всех возможных типов (включая UUID файловой системы) повторяются с диска на диск, что делает слово «уникальный» в UUID бессмысленным
Если вы об этом знаете.
Что, если ты не знаешь? Осознать постфактум, что у нескольких тысяч виртуальных машин осталась дыра из-за того, что кто-то забыл про ещё один уникальный идентификатор в одной из подсистем (в udev, в device-mapper, ещё где-то, о чём мы почему-то говорим) ) ты забыл подумать)? Чтобы не допустить подобных ошибок, нужно изучить каждый дистрибутив вдоль и поперёк.
Каждый.
И Debian, и Susi, и Centos, и Ubuntu (Ubuntu хоть и является форком Debian, но накопила весьма приличное количество отличий); что, если будет добавлен еще один дистрибутив? Уровень ответственности при клонировании невероятно возрастает. И непропорционально выгоде.
Но на самом деле истинной мотивацией использования устройства вместо клонирования была идеологическая чистота метода.
Кому-то это может показаться странным, но во многих вопросах хочется не просто «заставить работать», а следовать идеологии, присущей архитектуре.
Если авторы дистрибутива предполагают, что их дистрибутив будет установлен, то Верно , если он установлен.
Однако чистая установка также имеет некоторые небольшие преимущества для пользователей.
Например, пользователи CentOS найдут в /root файл anaconda-ks.cfg с настройками, с которыми была установлена машина, а также install.log и install.log.syslog с журналами установки.
Эти файлы относятся именно к той машине, на которой они расположены, а не к произвольной машине, когда-то кем-то установленной.
Точно так же пользователи Debian/Ubuntu найдут свои журналы в каталоге /var/log/install. О правильных датах файлов я уже писал выше.
Не буду врать насчет того, что «полная установка» не имеет недостатков по сравнению с клонированием диска.
Они есть.
Но все они касаются только момента установки и не влияют на дальнейшую жизнь машины.
Я перечислю их:
- Установка происходит медленнее, чем клонирование, особенно в случае небольших системных дисков.
- Установка более капризная — если кеширующий прокси хотя бы раз «икает», установка «зависает», в некоторых случаях фатально (установка зависает).
- Гораздо сложнее внести изменения в установку; для отладки этих изменений требуется каждый раз запускать процедуру установки.
Таким образом, преодолев проблему один раз, мы получаем максимально чистые системы, соответствующие замыслу создателей дистрибутива.
Однако я не хочу оголтело критиковать конкурентов.
Вариант клонирования вполне жизнеспособен и при должном старании сделает автомобили весьма похожими на «свежеустановленные».
Пожалуй, единственный вопрос для меня – «насколько похожи».
Как это работает? 
В базе данных (тот самый SCAPI, о котором я еще не говорил) есть класс объектов-шаблонов.
Шаблон хранит кучу параметров для создания машины — ограничения на минимальный/максимальный размер памяти и диска; текстовое описание, ссылка на иконки — короче все, что показывается пользователю при создании машины (пример слева).
Кроме того, там хранится самое важное: текст autoinstall_script. Каждый шаблон имеет свой скрипт, хотя для практических целей с помощью административных скриптов он генерируется из одного файла для 32-битной и 64-битной версий одной и той же ОС.
Это делается с помощью множества подстановок переменных, потому что.
фактический текст 32-битной и 64-битной версий сильно отличается (не только в именах пакетов).
Итак, когда пользователь нажимает кнопку «установить», скрипт отправляет в scapi серию команд (vm-create, vif-create, vdi-create, vbd-create и т. д.), которые «создают» машину.
После этого запускается основная команда — vm-install. Эта команда принимает параметры, необходимые для установки (например, имя хоста), берет из базы данных сценарий, соответствующий шаблону машины (шаблон передается в vm-create), и запускает процесс установки.
Как я писал выше, «процесс установки» буквально означает следующее: специальное ядро, специальный initrd и куча параметров, которые передаются через PV-args в паравиртуализированное ядро.
Внутри initrd каждая система имеет свой установщик, которому требуется свой формат. Сразу, как только виртуальная машина запустилась с ядром/initrd для установки, ее настройки изменяются на «рабочие», с обычным для данного дистрибутива ядром и initrd для загрузки.
(Кстати, какое ядро использовать для загрузки, тоже хранится в шаблоне).
Среди основных дистрибутивов существует три метода установки: preseed, кикстарт и автояст. Предпосев - достижение Debian, также относится и к Ubuntu. Он содержит ответы на вопросы, которые пакеты могут задавать через механизмы deb. К сожалению, ответы на эти вопросы не всегда описаны в документации — иногда приходится заглядывать внутрь файлов deb/udeb (udeb — небольшой deb, хранящий фрагменты установщика).
Надо сказать, что хотя debian и ubuntu очень близки, их набор ответов достаточно существенно различается, чтобы воспринимать их как разные операционные системы.
Основное преимущество preseed — возможность передавать любые ответы на вопросы как в виде файла, так и в виде аргументов ядра, что позволяет помещать в статический файл «общие» для машин параметры и все уникальное.
машине (имя, пароль, IP-адрес) передайте его через PV-args. Кстати, в Ubuntu preseed обрабатывается установщиком от debian (тот самый, красный и синий в текстовом режиме), поэтому красивого ПАРНЯ (которого видят пользователи десктопа при установке) там нет. Кикстарт — изобретение Red Hat вместе с другими возможностями RHEL было полностью перенесено в CentOS. Набор возможностей несколько уступает preseed, поэтому пришлось изобретать целую систему динамической генерации кикстартов с защитой от их загрузки сторонними машинами (будет очень неприятно, если кто-то скачает ваш первоначальный пароль, правда?) .
Еще одна особенность CentOS заключается в том, что ее сетевой образ не поддерживает Xen, и перед запуском его необходимо пропатчить (заменить на kudzu).
Автояст — расширение Yast, системы конфигурации Suse (и OpenSuse соответственно), с одной стороны, позволяет делать многое (точнее, в рамках концепции Yast, всё), с другой стороны, ещё и не поддерживает обычные PV-args. Кроме того, autoyast написан на причудливом XML, поэтому размер autoyast.xml примерно в 5 раз больше, чем кикстарта и содержит гораздо меньше полезной информации.
Отдельно нужно сказать и об особенностях установки CentOS. Из-за их чрезмерной приверженности неизменности CentOS прямо из коробки так же стар, как.
Centos. То есть yum update дает целых 80+ МБ обновлений на свежеустановленной системе.
Чтобы не оставлять пользователей с древними системами, yum update пришлось включить в раздел %post для кикстарта, это, кстати, объясняет, почему установка centos занимает больше времени, чем все остальные системы.
Теги: #selectel cloud #selectel cloud #selectel cloud #selectel cloud #управление виртуальными машинами
-
Курия
19 Oct, 24 -
Обзор Юзабилити Хабра (Пожелания)
19 Oct, 24
