-
Notifications
You must be signed in to change notification settings - Fork 0
Motivation
build-tools — программа, являющаяся одним из ключевых элементов предлагаемого здесь подхода к автоматизации управления программными окружениями на основе дистрибутивов GNU/Linux, использующих RPM (в текущей реализации). Предлагаемый автоматизированный подход реализует:
- воспроизводимость;
- версионность;
- гибкость;
- локальную доступность.
Эти свойства позволяют надёжно и быстро разворачивать приложения различной сложности.
Далее излагается основная суть данного подхода, а также предпосылки и мотивация его применения.
Для наглядности мы будем рассматривать в качестве примера типовое трёхуровневоe Интернет-приложение, в состав которого входят следующие компоненты:
- серверы баз данных (MySQL);
- серверы приложений (Apache+PHP);
- веб-фронтенды (nginx).
Далее считается, что развёртывание всего программного обеспечения происходит в условиях дистрибутива CentOS. В этом контексте окружение можно формально определить как фиксированный набор пакетов известных версий, набираемых из известных репозитариев. Подробно окружения рассматриваются далее в соответствующем разделе.
Таким образом, можно говорить о трёх ролях, соответствующих в нашем примере компонентам приложения, которые могут, вообще говоря, исполняться в различных окружениях, развёрнутыми на различных узлах сети:
- сервер БД;
- сервер приложений (динамических веб-страниц);
- фронтенд-сервер.
В то же время, жизненный цикл приложения осуществляется группой людей, которые в свою очередь также исполняют в этом процессе различные организационные роли:
- инженер-разработчик;
- инженер контроля качества;
- инженер эксплуатации.
Обычно соответствующие организационной роли обязанности возлагаются на различных участников и предполагают различные требования к другим участникам.
Разработчику, отвечающему за исходные тексты приложения, удобно иметь готовое окружение, где можно производить отладку действующей системы. Эта среда должна максимально близко воспроизводить «боевую» среду, где будет в конечном счёте использоваться приложение.
Очевидно, что подобным же образом инженеры контроля качества нуждаются в выделенных окружениях для своих задач.
Инженеры эксплуатации отвечают за интеграцию приложения в действующую систему, то есть производят управление на более высоком структурном уровне системы нежели разработчики. В число задач, решаемых ими, обычно входит подготовка всех окружений, где исполняются компоненты приложения — «боевых», для разработки и для контроля качества.
Таким образом, перед инженерами эксплуатации стоит трудоёмкая задача — создание и поддержка множества окружений различного назначения. При этом требуется соблюдать чёткость в управлении изменениями, чтобы обеспечить воспроизводимость окружений, минимизировать возможность ошибок и облегчить их локализацию.
Под окружением мы здесь понимаем определённый фиксированный набор пакетов определённых версий, установленных на некоторой машине (сетевом узле).
Очевидно, что создание окружения начинается с установки базовой операционной системы, которая в нашем примере представлена дистрибутивом CentOS, поскольку для установки какого бы то ни было программного обеспечения требуется по крайней мере действующая система управления пакетами. Автоматизацию установки базовой системы, необходимой для создания окружения мы здесь для простоты не рассматриваем.
В более широком смысле в этот же шаг можно включить вообще любую установку готовых пакетов программного обеспечения. Для нашего примера это может быть MySQL, nginx, PHP и/или другое ПО, необходимое для работы приложения, в зависимости от роли данного хоста. Уже на этом этапе уже могут возникнуть вопросы. Какая версия MySQL требуется? Доступна ли она в данной версии CentOS? Может потребоваться использовать версию не из официального репозитария, а, например, от компании Percona. Можно представить себе и крайний случай — собственную сборку MySQL со специальными патчами из собственного репозитария.
Подобное возможно и для пакетов других компонентов.
Следующий шаг — установка пакетов программного обеспечения изготовленных специально и используемых только в рамках данного проекта. Это включает в себя собственно приложение, а также любое вспомогательное программное обеспечение. Для простоты мы будем считать, что это программное обеспечение также представлено в виде пакетов RPM, которые подготавливаются разработчиками или инженерами по эксплуатации. Автоматизацию сборки пакетов мы здесь также осознанно обходим вниманием.
Если обобщить сказанное, то формально для описания желаемого окружения необходимо определить набор пакетов и их версии. Как следствие возникает необходимость также определить источники получения этих пакетов — репозитарии.
Описание требований к окружению производится в файле проекта. Смотри пример.
Как мы помним, в рассматриваемом примере было выделено три компонента, которым соответствуют три роли. BuildTracker непосредственно поддерживает описание окружений посредством ролей, которые представляют собой именованные наборы пакетов заданных версий. По имени на роль можно сослаться при описании окружения, чтобы включить в него её содержимое.
Смотри пример.
Результатом работы является сборка — репозитарий, в котором помимо указанных пакетов и их зависимостей будет присутствовать пакет проекта и пакет подключения репозитария. При установке последнего в систему управления пакетов добавляются настройки для полученного репозитария. Применительно к рассматриваемому примеру это означает, что после установки пакета подключения репозитария появляется соответствующий оному конфигурационный файл yum.
Пакет проекта, который доступен из репозитария проекта используется для развёртывания сборки. При его установке качестве его зависимостей автоматически устанавливаются все пакеты, указанные при описании проекта.
Так реализуются два свойства подхода — версионность и доступность. Первое — за счёт версии пакета проекта. Второе — за счёт репозитария проекта, который содержит все необходимые пакеты и держится нами в любом удобном нам месте.
После внесения изменений проекта для неого необходимо создать новую сборку. Ей будут соответствовать новые пакет репозитария проекта и пакет проекта, и это будет отражено в их версиях.
Следовательно, можно обновить окружение, установив новые версии этих двух пакетов.
- Примеры интеграции с автоматическими инсталляторами
- Примеры интеграции с Puppet и Chef
- Поддержка Debian/Ubuntu