Agile DevOps ― гибкая разработка и эксплуатация ПО: Автоматизация инфраструктуры

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

Сколько раз вы вручную выполняли одни и те же шаги при создании инфраструктуры или полагались на другую группу, которая настраивала для вас рабочую среду? А что, если все эти действия представить в виде сценариев и версий, как и остальные системы программного обеспечения? В этом выпуске Agile DevOps специалист по DevOps Пол Дюваль показывает, как автоматизировать процесс инициализации инфраструктуры с помощью инструментов Chef и Puppet. Он рассказывает об основах каждого из этих инструментов — а также об их сходстве, примерах применения и различиях - и приводит видеодемонстрацию Puppet.

Пол Дюваль, технический директор, Stelligent Incorporated

Paul DuvallПол Дюваль (Paul Duvall) является техническим директором компании Stelligent Incorporated – консалтинговой фирмы, которая помогает командам разработчиков оптимизировать гибкие методологии разработки программного обеспечения. Он также соавтор книги Continuous Integration: Improving Software Quality and Reducing Risk (Addison-Wesley, 2007 г.). Он принимал участие в создании книг UML 2 Toolkit (Wiley, 2003 г.) и No Fluff Just Stuff Anthology (Pragmatic Programmers, 2007 г.).



01.03.2013

Об этом цикле статей

Разработчики могут многому научиться у групп эксплуатации, а те ― у разработчиков. Эта серия статей посвящена изучению практического применения образа мышления групп эксплуатации к разработке и наоборот — а также рассмотрению программных продуктов в качестве целостных объектов, которые могут поставляться быстрее и чаще, чем когда бы то ни было.

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

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

За последнее десятилетие появилось несколько инструментов для поддержки автоматизации инфраструктуры ― как с открытым исходным кодом, так и коммерческих. В число инструментов с открытым исходным кодом входят 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-сообщество стремительно растет, передавая рецепты другим пользователям.

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

Будьте в курсе

Раздел Agile transformation портала developerWorks содержит новости, обсуждения и учебные материалы, которые помогут вам и вашей организации строить фундамент на принципах гибкой разработки (EN).

В 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

Puppet эксплуатируется с 2005 года. Многие крупные организации, включая Google, Twitter, Oracle и Rackspace, используют его для управления своей инфраструктурой. Puppet обычно требует более продолжительного обучения, чем Chef, и поддерживает различные инфраструктуры на базе Windows и *nix. У Puppet широкое и активное сообщество пользователей. Он применялся в тысячах организаций, эксплуатирующих установки с десятками тысяч экземпляров.

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

Puppet использует концепцию главного сервера — называемого Puppet master,— который централизует конфигурацию между узлами и группирует их по типу. Например, если имеется группа Web-серверов, на которых установлен Tomcat с Jenkins WAR, то на сервере Puppet master эти серверы группируются друг с другом. В качестве демона на системах работает Puppet agent. Это позволяет развертывать изменения инфраструктуры во многих узлах одновременно. Он функционирует так же, как менеджер развертывания, но вместо приложений развертывает изменения инфраструктуры.

В состав Puppet входит инструмент facter. Он содержит метаданные о системе и может использоваться для фильтрации серверов. Например, facter можно использовать для определения имени узла. С Puppet интегрирован инструмент развертывания MCollective. Его можно использовать для распространения среди узлов изменений инфраструктуры.

Ключевые компоненты Puppet перечислены в таблице 2.

Таблица 2. Ключевые компоненты Puppet
КомпонентОписание
АгентПроцесс-демон, запущенный в узле, который собирает сведения об узле и отправляет их в Puppet master.
КаталогСобрание фактов, определяющих способ настройки узла.
ФактыДанные узла, переданные им в Puppet master.
МанифестОписание ресурсов и зависимостей между ними.
МодульГруппа связанных манифестов (в каталоге). Например, модуль может определять, как установить, настроить и запустить базу данных, такую как MySQL.
УзелУзел, управляемый Puppet master. Узлы определяются как классы, но содержат имя узла или полное доменное имя.
Puppet masterСервер, управляющий всеми узлами Puppet.
РесурсНапример, пакет, файл или служба.

Примеры

В листинге 3 приведен пример манифеста Puppet с описанием пакетов, устанавливаемых в узле. Puppet определяет наилучший подход и порядок исполнения для процесса установки этих пакетов.

Листинг 3. Манифест Puppet для установки пакетов
class system {
  package { "rubygems": ensure => "installed" }

  package { "make": ensure => "installed" }
  package { "gcc": ensure => "installed" }
  package { "gcc-c++": ensure => "installed" }
  package { "ruby-devel": ensure => "installed" }
  package { "libcurl-devel": ensure => "installed" }
  package { "zlib-devel": ensure => "installed" }
  package { "openssl-devel": ensure => "installed" }
  package { "libxml2-devel": ensure => "installed" }
  package { "libxslt-devel": ensure => "installed" }
}

Фрагмент манифеста Puppet, приведенный в листинге 4, содержит примеры различных типов ресурсов — пакетов и служб, — которые можно использовать в сценариях инфраструктуры.

Листинг 4. Манифест Puppet для httpd
class httpd {
  package { 'httpd-devel':
    ensure => installed,
  }
  service { 'httpd':
    ensure => running,
    enable => true,
    subscribe => Package['httpd-devel'],
  }
}

Puppet использует декларативную модель с явным управлением зависимостями. Поэтому его, как правило, предпочитают инженеры с большим опытом системного администрирования, которым требуется составить сценарий своей среды.


Инфраструктура как код

В этой статье — на примерах — показано, что инфраструктура больше не нуждается в уникальных ручных усилиях, прилагаемых к отдельным узлам. Автоматизируя инфраструктуру, можно масштабировать ее вверх и вниз без каких-либо дополнительных трудозатрат. Так как инфраструктура моделируется в сценариях, ее версиями можно управлять и тестировать их точно так же, как версии кода приложений.

В следующей статье мы рассмотрим модели и методы для создания эфемерных (или кратковременных) сред — которые создаются и уничтожаются за 24 часа и иллюстрируют подход массовости (то есть отсутствия уникальности), который ассоциируется с Agile DevOps.

Ресурсы

Научиться

Получить продукты и технологии

  • Chef: несколько версий Chef.
  • Puppet: Puppet Enterprise.
  • IBM Tivoli Provisioning Manager: Tivoli Provisioning Manager позволяет создавать динамическую инфраструктуру, автоматизируя управление физическими серверами, виртуальными серверами, программным обеспечением, системами хранения данных и сетью.
  • IBM Tivoli® System Automation for Multiplatforms: Tivoli System Automation for Multiplatforms обеспечивает высокую готовность и автоматизацию приложений и ИТ-услуг по всей организации.

Комментарии

developerWorks: Войти

Обязательные поля отмечены звездочкой (*).


Нужен IBM ID?
Забыли Ваш IBM ID?


Забыли Ваш пароль?
Изменить пароль

Нажимая Отправить, Вы принимаете Условия использования developerWorks.

 


Профиль создается, когда вы первый раз заходите в developerWorks. Информация в вашем профиле (имя, страна / регион, название компании) отображается для всех пользователей и будет сопровождать любой опубликованный вами контент пока вы специально не укажите скрыть название вашей компании. Вы можете обновить ваш IBM аккаунт в любое время.

Вся введенная информация защищена.

Выберите имя, которое будет отображаться на экране



При первом входе в developerWorks для Вас будет создан профиль и Вам нужно будет выбрать Отображаемое имя. Оно будет выводиться рядом с контентом, опубликованным Вами в developerWorks.

Отображаемое имя должно иметь длину от 3 символов до 31 символа. Ваше Имя в системе должно быть уникальным. В качестве имени по соображениям приватности нельзя использовать контактный e-mail.

Обязательные поля отмечены звездочкой (*).

(Отображаемое имя должно иметь длину от 3 символов до 31 символа.)

Нажимая Отправить, Вы принимаете Условия использования developerWorks.

 


Вся введенная информация защищена.


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