Решение проблемы идентичности сред в DevOps методологии

Сегодня многие говорят о 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 мне удалось:

1. решить проблему идентичности development, testing, production сред
2. предоставить разработчикам широкие возможности по версионированию среды и совместимости софта в рамках всего проекта