Сегодня многие говорят о DevOps как о методологии, которая помогает разрушить «железный занавес» между IT отделом, QA и программистами и создать некий общий механизм, помогающий делать продукты быстрее и качественнее. Основная задача, которая встает перед DevOps разработчиком — это добиться максимальной автоматизации развертывания development. testing, production сред и переходов между ними. Соответственно одна из основных проблем в данном случае — это соблюсти полную идентичность сред разработки, тестирования и эксплуатации. Под катом приведу пример практического решения данной задачи, которое я использовал в нескольких компаниях в ходе интеграции DevOps методологии.
Так как речь идет о рабочем примере, сразу опишу те ограничения, которые задаются при решении данной задачи:
- Стабильная версия популярный rpm-based дистрибутиа с большим сообществом, где помогут решить типовые проблемы связанные с ОС. Был выбран CentOS, так как на текущий момент это самое популярный rpm-based дистрибутив.
- Возможность версионирования среды. Программисты занимались разработкой сразу нескольких форков продукта на CentOS 5 и CentOS 6
- Обязательный набор софта для корректной работы и разворачивания продукта (это пример, в реальности список был значильно больше):
Для CentOS 5:
- python => 2.4
- python-IPy
- python-simplejson
- mysql-server >= 5.0
Для CentOS 6:
- python => 2.6
- python-IPy
- python-simplejson
- mysql-server >= 5.1
На момент когда я впервые задался этой проблемой, готовых решений небыло, да и сейчас это довольно специфический момент и общих решений я пока не нашел. Как правило это какие-то внутренние скрипты, которые затачиваются под конкретные продукты.
Чтобы унифицировать это решение я разработал утилиту build-tools https://github.com/scopenco/build-tools, которая позволяет создавать RHEL, CentOS, Fedora, Scientific yum репозитарии с метапакетом (пакет проекта) на базе XML спецификаций(aka ролей). Роли описывают набор обязательных пакетов и репозитариев, откуда эти пакеты вместе с зависимостями скачиваются в локальный yum репозитарий (aka билд). Данный репозитарий используется в качестве пакетной базы для продукта.
Итак, установка build-tools очень простая и описана в README.
Перейдем к спецификациям проектов.
Пример спецификации для СentOS 5:
<?xml version="1.0" encoding="UTF-8"?>
<project
name="myproject"
summary="My First Project"
repository="http://repo.domain.com/pub/repo/"
version="0.1"
>
<!-- role with minimal set of packages -->
<role path="roles/centos-5-minimal.xml" />
<!-- python packages -->
<package name="python" version="2.4.3" />
<package name="python-IPy" />
<package name="python-simplejson" />
<!-- mysql packages -->
<package name="mysql-server" version="5.0.95" />
<!-- yum repos -->
<role path="repos/centos-5-base.xml" />
<role path="repos/centos-5-updates.xml" />
<role path="repos/centos-5-epel.xml" />
</project>
Пример спецификации для СentOS 6:
<?xml version="1.0" encoding="UTF-8"?>
<project
name="myproject"
summary="My First Project"
repository="http://repo.domain.com/pub/repo/"
version="0.2"
>
<!-- role with minimal set of packages -->
<role path="roles/centos-6-minimal.xml" />
<!-- python packages -->
<package name="python" version="2.6.6" />
<package name="python-IPy" />
<package name="python-simplejson" />
<!-- mysql packages -->
<package name="mysql-server" version="5.1.71" />
<!-- yum repos -->
<role path="repos/centos-6-base.xml" />
<role path="repos/centos-6-updates.xml" />
<role path="repos/centos-6-epel.xml" />
</project>
Разница по сути только в подключаемых yum репозитариях и ролях с минимальным набором пакетов.
Для сборки yum репозитария и мета пакетов можно воспользоваться готовыми скриптами, а можно и написать свои с более глубокой автоматизацией и интеграцией в процесс разработки.
cd src
cp ../repository .
./build-el5.sh
./build-el6.sh
Сборка репозитариев выполняется обязательно на CentOS 5. Причиной этому является тот факт, что yum обратно не совместим и репозитарии, собранные через yum API CentOS 6 не будут ставиться на CentOS 5 машины, тогда как репозитарии, собранные на CentOS 5 ставятся на CentOS 6, Fedora 13 и выше, Scientific 5 и выше.
После запуска сбоки на выходе получается 2-а репозитария, с которых можно заливать физические и виртуальные сервера по kickstart. Таким образом фиксируется набор софта, который можно хранить в корпоративном репозитарии и использовать для разворачивания продукта.
Можно создавать новые роли с публичными yum репозитариями и пакетами для кастомизации сред.
Рассмотрим несколько популярных вариантов:
- Допустим для testing среды нужно добавить какие-то дополнительные rpm пакеты, которых не должно быть в production. В этом случае создается отдельная роль со списком этих пакетов и отдельный проект для testing среды, куда эта роль добавляется на ряду с ролями для остальных сред. Сборку билдов для всех сред нужно сделать в тот же день чтобы версии пакетов в билдах для development и production не отличались от testing а только их кол-во.
- Допустим есть регламентированный список софта, который должен присутствовать на всех серверах проекта. В таком случае создается отдельная роль с этим списком, которая добавляться во все спецификации проектов. Таком образом гарантируется что софт будет установлен на всех серверах.
Подробное описание атрибутов можно найти в wiki build-tools.
Если говорить об обновлении, которое рано или поздно случается, то в данном случае достаточно будет инкриментировать версию в спецификации проекта и пересобрать билд. Получится новый билд с новой версией, который можно разворачивать либо обновлять в средах разработки, тестирования и эксплуатации.
Итоги:
Таким образом, используя build-tools мне удалось:
- решить проблему идентичности development, testing, production сред
- предоставить разработчикам широкие возможности по версионированию среды и совместимости софта в рамках всего проекта
