Agile DevOps ― гибкая разработка и эксплуатация ПО

Автоматизация инфраструктуры

Представление инфраструктуры в виде кода с помощью инструментов Chef или Puppet

Comments

Серия контента:

Этот контент является частью # из серии # статей: Agile DevOps ― гибкая разработка и эксплуатация ПО

Следите за выходом новых статей этой серии.

Этот контент является частью серии:Agile DevOps ― гибкая разработка и эксплуатация ПО

Следите за выходом новых статей этой серии.

Автоматизация инфраструктуры — это процесс написания сценариев среды ― от установки операционной системы до установки и Настройки серверов в экземплярах, связей между экземплярами и ПО и т.п. Среда, описанная сценариями, позволяет применять одну и ту же конфигурацию к одному узлу или к тысячам узлов.

Автоматизация инфраструктуры выступает и под другими названиями: управление конфигурацией, управление ИТ, инициализация, описываемые сценариями инфраструктуры, управление конфигурацией систем ― и многими другими пересекающимися терминами. Смысл все тот же: инфраструктура и ее конфигурация описывается сценарием или набором сценариев, так что среду можно реплицировать с гораздо меньшим риском ошибок. Автоматизация инфраструктуры вносит гибкость как в процесс разработки, так и в эксплуатацию, потому что любой уполномоченный член команды может изменять сценарии с применением к инфраструктуре надлежащих методов разработки ― таких как автоматизированное тестирование и управление версиями.

За последнее десятилетие появилось несколько инструментов для поддержки автоматизации инфраструктуры ― как с открытым исходным кодом, так и коммерческих. В число инструментов с открытым исходным кодом входят Bcfg2, CFEngine, Chef и Puppet. Их можно использовать в облаке и в физических или виртуальных средах. В этой статье я сосредоточусь на наиболее популярных инструментах автоматизации инфраструктуры с открытым исходным кодом: Chef и Puppet. Читатель не освоит всех тонкостей работы с каждым из инструментов, но получит представление о сходствах и различиях между ними, а также познакомится с некоторыми показательными примерами. Более подробный пример установки и использования инструмента автоматизации инфраструктуры приводится в видеодемонстрации к этой статье, где показано, как использовать Puppet в облачной среде.

Для сценариев среды Chef и Puppet используют предметно-ориентированный язык (DSL) Ruby. В Chef применяется внутренний Ruby DSL, а пользователи Puppet работают главным образом с внешним DSL ― также написанным на Ruby. Эти инструменты, как правило, используются в Linux®-системах автоматизации, но поддерживают и Windows. Клиентская база Puppet больше, чем у Chef, и он предлагает более широкую поддержку устаревших операционных систем. Puppet позволяет устанавливать связи с другими задачами. Оба инструмента являются идемпотентными ― то есть при одной и той же конфигурации дают один и тот же результат, сколько бы раз их ни запускали.

Chef

Chef существует примерно с 2009 года. Он создан под влиянием Puppet и CFEngine. Chef поддерживает несколько платформ, включая Ubuntu, Debian, RHEL/CentOS, Fedora, Mac OS X, Windows 7 и Windows Server. Его часто называют более простым в применении — особенно для разработчиков Ruby, потому что все в Chef определяется в виде Ruby-сценария и соответствует модели, которой пользуются разработчики. Chef имеет базу ревностных пользователей, и это Chef-сообщество стремительно растет, передавая рецепты другим пользователям.

Как это работает

В Chef три основных компонента взаимодействуют друг с другом —сервер Chef, узлы и рабочая станция Chef. Chef исполняет в узлах рецепты, состоящие из автоматизированных шагов ― называемых действиями, ― таких как установка и настройка программного обеспечения или добавление файлов. Сервер Chef содержит данные о конфигурации для управления несколькими узлами. Узлы при необходимости извлекают файлы конфигурации и ресурсы, хранящиеся на сервере Chef. К ресурсам относятся, например, файлы, пакеты, хроны (cron) и выполнение (execute).

Пользователи взаимодействуют с сервером Chef с помощью интерфейса командной строки, называемого Knife. Узлы могут иметь одну или несколько ролей. Роль определяет атрибуты (специфические параметры) и рецепты для узла и может применять их к нескольким узлам. Рецепты могут исполнять другие рецепты. Рецепты для узла, называемые рабочим списком (run list), выполняются по порядку. Рабочая станция Chef представляет собой экземпляр с установленными на нем локальным репозиторием Chef и интерфейсом Knife.

Основные компоненты Chef перечислены в таблице 1:

Таблица 1. Компоненты Chef
КомпонентОписание
АтрибутыОписание данных узла, таких как IP-адрес и имя хоста.
Клиент ChefРаботает от имени узла. Один клиент Chef может исполнять рецепты для нескольких узлов.
Chef SoloПозволяет исполнять рецепты Chef без сервера Chef.
"Поваренные книги" (cookbooks)Содержат все ресурсы, необходимые для автоматизации инфраструктуры, и могут передаваться другим пользователя Chef. Поваренные книги обычно состоят из нескольких рецептов.
Пакеты данныхСодержат глобально доступные данные, которые используются узлами и ролями.
KnifeИспользуется системными администраторами для загрузки изменений конфигурации на сервер Chef. Knife используется для связи между узлами через SSH.
Консоль управленияWeb-интерфейс сервера Chef для управления узлами, ролями, поваренными книгами, пакетами данных и API клиентов.
УзелУзлы, на которых исполняется клиент Chef. Основные функции узла с точки зрения Chef ― это его атрибуты и рабочий список (run list). Узлы ― это компоненты, к которым применяются роли и рецепты.
OhaiНаходит данные об используемой операционной системе. Может работать и в автономном режиме, но его основная цель заключается в снабжении Chef данными об узлах.
РецептБазовая конфигурация в формате Chef. Рецепты содержат наборы ресурсов, которые выполняются в порядке, определенном для настройки узлов.
Репозиторий (репозиторий Chef)Место, где размещаются поваренные книги, роли, файлы конфигурации и другие артефакты для управления системами с помощью Chef.
РесурсКроссплатформенная абстракция того, что настраивается в узле. Например, учетные записи пользователей и пакеты на разных платформах ОС можно настроить по-разному; Chef скрывает детали этого процесса от пользователя.
РолиМеханизм для группирования аналогичных свойств подобных узлов.
Сервер (сервер Chef)Централизованное хранилище конфигурации сервера.

Примеры

Листинг 1 демонстрирует использование ресурса service в рецепте, который является частью поваренной книги для Tomcat. Как видите, такие инструменты, как Chef, можно использовать для настройки конкретной платформы и управления конфигурацией сервера.

Листинг 1. Рецепты Chef
service "tomcat" do
  service_name "tomcat6"
  case node["platform"]
  when "centos","redhat","fedora"
    supports :restart => true, :status => true
  when "debian","ubuntu"
    supports :restart => true, :reload => true, :status => true
  end
  action [:enable, :start]
end

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

Листинг 2. Атрибуты Chef
default["tomcat"]["port"] = 8080
default["tomcat"]["ssl_port"] = 8443
default["tomcat"]["ajp_port"] = 8009

Chef расширяет язык Ruby ― по сравнению с внешним DSL, ― предоставляя модель для применения конфигурации сразу ко многим узлам. Chef использует императивную модель без явного управления зависимостями, поэтому, когда сценарии среды составляют люди с большим опытом разработки, они, как правило, тяготеют к Chef.

Puppet

static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=40
Zone=Технология Java
ArticleID=860112
ArticleTitle=Agile DevOps ― гибкая разработка и эксплуатация ПО: Автоматизация инфраструктуры
publish-date=03012013