 |
|
|
|
Системы управления конфигурацией. Чем отличаются Chef, SaltStack, Puppet, CFEngine и Ansible?
Системы управления конфигурацией В статье рассматриваются четыре важнейшие группы свойств систем управления конфигурацией, по которым делается сравнение популярных CM-инструментов Компьютеры, которые работают в качестве серверов, должны обладать в первую очередь повышенной надежностью и бесперебойностью в работе. Для этого, кроме прочего, им нужно обеспечит очень хорошую управляемость. Это достигается многими технологиями и, в том числе, применением программных систем управления конфигурациями. По-английски эти системы называются Configuration Management (CM). На рис.1 изображена типичная организация компонентов программного CM-инструмента в общем случае. Operator – это вы – системный инженер, который эксплуатирует систему. В Repository хранятся вводные данные – спецификации, которые описывают инфраструктуру или сервер. Спецификация переводится в profile на Translation Agent. Эти данные передаются (или забираются) на управляемые узлы (managed devices) и превращаются там в набор исполняемых команд при помощи компонента внедрения (deployment agent).
Рисунок 1. Общая схема работы CM-системы CM-системы позволяют настраивать сервера не руками, а программным способом. Они автоматизируют труд системных администраторов, превращая их в системных инженеров. Серверы при этом настраиваются быстро и безошибочно (если, конечно, сами управляющие скрипты-рецепты-плейбуки были написаны без ошибок). Кроме того, система управления конфигурацией позволяет следить за изменениями состояния сервера и поддерживать на нем стабильную эталонную конфигурацию. Решение подобной задачи необходимо, как правило, на довольно крупных системах, так как позволяет экономично эксплуатировать большой парк однотипных серверов. Однако теперь все чаще можно встретить использование CM на небольших проектах, изначально закладывающих в архитектуру несколько ролей серверов и стандартных окружений (разработка-тест-продакшн). Управление конфигурацией через код, хранимый в репозитории, существенно повышает управляемость процессом настройки и администрирования ИТ-инфраструктуры. Эта парадигма приобрела даже свою собственную аббревиатуру – IaaC – Infrastructure as a Code. Поскольку интерес к CM-продуктам неуклонно растет, в данной статье мы попытались проанализировать и сравнить самые популярные из них. История возникновения популярных CM-инструментов Первая система управления конфигурацией, появившаяся на рынке, была CFEngine. Основатель и бессменный руководитель проекта CFEngine – норвежский ученый Марк Бургес, работающий в университете города Осло. Первая версия продукта вышла в 1993 году. По понятным причинам основными параметрами системы должны были стать легковесность и нетребовательность к ресурсам, особенно к сетевым. Действительно, особенности архитектуры позволяли настраиваемым компьютерам преспокойно жить даже в отсутствии связи с управляющей машиной. Почти одновременно, в 1994 году, выходит LCFG – CM-система на Perl, разработанная в Эдинбургском университете. В отличие от CFEngine, система использовала централизованную архитектуру с обработкой запросов узлов на центральном сервере. В 1998 году появляется еще несколько систем – ISConf, PIKT, STAF. Честно говоря,мы не исследовали их подробно, важно, что на этом рынке уже была конкуренция. В 2002 году выходит CFengine2 – версия, в которой вводятся понятия convergence to desired state и self-healing. Эти парадигмы позволяли управляемым компьютерам самостоятельно обнаруживать отклонения от желаемого состояния и возвращаться к нему путем выполнения определенных команд или операций. В 2000-е годы появляется еще несколько разработок, из которых самой популярной становится BCfg2 на Python. В этой системе не было изначально модульности и она не позволяла подняться выше уровня абстракции «Configuration files» (см. ниже). Но система была написана на Python и поэтому привлекла к себе внимание сообщества «питонщиков». В 2005 году один из продвинутых пользователей CFEngine2 Luke Kanies решает сделать свой продукт, в связи с тем, что он был недоволен тем, как Марк Бургес управлял развитием CFEngine. Действительно, ученые, при всем к ним уважении, редко бывают хорошими управленцами или бизнесменами. Так родился Puppet, отличительными особенностями которого стал движок моделей на основе графов состояний, простой и понятный DSL-язык описаний на основе Ruby и изначальная ориентированность на сообщество разработчиков. Все эти инновации были востребованы рынком, поэтому Puppet стал активно внедряться в промышленную эксплуатацию. В 2008 году Марк Бургес и его проект CFEngine3 ответили Puppet более удобным языком описаний и новой стройной концепцией, которая называлась Theory of Promises – теория обещаний. В одноименной книге Бургес попытался описать «обещания» как технический объект, а не юридически-моральный, как было принято до него. Концепция была внедрена в продукт и теперь, если вы хотите настроить сервер при помощи CFEngine3, вы должны разобраться, что такое «обещание» и кто кому их дает среди серверов вашего проекта. В 2009 году несколько активных членов сообщества Puppet во главе с Adam Jacobs в свою очередь решили отпочковаться и создать свой продукт, который они назвали Chef. В отличие от Puppet, и его якобы «недетерминированности», в Chef все операции идут в том порядке, в котором их написал программист. Кроме того, язык описаний (DSL) в Chef – это просто Ruby, что позволило привлечь разработчиков на этом популярном языке к созданию первичной базы скриптов (в терминологии Chef – рецептов). В 2011 разработчики суперскоростного пакета обмена сообщениями ZeroMQ создают свою CM-систему SaltStack, преимуществом которой является именно скоростная коммуникация между узлами сети. В 2012 стартовал проект Ansible – система управления конфигурациями, с возможностью решения ad-hoc задач, без софтверного агента на управляемом узле. Работает через SSH, на управляемом узле требуется только Python версии 2.4+. Как следствие эта программа не позволяет управлять зависимостями между узлами инфраструктуры. Как видим, пакетов достаточно много, познакомиться с ними можно в Википедии [1]. Причем это сравнение не содержит проприетарные инструменты от компаний IBM, HP, Microsoft, Dell и других серьезных производителей решений. Мы выбрали для анализа только самые известные из Open Source решений, которые используются на реальных проектах и, что немаловажно, используются реальными клиентами нашей компании Git in Sky, то есть мы имели опыт работы с ними в реальных задачах. Итак, эти инструменты:
Методология сравнения В своем исследовании мы опирались на методологию [2], разработанную в 2010 году в бельгийском университете Katholieke Universiteit Leuven. Статью целиком читайте в журнале «Системный администратор», №6 за 2014 г. на страницах 35-39. PDF-версию данного номера можно приобрести в нашем магазине. |
СЕРГЕЙ ЖИТИНСКИЙ, генеральный директор Git in Sky (ООО «Жить в небе»), 
АЛЕКСАНДР ЧИСТЯКОВ, главный инженер Git in Sky (ООО «Жить в небе»), 
Комментарии отсутствуют
| Добавить комментарий |
|
Комментарии могут оставлять только зарегистрированные пользователи |
|
