CFEngine, Puppet, Chef, SAltStack and Ansible Failover'14

Сравнение систем управления конфигурациями

CFEngine3, Puppet, Chef, SaltStack, Ansible

Что такое CM-системы?

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

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

Общая схема работы CM-инструмента

RepositorySystem Input

Translation agent

Profile Profile Profile Profile

Managed device(Deployment agent)

Managed device(Deployment agent)

Managed device(Deployment agent)

История появления CM-инструментов

1. CFEngine (Mark Burgess), 1993

2. LCFG (Perl), 1994

3. ISConf, PIKT, STAF, 1997-1998

4. CFEngine2 (Convergence to desired state), 2002

5. BCfg (Python), 2002

6. Puppet, 2005

7. Chef (idempotence, flow control), 2009

8. CFEngine3 (Theory of promises), 2009

9. SaltStack (ZeroMQ), 2011

10. Ansible (CM, adhoc, deployment)

Как мы сравнивали CM-инструменты?

1. Свойства спецификации ввода1. Язык описаний2. Доступные механизмы абстракции3. Поддержка модульности4. Возможность управления

отношениями между узлами

2. Свойства процесса внедрения1. Масштабируемость2. Архитектура внедрения3. Поддержка платформ

3. Свойства управления спецификациями1. Удобство2. Версионность3. Документация4. Интеграция с окружением5. Права доступа

4. Поддержка продукта1. Доступная документация2. Коммерческая поддержка3. Сообщество4. Зрелость продукта

Какие CM-инструменты мы сравнивали?

1.CFEngine 3.0.4, 3.5.22.Puppet 2.7.*3.Opscode Chef 11.6.04.SaltStack 2014.1.05.Ansible 1.5

CM-инструментыCM-инструментыCM-инструменты

Свойства языка ввода спецификаций

CM-инструмент Декларативный/императивный DSL

DSL использует язык/стандарт

Наличие Web-интерфейса

СF Engine 3 Декларативный Свой Да, в платной версии

Puppet Декларативный/Императивные элементы

Свой/Ruby Да

Chef Императивный/Декларативные элементы

Ruby (в чистом виде) Да, только управление рецептами/кукбуками

Salt Декларативный/императивные элементы

YAML/Python Да, пока сырая версия

Ansible Декларативный/императивные элементы

YAML Да, только в платной версии Ansible Tower

Возможные механизмы абстракции DSL

A. Управление требованиями SLA к системе (например: «сконфигурировать достаточно почтовых серверов, чтобы обеспечить время SMTP-отклика N ms»)

B. Управление требованиями к ролям (классам) инстансов (например: «сконфигурировать N подходящих машин в качестве почтовых серверов»)

C. Управление требованиями к инстансам, независимо от их конкретной реализации (например: «сконфигурировать машины X,Y,Z как почтовые серверы»).

D. Управление требованиями к конкретным реализациям инстансов (например: «Создать/заменить следующие строчки в sendmail.cf на машинах X,Y,Z»)

E. Управление конфигурационными файлами (например: «положить конфигурационный файл sendmail.cf на сервер X»)

F. Управление двоичными образами конфигураций («залить образ виртуальной машины на сервер X»)

Возможные механизмы абстракции DSL

СМ-инструмент Возможные уровни абстракцииCFEngine 3 C, D, EPuppet С, D, EChef C, D, ESaltStack C, D, EAnsible C, D, E

Механизмы поддержки модульности

A. Статически описанные группы (Static)

B. Группы сформированные по запросу (Query based)

C. Иерархические группы (Hierarchical)

СМ-инструмент

Механизмы поддержки модульности

Возможность создания модулей 3 сторонами

CFEngine 3 A,B,C ДаPuppet A,B,C ДаChef A,B ДаSaltStack A,B ДаAnsible A Да

Механизмы моделирования отношений. Детальность.

A. Инстанс-инстанс. Примером такого отношения является приведенный выше пример зависимости между инстансом сервера DNS и его клиентов.

B. Параметр-параметр. Примером такой зависимости является, например, CNAME-запись, которая требует обязательного наличия соотвествующей A-записи в DNS.

C. Параметр-инстанс. Примером такой зависимости может быть зависимость mail-сервера от наличия MX-записи в DNS.

Механизмы моделирования отношений: Арность, Ограничения

Арность

A. One-to-one

B. One-to-many

C. Many-to-many

Ограничения

A. Ограничение с проверкой условия.

B. «Мягкое» ограничение. Одно из ряда.

СМ-инструмент

Детальность Арность Ограничения

CFEngine 3 A, B, C A, B, C B

Puppet A, B, C B, C A

Chef A, B, C B, C A

SaltStack A, B, C B, C A

Ansible Не поддержвает Не поддержвает Не поддержвает

Свойства процесса внедрения.

СМ-инструмент

Масштабируемость

Deployment architecture

Способ доставки

Platforms

CFEngine 3 10000 узлов Strongly distributed Pull, Push *BSD, AIX, HP-UX, Linux, Mac OS X, Solaris, Windows

Puppet Есть инсталляции

100k узлов

Centralized or weakly

distributed

Push, Pull *BSD, AIX, HP-UX, Linux, Mac OS X, Solaris, Windows

Chef > 10000, заявлено до 50000

Centralized or weakly

distributed

Pull, Push *BSD, Linux, Mac OS X, Solaris, Windows

SaltStack No info Centralized or weakly

distributed

Pull *BSD, AIX, HP-UX, Linux, Mac OS X, Solaris, Windows

Ansible 100 Centralized Push *BSD, AIX, HP-UX, Linux, Mac OS X, Solaris

Управление спецификациями.

СМ-инструмент

Простота Тесты Мониторинг Версион-ность репозиторий

Докумен-тирование

Окружения Права

CFEngine 3 Сложно Dry run Встроен Внешний Структ. Runtime Path-based

Puppet Средне Dry run, staging/testing

Интеграция с внешним

Внешний Свободная и структ.

Runtime, database

Path-based

Chef Сложно DevOps

Dry run, staging/testing

Интеграция с внешним

Встроенный и внешний

Свободная и структ.

Runtime, database

Path-based

SaltStack Средне Dry run Встроен с 0.15.0

Внешний Свободная Runtime, database

Встроенный ACL

Ansible Просто Dry run Интеграция с внешним

Внешний Свободная Runtime Нет

Поддержка продукта.

СМ-инструмент

Освоение Внедрение Документация Коммерч. поддержка

Сообщество Зрелость

CFEngine 3 2 3 Полная документация, туториал, справка

Есть 3 5

Puppet 3 4 Полная документация, туториал, справка

Есть 5 4

Chef 2 3 Полная документация, туториал, справка

Есть 5 5

SaltStack 4 3 Полная документация, справка

Есть 3 3

Ansible 5 5 Полная документация, справка

Есть 3 3

Выводы

Все системы достаточно хороши, но приспособлены немного для разного.

1) Если у вас есть ограничения по мощности машин и/или по коннективити – однозначно CFEngine

2) Если вы Ruby-developer – ваш выбор Chef

3) Если вы питонщик, то SaltStack понравится вам больше.

4) Если вы системный инженер/администратор и только начинаете осваивать СM-инструменты, попробуйте Ansible

5) Puppet имеет в своих списках внедрения ОГРОМНЫЕ (HUGE!) инфраструктуры.

Мы попробовали все системы в реальных конфигурациях, поэтому можем помочь вам с тем, как определиться. Да и вообще, написать все скрипты .

С вами был Сергей Житинский, CEO, Git in Skysergey@gitinsky.ru

А о конкретных кейсах внедрения расскажет главный инженер Git in Sky

Александр Чистяков

Краткий обзор CM-систем с высоты 10000 метров

§ Что-то большое и сложное, за день не облететь§ Кажется, в инфраструктуре есть сервер§ Раз есть сервер — значит, есть и клиенты§ Знакомо, не правда ли?§ CM-система — это сервер и клиенты (агенты)

Кстати, как называется конференция?

§ Мы еще ничем не начали управлять,§ А у нас уже прибавилось точек отказа!§ Кстати, сколько их теперь?§ Рассмотрим, например, архитектуру Chef-сервер§ (Это старая диаграмма, сейчас квадратиков

еще больше)

Мы же обещали кейсы! Не беспокойтесь, сейчас всё будет

§ Сначала я познакомился с Puppet, и это было

довольно давно§ Сейчас мы тоже работаем с Puppet§ Puppet — он как Windows, стремится быть

умнее своего пользователя§ Ключевые слова: RHEL, enterprise§ В 2014 году нам это уже не мешает (потому что современный

Puppet это такой почти Chef)

Chef: эта музыка может быть вечной

§ Chef — это очень большой и не очень

простой стек технологий§ К счастью, он очень гибкий§ К несчастью, из него могут застрелиться

даже его создатели§ Про Chef-сервер я уже говорил§ Безусловные плюсы: инфраструктура

тестирования (от юнит-тестов до интеграционных),

система управления зависимостями

Salt: альтернативная кулинария

§ Salt начинался как parallel execution tool§ Два других важных преимущества — очень

отзывчивое сообщество и простота (сервер -

один процесс, описание на YAML, старый

добрый Python в качестве языка ядра системы)§ Пытается догнать Chef и, в конце концов,

догонит§ Пока не догнал — используем с удовольствием, рекомендуем

и внедряем клиентам

Ansible: серебряной пули нет

§ Для автора Ansible это была уже вторая попытка§ Простота и легкость использования§ Очень большое удобство для решения повседневных

задач§ Нет необходимости в сервере§ Нет необходимости в агенте - «сервер» и клиент

общаются по SSH, нужен только интепрертатор Python§ ansible-pull

Обратно на 10000 метров

§ Прогресс не стоит на месте:

serverless Chef, serverless Puppet, serverless Salt§ Конкуренция идет:

производители с удовольствием копируют

друг у друга§ Пользователь пока выигрывает!

Подведение итогов и награждение

§ Спасибо за внимание!§ Мы готовы отвечать на вопросы§ С вами были Сергей Житинский и

Александр Чистяков§ sergey@gitinsky.com§ alex@gitinsky.com§ http://gitinsky.com, http://meetup.com/DevOps-40