В представленной работе решается задача автоматизации развертывания компонент распределенной системы при помощи средств Управления конфигурацией. В рамках работы рассмотрены существующие решения Управления конфигурацией, аргументирован выбор конкретных решений. Продемонстрированы сценарии автоматизации развертывания и модернизации компонентов системы с помощью выбранных средств.
Ключевые слова: автоматизация, развертывание, DevOps, управление конфигурацией, CFEngine, Puppet, Chef, Ansible, SaltStack
В настоящее время, в связи с постоянным возрастанием сложности вычислительных задач и необходимостью работы с данными больших объемов, все большее распространение получают технологии распределенной обработки данных. В условиях неконтролируемого прироста информации и постоянного увеличения необходимых для ее обработки ресурсов возникает потребность в непрерывном горизонтальном масштабировании распределенных систем. В связи с этим обнаруживается ряд требований к подобным системам, например: необходимость быстрого введения в эксплуатацию новых элементов распределенной системы, возможность изменения ее архитектуры без ущерба текущей работоспособности и автоматизация вышеприведенных процессов.
Данная работа посвящена изучению современных средств Управления конфигурацией IT-инфраструктуры и выполнению задачи по внедрению потенциально наиболее подходящих из них в разработанную ранее распределенную систему. В ходе работы рассматривается архитектура распределенной системы, нуждающейся в автоматизации, выдвигаются требования к используемым средствам автоматизации, рассматриваются и сравниваются существующие на рынке решения, производится внедрение выбранных средств.
Обзор инфраструктуры распределенного приложения
Рис. 1. Архитектура рассматриваемого приложения
Нуждающееся в автоматизации приложение обладает распределенной архитектурой с наличием единого центрального и множества локальных, взаимодействующих с ним серверов, расположенных на удаленных филиалах. Помимо локального сервера, каждый удаленный филиал подразумевает наличие клиентских узлов с установленными на них компонентами приложения (см. Рис. 1.). В качестве хранилища данных, на каждом из локальных серверов используется СУБД MSSQLServer. Компоненты системы разработаны на платформе.NET на языке C#. В рамках текущей работы решается задача автоматизации развертывания удаленных филиалов приложения.
Процесс ручного развертывания инфраструктуры отдельно взятого филиала производится в несколько этапов. Первый этап, настройка сервера баз данных:
– Получение удаленного доступа к серверу через приложение TeamViewer с помощью сотрудников филиала
– Установка SQL Server 2014 Express WT.
– Настройка разрешающих правил брандмауэра порту 1433.
– Включение и настройка протокола TCP/IP
– Развертывание базы данных филиала и необходимых файлов
Второй этап, настройка программных компонентов системы на узлах филиала: Задачи данного этапа решаются при помощи средства развёртывания ClickOnce, позволяющего проводить установку Windows-приложений в автоматическом режиме после ручного запуска единственного скрипта. Подобные скрипты написаны для каждого из компонентов приложения и запускаются вручную на каждом из необходимых узлов сотрудниками филиала.
Третий этап, тестирование: После того, как проведена настройка локального сервера, и установлены необходимые компоненты на клиентские машины, сотрудниками филиала осуществляется попытка подсоединения к локальному серверу с одного из узлов. В случае успеха, процесс развертывания филиала считается завершенным.
На основании рассмотренного процесса ручного развертывания системы необходимо отметить, что, на данный момент, наиболее трудозатратным и незащищенным от возможных ошибок является процесс конфигурирования локального сервера филиала. Таким образом, в рамках текущей архитектуры приложения, задача автоматизации управления системой главным образом сводится к задаче автоматизации дистрибуции и управления локальными серверами филиалов с помощью средств Управления конфигурацией.
Учитывая внутреннюю архитектуру компонентов, распределенную архитектуру приложения и описанный выше процесс ручной дистрибуции, в рамках поставленной задачи можно выделить следующие основные требования к ПО Управления конфигурацией:
- Возможность работы с файловой системой;
- Возможность изменения сетевого окружения;
- Возможность автоматической дистрибуции, конфигурирования и запуска приложений;
- Возможность выполнения вышеозначенных задач на узле под управлением OCWindows;
- Минимизация необходимости ручной работы непосредственно на развертываемом узле
DevOps иУправление конфигурацией
Для решения задач введения в эксплуатацию отдельных элементов распределенных систем, а также возможности изменения архитектуры распределенных приложений вне зависимости от этапа их жизненного цикла в рамках серии встреч «DevOpsDays» в 2009 году была предложена новая методология разработки Программного Обеспечения DevOps[1] (developmentandoperations: разработка и IT-операции), основанная на идеи тесной взаимосвязи разработки и эксплуатации программного обеспечения.
Рис. 2. Принцип методологии DevOps
Главной целью DevOps является создание единого цикла взаимозависимости между разработкой, развертыванием и эксплуатацией ПО для помощи организациям в быстром создании и обновлении их программных продуктов, используемых в режиме реального времени. Данная цель достигается путем создания между отделом разработки, IT-отделом и заказчиком «промежуточного звена» (см. Рис. 2), ответственного за оптимизацию всех этапов производства приложения, нуждающегося в непрерывном обновлении.
Различные модели внедрения DevOps подразумевают тесную интеграцию IT-отдела с Отделом разработки [2]. При этом прослеживается необходимость непрерывно контролировать инфраструктуру создаваемого ПО. В том числе для решения данной задачи существует комплекс методов под общим названием «Управление Конфигурациями» [3]. Конечной целью данного комплекса является представление инфраструктуры ПО частью создаваемого приложения, с возможностью автоматического контроля над всеми изменениями, происходящими в ней. При подобном подходе появляется возможность автоматизации изменений в инфраструктуре приложения в зависимости от изменений в его архитектуре, что позволяет решать проблемы, свойственные постоянно модернизирующимся распределенным системам.
В данной работе, в соответствии с сформулированными в предыдущей главе требованиями, производится обзор и сравнительный анализ следующих представленных на рынке средств Управления конфигурацией: CFEngine 3, Puppet, Chef, Ansible, SaltStack, с целью выбора наиболее подходящих из них в рамках поставленной задачи.
CFEngine
CFEngine [4] является первым из появившихся на рынке средств Управления Конфигурацией. CFEngine 1 разработан и представлен в 1993 году в Университете Осло (Норвегия) с целью автоматизации управления серверов кафедры Теоретической физики. На сегодняшний день последней версией программы является, представленная в 2008 году, CFEngine 3, главным нововведением которой является концепция “Теории обещаний” (“Promisetheory”) [5], используемая в качестве языка описания, подразумевающая декларативный подход к управлению инфраструктурой с отсутствием непосредственных инструкций к находящимся под управлением узлам.
CFEngine представляет собой сильно распределенную систему с отсутствием управляющего узла. Большинство компонент независимо друг от друга и то, какие из них будут установлены на конкретный узел, зависит от его роли в текущей инфраструктуре.
Все изменения могут осуществляться как “Pull”, так и “Push” методами. Различные компоненты CFEngine позволяют производить автоматическое развертывание, конфигурирование, мониторинг и взаимодействие управляемых узлов. CFEngine распространяется как по Open-source, так и по коммерческой лицензии. В Enterprise-версии Системы присутствует web-интерфейс, упрощающий работу с узлами. Рассмотренное средство поддерживает семейство Unix-систем, а также MacOSX и Windows.
Puppet
Puppet [6] — средство управления конфигурацией, изначально сориентированное на использование в промышленных целях. Первая версия системы представлена в 2005 году. На текущий момент представлена уже четвертая версия системы.
Архитектура Puppet построена на двух взаимодействии двух отдельных модулей: PuppetMaster, устанавливаемый на управляющие узлы, и PuppetAgent, устанавливаемый на управляемые. Подобное решение подразумевает либо централизованную, либо слабо-распределенную архитектуру и обеспечивает высокую степень горизонтального масштабирования.
В Puppet используется декларативный стиль описания конфигураций на собственном предметно-ориентированном языке, основанном на синтаксисе Ruby. В качестве методов доставки конфигурации данное решение сочетает “Push” и “Pull” технологии.
Существуют Open-source и Enterprise версии Puppet, отличающиеся наличием дополнительных встроенных компонент управления инфраструктурой (в частности Web-интерфейса), средств мониторинга, дополнительными модулями, доступными в официальной библиотеке. Данная система поддерживает операционные системы Unix, MacOCX, Windows для управляемых узлов и системы семейства Unix для управляющих.
Chef
Chef [7]— средство управления конфигурацией, изначально представленное в 2009 году, и, к настоящему времени, реализованное уже в двенадцатой версии. Chef обладает схожей с Puppet концепцией построения инфраструктуры, при этом отличаясь как в методах описания конфигурации, так и в методах ее внедрения.
Архитектура Chef, по аналогии с Puppet основывается на двух основных компонентах: ChefServer и ChefClient, функционирующих на управляющем и управляемом узлах соответственно. В случае с Chef, к данным компонентом добавляется ChefWorkstation, предназначенный для управления взаимодействием двух предыдущих компонент. Также возможно создание изолированного управляемого узла. Важным отличием данной системы является возможность автоматической дистрибуции ChefClient на управляемые узлы.
Chef использует императивный стиль описания конфигурации средствами языка Ruby. Инструкции по приведению узла в необходимое состояние содержатся в, так называемых, Cookbook`ах, объединяющих в себе набор рецептов — инструкций и требуемые файлы. В общем случае, данная система использует метод доставки конфигурации по запросу: “Pull”. Возможность дистрибуции конфигураций одновременно на большое количество серверов “Push” методом реализуется с помощью отдельного расширения Enterprise-версии Chef.
Chef распространяется в трех возможных версиях: OnpremisesChef, HostedChef, OpenSourceChef. В качестве поддерживаемых платформ для управляющего компонента выступают операционные системы семейства Unix, для управляемых компонентов и ChefWorkstation — Unix, MacOCX, Windows.
Ansible
Ansible [8] является наиболее новым из обозреваемых Средств управления конфигурацией: проект был представлен в 2012 году. Система позиционируется как средство для решения повседневных задач системного администрирования в силу простоты освоения и быстроты внедрения желаемых конфигураций.
Ключевой особенностью архитектуры Ansible является отсутствие “агента” на управляемом узле. Требования к управляемому узлу ограничиваются установленной на нем необходимой версии Phyton и возможностью доступа к нему по ssh. Таким образом, единственным возможным методом доставки конфигурации для Ansible является “Push”, а единственная возможная Ansible архитектура — централизованная.
Ansible использует декларативный стиль описания конфигурации формата YAML. Описание желаемых конфигураций для управляемых узлов осуществляется с помощью инвентарного файла, так называемых “Playbook`ов”, файлов ролей и файлов модулей. С помощью данных инструментов поддерживаются списки управляемых узлов, информация о том, к какому состоянию каждый из них необходимо привести и средства, которыми будет достигнут результат.
Ansible распространяется в Open Source и Enterprise (Ansible Tower) версиях. Начиная с версии 1.7 Ansible предоставляет возможность работы с OCWindows с помощью PowerShell, но, стоит заметить, что, в связи с относительно недавним началом поддержки, количество готовых Windows-решений не столь велико.
SaltStack
Система управления конфигурациями SaltStack [9] разработана в 2011 году разработчиками пакета скоростного обмена сообщениями ZeroMQ [19]. На основании данного решения построен сетевой уровень SaltStack. Основная идея данного средства схожа с идеей Ansible: максимально интуитивное и быстрое управление конфигурациями. При этом, ключевым отличием от предыдущего решения является наличие клиента, позволяющего выполнять с помощью SaltStackболее комплексные задачи.
SaltStack основывается на двух компонентах: SaltMaster, устанавливаемым на управляющий узел, и SaltMinion, устанавливаемом на управляемые узлы. Система подразумевает как централизованную, так и слабо-распределенную архитектуру управления конфигурациями, с возможностью распределения нагрузки между управляющими узлами. SaltStack сочетает “Pull” и “Push” методы доставки конфигурации с помощью собственного асинхронного протокола. Описание требуемой к развертыванию конфигураций, в случае с SaltStack может носить как декларативный, так и императивный характер.
В качестве возможного ПО для SaltMaster выступают Unix-системы, а для SaltMinion также MacOSX и Windows.
Таблица 1
Сравнение представленных средств
|
CFEngine 3 |
Puppet |
Chef |
Ansible |
SaltStack |
|
|
Архитектура системы |
Сильно распределенная |
Централизованная, слабо распределенная |
Централизованная, слабо распределенная |
Централизованная |
Централизованная, слабо распределенная |
|
Работа с узлами ОС Windows |
Поддержка всеми типами узлов |
Поддержка управляемыми узлами, наличие документации, готовые решения от сообщества |
Поддержка управляемыми узлами, отсутствие отдельной документации, библиотека Chocolatey, готовые решения от сообщества |
Поддерживает, Наличие документации |
Поддержка управляемыми узлами, наличие документации, отдельный репозиторий |
|
Необходимость работ на управляемом узле |
Ручная установка клиента |
Ручная установка клиента |
Автоматическая установка клиента |
Клиент отсутсвует |
Ручная установка клиента |
В Таблице 1 представлены характеристики рассмотренных средств Управления конфигурацией, наиболее существенно повлиявшие на дальнейший выбор используемых средств. Также, можно выделить ряд особенностей изученных систем, таких как: высокая степень масштабируемости CFEngine за счет сильно распределенной архитектуры, удобство управления инфраструктурой со множеством различных конфигураций Puppet с помощью специфического языка описания управления узлов, наличие максимально большого количества готовых решений Chef, отсутствие необходимости дистрибуции дополнительного ПО на управляемый узел Ansible, параллельное исполнение процессов SaltStack средствами сетевого уровня приложения ZeroMQ.
Для выполнения текущей задачи необходима система с централизованной архитектурой, поддержкой OCWindows для управляемых узлов и, при этом, возможностью максимально дистанцироваться от взаимодействия с ними. С учетом данных требований, для дальнейшего практического изучения в рамках текущей задачи, а также на основании сравнительных статей [10, 11] был выбран Chef, как средство управления, имеющее автоматическое развертывание части своих компонент и обширную библиотеку пользовательских решений, а также Puppet, как наиболее зрелый продукт, среди представленных решений с централизованной архитектурой.
Сценарий развертывания
Средствами Chef и Puppet был автоматизирован следующий сценарий развертывания:
- Установка SQL сервер, настройка окружения:
– Установка SQL Server 2014 Express WT;
– Настройка разрешающего правила в брандмауэре;
– Включение протокола TCP/IP в диспетчере конфигурации сервера;
– Создание разрешающего правила брандмауэра для входящего трафика;
- Настройка сетевого окружения филиала:
– Создание локального пользователя;
– Создание общей папки на чтение и запись для созданного пользователя;
– Создание сетевого диска на созданную общую папку;
- Развертывание базы данных и файловой системы:
– Запуск конфигурационного SQL скрипта;
– Извлечение содержимого файлового архива в созданную общую папку;
Автоматизация развертывания сервера при помощи Puppet
Автоматическое конфигурирование управляемых Puppet узлов осуществляется средствами так называемых “манифестов”. Каждый манифест содержит в себе следующие элементы языка описания конфигурации:
– Ресурсы: являются базовым инструментом приведения отдельных компонентов узла в необходимое состояние. Существует большое количество ресурсов для взаимодействия с файловой системой, управления системными службами и прочее. Каждый примененный ресурс, в соответствии с декларативным способом описания конфигурации Puppet, указывает, в каком состоянии должен находится тот или иной элемент управляемого узла.
– Классы: реализуют уровень абстракции, позволяя объединять различные ресурсы в единые конструкции для выполнения комплексных задач. Поддерживают механизмы наследования и переопределения атрибутов используемых ресурсов.
– Узлы (nodes): определяют, к каким именно управляемым узлам будут применяться те или иные ресурсы и классы. Также поддерживают механизм наследования, тем самым предоставляя гибкость в управлении сетевым окружением.
– Ссылки на манифесты: позволяют использовать классы и узлы, расположенные в другом манифесте.
Помимо данных элементов в Puppet существует понятие “модулей”. Модуль представляет собой набор каталогов, содержащих файлы, классы, манифесты и сторонние библиотеки с целью их структуризации и единого применения к управляемым узлам.
Автоматизация развертывания сервера при помощи Chef
Были применены следующие средства описания процесса автоматического развертывания Chef:
– Сookbook: общий способ хранения конфигурации, предназначенной для развертывания на управляемых узлах. Содержит в себе так называемые “рецепты”, файлы атрибутов, шаблонов и метаданных. Каждый cookbook представляет собой готовое решение некоторой задачи на управляемых узлах. Как правило, “Поваренные книги” свободно распространяются сообществом пользователей Chef, следствием чего является наличие готовых решений для распространенных задач Управления конфигурацией. Существует также официальный репозиторий пользовательских решений, с возможностью быстрой установки необходимого Сookbook`а.
– Рецепт: файлы Ruby, в которых, при помощи языка DSL, описывается необходимое состояние управляемого узла. Каждый сookbook может содержать различное количество рецептов, по умолчанию запускается рецепт default.rb, при этом одни рецепты могут запускаться из других. Описание состояния узла в рецепте происходит при помощи так называемых “Ресурсов”.
– Ресурс: назначение Chef-ресурсов аналогично назначению Puppet-ресурсов, описанному выше: ресурсы Chef являются базовыми инструментами приведения отдельных компонентов узла в необходимое состояние. Ресурсы представляют собой лаконичную абстракцию над Провайдерами — внутренними компонентами Chef, автоматически определяющими, какие действия нужно произвести при вызове Ресурса, в зависимости от конкретной ситуации данного вызова.
– Атрибуты: файлы атрибутов представляют собой файлы хранения данных, необходимых для работы конкретного Сookbook`a. Данные файлы содержат информацию, использующуюся в рецептах, а также производят генерирование динамических данных при запуске “Поваренной книги” (например: ip-адрес управляемого узла).
– Шаблоны: шаблоны предоставляют возможность автоматического генерирования общих файлов Cookbook`а на основе его атрибутов.
– Метаданные: файл метаданных содержит в себе всю базовую информацию о конкретном Cookbook`e, включая имя, версию, создателя, список зависимостей.
Кроме понятия Cookbook и его составляющих, в Chef также присутствует возможность создания так называемой “Роли” — списка запуска нескольких Cookbook`ов для приведения узла в необходимое состояние в соответствии с его “Ролью”.
Выводы
Оба представленных средства успешно справляются с поставленной задачей: С их помощью были разработаны два одинаковых по функционалу прототипа, автоматизирующих наиболее трудоемкую часть развертывания филиала.
Сравнивая методы, которыми решается поставленная задача в том и в другом случае, можно заметить, что наличие в свободном доступе большого числа пользовательских решений в случае с Chef позволяет, в сравнении с Puppet, значительно сократить количество выполняемых внешних команд в процессе развертывания. Также стоит подчеркнуть, что, благодаря декларативному стилю описания конфигураций, поддержки наследования и отношению к управляемой инфраструктуре как к программному коду, Puppet, в сравнении с Chef, предоставляет более широкие возможности по управлению обширной инфраструктурой со множеством ролей.
Заключение
В рамках данной работы, с целью автоматизации развертывания компонент распределенного приложения, было произведено изучение понятий DevOps и Управление конфигурацией, рассмотрены существующие программные решения по Управлению конфигурацией с последующем сравнением перспективности в рамках решаемой задачи. С помощью двух выбранных средств была автоматизирована часть процесса развертывания системы с последующими выводами и сравнением полученных результатов.
Литература:
- DevOps. http://devopswiki.net/index.php/DevOps
- Модели развертывания DevOps. http://www.osp.ru/os/2013/05/13035991/
- Управление конфигурацией. http://www.sei.cmu.edu/productlines/frame_report/config.man.htm
- Документация CFEngine. https://docs.cfengine.com/lts/
- Теория обещаний в CFEngine.http://www.networkworld.com/article/2449562/sdn/promise-theory-mark-burgess-cfengine-sdn-cisco-aci-apic-opflex.html
- Документация Puppet. https://docs.puppet.com/
- Документация Chef. https://docs.chef.io/
- Документация Ansible. http://docs.ansible.com/
- Документация SaltStack. https://docs.saltstack.com/
- Сравнение инструментов управления конфигурацией. http://www.infoworld.com/article/2609482/data-center/data-center-review-puppet-vs-chef-vs-ansible-vs-salt.html
- Сравнение Puppet и Chef. https://www.upguard.com/blog/puppet-vs-chef-battle-wages
