Эффективный способ обеспечения «чистой системы» для непрерывной интеграции

10

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

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

Мы, вероятно, сами напишем сервис CI, поскольку наша экосистема довольно необычна. Вопрос: как эффективно обеспечить систему чистого листа для каждой итерации КИ?

Развертывание проекта устанавливает несколько пакетов Debian, настраивает несколько сайтов nginx, а также устанавливает некоторые пакеты в общесистемном диспетчере пакетов для конкретного языка (LuaRocks). Нет ничего более навязчивого, чем это (я считаю). Таким образом, более важно иметь возможность быстро настроить чистый лист (в течение минуты на современном оборудовании, быстрее - лучше), чем обеспечить абсолютную изоляцию и чистоту.

Я вижу два способа сделать то, что нам нужно:

Либо установить какую-нибудь тюрьму (например, lxc).
Или установите виртуальную машину, которая может делать снимки, и используйте их.

Но на данный момент мне не хватает информации, чтобы принять решение.

Что бы вы посоветовали? Есть еще варианты? Какие-то конкретные названия инструментов?

Примечание. Служба CI будет работать внутри гостевой системы Citrix XenServer. Платные решения в порядке, если цены разумные. (Обычно они не являются разумными в этой области.) Решения удаленного CI не в порядке.

— Александр Гладыш
источник

5

Посмотрите на шеф-повара / бродяги . Не уверен, что это будет достаточно быстро, но что-то посмотреть.

На случай, если вы не знакомы с Chef, это сервер, предназначенный для простой подготовки серверов на основе кода. Я бы рекомендовал взглянуть на одну из веб-трансляций. Джанго шеф-повар

Vagrant, veewee, chef-solo & knife-solo, я думаю, что этот материал охватывает большую часть того, что вы хотите сделать.

Сообщение в блоге Vagrant Сообщение в блоге, показывающее быструю настройку сервера с использованием Vagrant.

— Филипп Тинни
источник

Спасибо. Вы хотите предоставить более подробную информацию в своем ответе?

— Александр Гладыш

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

— Филипп Тинни

13

Посмотрите на Дженкинса . Он имеет плагины, которые позволяют запускать сборки на виртуальных машинах в VMWare или VirtualBox или в облаке Amazon / a Eucalyptus . Для виртуальных машин, запускаемых в облаке, вы можете указать сценарий инициализации, в котором вы можете выполнять такие действия, как установка пакетов.

— Ларс Котхофф
источник

Спасибо, но Дженкинс - CI-сервер, и я хотел бы узнать о способах его создания самостоятельно.

— Александр Гладыш

2

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

— jenkins

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

— Ларс Котхофф

В любом случае, Дженкинс или нет Дженкинс, что использовать для быстрого получения снимков ОС с чистого листа? (Пожалуйста, прекратите упоминать сторонние облака - это должно быть запущено на наших собственных серверах.)

— Александр Гладыш

Запустить облако Eucalyptus / OpenStack / ... на своих собственных серверах?

— Ларс Котхофф

2

Я бы использовал инфраструктуру VM и создал бы базовый шаблон, или использовал бы облако, как предложил @LarsKotthoff. Их легко раскрутить быстро, и вы можете быть уверены, с чего начали.

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

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

— tenacioustechie
источник

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

— Александр Гладыш

Также, пожалуйста, уточните, что касается «использования инфраструктуры ВМ и создания базового шаблона».

— Александр Гладыш

2

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

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

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

Развертывание проекта устанавливает несколько пакетов Debian, настраивает несколько сайтов nginx, а также устанавливает некоторые пакеты в общесистемном диспетчере пакетов для конкретного языка (LuaRocks). Нет ничего более навязчивого, чем это (я считаю). Таким образом, более важно иметь возможность быстро настроить чистый лист (в течение минуты на современном оборудовании, быстрее - лучше), чем обеспечить абсолютную изоляцию и чистоту.

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

Платные решения в порядке, если цены разумные. (Обычно они не являются разумными в этой области.) Решения удаленного CI не в порядке.

Если вы ищете для запуска нескольких машин одновременно, проверьте Nimbula (я бесстыдный; я работаю на них). Для небольших развертываний это бесплатно и позволяет вам собрать собственное частное облако для тестирования ... или чего-либо еще. Между Jenkins и файлом оркестровки вы можете раскрутить хост-серверы, тестировать клиентов и все остальное, чтобы автоматически выполнять полный спектр тестового кода без какого-либо взаимодействия.

— Джефф Ферланд
источник

Тьфу. Может быть, я не спешу сегодня, но я пытался копаться в сайте Nimbula, но не вижу причины, по которой говорят о маркетинге. Вы хотите указать на здравый текст, который описывает, как делать то, что мне нужно? (Т.е. настроить шаблон гостевой машины и, исходя из сценария, создавать и уничтожать его для каждой сессии CI.)

— Александр Гладыш

@AlexanderGladysh Это удобно, если вы используете много машин для сборки из / много работы CI. Бесполезно, если у вас недостаточно рабочей нагрузки, чтобы гарантировать кластер, по крайней мере, из 3 машин.

— Джефф Ферланд