Технология для недолговечных частных виртуальных машин

Я пытаюсь создать систему, которая будет работать с недолговечными (CI и тестовыми сборками) программными компонентами, и в соответствии с моими требованиями каждый из них должен работать на частном хосте. Я использую это определение, чтобы включить варианты паравиртуализации , так как кажется, что это избавит меня от головной боли.

Я работаю на Mac, так что в значительной степени каждая технология выходит, Libvirt и quemu , и т.д. просто не будет работать для меня. Однако я планирую развернуть в Debian; поэтому все, что работает в Debian, возвращается на стол, при условии, что я могу написать сценарий подготовки хост-компьютера, а также его гостевых доменов.

Моя предполагаемая установка состояла в том, что я могу использовать для начальной загрузки установщик Debian, что-то должно означать, что при загрузке машина автоматически настраивается (Chef, Puppet, Babushka, не возражайте, правда) - и часть этой подготовки должна создать Шаблон rootfs, который можно использовать для загрузки контейнера. Сам контейнер также должен быть подготовлен, чтобы, когда контейнер подошел, он знал, какую работу нужно выполнить, мог выполнить эту работу и затем завершить работу.

Короче, вот рабочий процесс, который мне нужен:

1. Загрузите машину (виртуальную или другую) и подготовьте ее к работе.
2. Работа должна выполняться скриптом, установленным chef / puppet / babushka / etc
3. Когда приходит работа, для ее запуска должна быть запущена виртуальная машина.
4. ВМ должна выполнить работу, выйти и освободить свои ресурсы для родительского / хост-компьютера. (важно, чтобы это масштабировалось как минимум до сотен гостевых виртуальных машин на разумном оборудовании)

Я пришел к тому, что попробовал следующее и отказался от них по причинам, указанным ниже:

Для хост-машины

1. Предварительное заполнение образов ISO ISO Debian с помощью Instalinux (при поддержке LinuxCOE) ( Плохо: не работало вообще («Модули ядра не найдены») (поскольку образы Instalinux не синхронизированы с репозиториями FTP, очевидно, это решение очень хрупкое, он также не дает много возможностей для пост-установки и сбрасывает на компьютер известные ключи SSH, ключи хоста и т. д. Это похоже на запуск и забытие, в конце концов у меня будет работающая машина, но нет доступа к ней .)
2. Предварительно заполнить Debian netinst ISO ( Плохо : те же проблемы, что и выше, за исключением того, что, по крайней мере, установка обычно завершается, так как нет никакого несоответствия ядра между ISO и FTP-репозиторием. Тем не менее ограниченная область применения после установки. Хорошо : Абсолютно надежно и повторяемо, легко перебросить в любой стек виртуальных машин на Mac или на «железный» компьютер, будет работать где угодно, но я не могу пост-установить его достаточно )
3. Различные методы создания rootfs и компиляции его в качестве загрузочного образа жесткого диска ( Плохо : мало что я мог получить, это было хрупко, черт возьми, его было бы трудно установить на реальную машину, и это сложный процесс сборки. Хорошо: если Я мог бы заставить его работать, это, казалось бы, обеспечило большую часть преднастройки машины к заданной спецификации с ключами ssh, ключами хоста, именем хоста, программным обеспечением, установленным из Git и любым другим, но тогда вопрос был бы, как упаковать это для распространения, или как написать сценарий, это отдых. )

Я, честно говоря, не уверен, какие технологии люди будут использовать для превращения виртуальной машины из ничего в работающую, работающую и полезную систему. Для меня это выглядит как три шага: а) операционная система, б) конфигурация системы (пользователи и т. Д.), А затем в) изменения файловой системы.

Для гостевых (виртуальных) машин:

1. Множество вещей, в основном я думаю, что ответ здесь - это root-файлы, доступные только для чтения debootstrap, и специальный раздел в контейнере LXC, который содержит работу, которая должна быть выполнена для этого конкретного экземпляра (манифест задания). Вставьте все обычные предостережения о сборке ОС, загрузке, создании пользователей, проверке программного обеспечения из git и выполнении работы.

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

Большинство людей, кажется, предлагают для хост-машины выбрать технологию виртуализации, загрузить машину в рабочее состояние, а затем сделать ее снимок (libvirt кажется логичным фаворитом для этого). Использование снимка для запуска любых последующих установок для тестирования или производства.

Для гостевых машин lxc, по-видимому, предоставляет самый простой вариант, за исключением того, что фоновый режим контейнера и последующее подключение к нему через консоль прерывается во всех существующих ядрах, а новейшей версии lxc, доступной для стабильного Debian, более 18 месяцев. и не хватает многих функций, которые широко используются.

Обычно я являюсь разработчиком приложений, и я не часто работаю с технологиями уровня сервера (и я уверен, что SF пометит этот вопрос как «слишком субъективный»), но я действительно не уверен, какие инструменты использовать.

Последнее слово - я знаю один подобный проект (travis-ci.org), который использует для этого ящики Vagrant. Это кажется довольно тупым инструментом, большими, медленными, ориентированными на рубины инструментами, предназначенными для мелкомасштабного предоставления настольных компьютеров для тестирования виртуальных машин, используемых для критически важной инфраструктуры обслуживания, но я также знаю некоторых из этих ребят, и они умнее меня, так что, возможно, они просто сдались.

Любая помощь приветствуется.

Некоторые идеи:

1. Ваша точка зрения «сотни виртуальных машин на разумном оборудовании» заставляет меня (без личного опыта) думать о виртуальных машинах, которые либо загружаются по сети, либо совместно используют большую часть своего тома (/ usr) через NFS. Зависит от того, насколько похожи ваши виртуальные машины.
2. «То, что я мало мог получить, было чертовски хрупким» Трудно поверить. Вы можете быть более точным, в чем проблема?
3. «было бы трудно установить на реальную машину» Вы имеете в виду «сложно» по сравнению с тем, что нужно для решения в один клик для создания виртуальной машины? Я бы спросил: насколько это сложно и как часто это будет происходить? В чем разница, воссоздавая initrd для соответствующего оборудования?
4. «Однако я не могу пост-установить его достаточно» Что вам нужно, и почему это не работает? Вы можете сделать загрузку скрипта частью процесса загрузки. Виртуальная машина получает свой IP по DHCP (жестко настроенный на MAC-адрес виртуальной машины), а Samba предоставляет виртуальные машины различные сценарии после установки в зависимости от IP-адреса клиента.

Читая ваш пост, я продолжал думать, что vagrant и jenkins с плагином vagrant вполне соответствуют вашим потребностям. Любая имеющаяся у вас коробка, которая может обрабатывать количество виртуальных машин, о которых вы говорите, не должна даже замечать издержки инструментов, поддерживающих среду.

Используя что-то, что работает на Apple и Debian, я попробовал только виртуальную коробку. Хорошо, что с помощью virtualbox вы можете создать виртуальную машину на своей системе Mac и скопировать ее в систему Debian, используя ту же версию виртуальной коробки, и она загрузится.

Сотни виртуальных ящиков, использующих виртуальный ящик, звучат так, как если бы вы тратили немало времени, используя интерфейс vboxmange для написания необходимой уникальной информации для каждого виртуального компьютера. Как uuids для жестких дисков, mac-адрес на сетевых интерфейсах.

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

Используя ваш снимок, вы также можете сделать сотни копий этого образа виртуальной машины. Использование скриптового интерфейса vboxmange для создания копий, уникальных по своим значениям, например, uuids и mac-адресов. Затем попросите сценарий запуска вызвать все изменения, настройки, которые вам нужно применить на виртуальных машинах для тестирования, или запустить различные тесты.