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