Необходимость использования средств управления конфигурацией в процессе эксплуатации сложных веб систем быстро становится очевидной, тем не менее, использование различных средств управления конфигурацией имеет свои нюансы и тонкости. Разные системы управления конфигурацией создавались с учетом различающихся требований их создателей, и они по-разному решают возложенные на них задачи. Доклад посвящен обобщению практического опыта применения четырех средств управления конфигурацией — Chef, Puppet, SaltStack и Ansible в гетерогенных окружениях разного размера, построенных на базе различных UNIX-подобных платформ, от FreeBSD и Linux до SmartOS. Целевая аудитория доклада: веб-разработчики, инженеры отделов эксплуатации. Ее примерный уровень: средний.

1. Сравнение современных средств управления
конфигурацией: Chef, Puppet, SaltStack, Ansible
Александр Чистяков, главный инженер
Git in Sky, 2014

2. Давайте познакомимся, я:
✔ Занимаюсь поддержкой инфраструктуры разных проектов, больших и
маленьких
✔ Живу на Северо-Западе
✔ Работаю главным инженером в компании Git in Sky
✔ Постоянно что-нибудь конфигурирую

3. Давайте познакомимся, вы:
✔ Занимаетесь разработкой веб-проектов?
✔ Занимаетесь поддержкой веб-проектов?
✔ Не занимаетесь? А чем занимаетесь?
✔ Готов поспорить, вы немного конфигурируете?
✔ Если нет, кто-то делает это за вас

4. How to configure like a pro!
✔ 70-е Сначала был UNIX shell (почему «был», он и сейчас есть)
✔ 90-е CFEngine 1, CFEngine 2 (ядро проекта - на языке C, кстати, кто-
нибудь здесь разрабатывает на языке C?)
✔ 00-е Puppet (на Ruby), Bcfg2 (на Python)
✔ 10-е Chef (Ruby), Salt (Python), Ansible (Python), Juju (Go),
Rundeck (Java), Babushka (Ruby), Marelle (Prolog)
✔ Как видите, выбор есть! (Наверняка, я перечислил не всё)

5. Мужской справочник по CM системам
✔ Задача: выбрать систему управления конфигурацией
✔ План действий (два варианта):

6. Меня зовут Саша, и у меня есть проблема
✔ Как решал эту задачу я:
✔
Начало 2011-го, Puppet и Chef уже есть, выбираю из них
✔
Не знаю ни Chef, ни Puppet, ни Ruby
✔
Но! Про Puppet есть книга!
✔
Книга — источник знаний?
✔
Книга — показатель «взрослости» проекта!
✔
http://goo.gl/MKe5Ni (опубликована Feb 4, 2008)

7. Назад в будущее
✔ Как бы я решал эту задачу сейчас?
✔
2014: Puppet, Chef, Salt, Ansible, Fabric, ...
✔
Про Chef есть книга...две книги...три книги
✔
Про Puppet есть три книги...или больше?
✔
(Packt Publishing — это круто!)
✔
O_O
✔
Нужно менять критерии отбора!

8. Придумываем критерии
✔ Порог вхождения (низкий, высокий, средний)
✔ Сложность развертывания (низкая, высокая, средняя)
✔ Язык ядра проекта (Ruby, Python, C, Java, Prolog, ...)
✔ Язык описания конфигурации (custom DSL, YAML, XML, eDSL, Ruby)
✔ Парадигма описания конфигурации (императивная, декларативная)
✔ Сложность поддерживания сервиса (низкая, высокая, средняя)
✔ Ресурсоемкость (низкая, высокая, средняя)
✔ Дружелюбность и компетентность сообщества
✔ Классификация получилась очень субъективная и не очень стройная
✔ Но другой у меня для вас нет (может, есть у вас для меня?)

9. Порог вхожения
✔ Сильно зависит от вашего пути:
✔
Я начинал с Puppet, и мне было сложно
✔
Через три года я вернулся - «так здесь же все понятно!»
✔
Я уже знал анатомию типичной CM системы
✔
Я знал, что именно мне необходимо (все CM системы похожи)
✔
Новая информация про Puppet в сети, новые книги, etc
✔ Тем не менее, у разных систем порог вхождения разный

10. Порог вхожения
✔ Про CFEngine тоже есть книга
✔
Я пытался читать ее, уже имея опыт с Puppet и Chef
✔
Сначала я сломался прямо на оглавлении
✔
Потом я не смог найти, как в CFEngine устроена генерация конфигов
при помощи шаблонов
✔
Так, до сих пор, и не знаю, возможно, никак не устроена
✔ Да, я не хочу читать никакие книги, я хочу описывать конфигурацию,
где мой «Getting started»?

11. «Getting started»
✔ Типичные действия:
✔
Развернуть и настроить сервер, пусть в минимальном варианте
(если сервер вообще предусмотрен)
✔
Настроить агент на клиентских машинах, связать их с сервером
✔
Начать описывать конфигурацию
✔
Протестировать описание
✔
Применить описание
✔ Казалось бы, пять простых пунктов!

12. Анатомия CM системы
✔ Сервер (если есть, обычно — есть)
✔ Агент на клиентских узлах (если есть, часто — есть)
✔ Описания конфигурации (хранятся на сервере, применяются на
клиенте), состоят из:
✔
Описаний установленных пакетов
✔
Описаний разрешенных и запущенных сервисов
✔
Шаблонов конфигурационных файлов и правил генерации
✔
Описаний параметров сред (логических групп серверов)

13. Все CM-системы похожи?
✔ С большого расстояния — да
✔ Если подойти поближе, то у них окажется
разный цвет и разная форма ушей
✔ Кроме того, у каждой будет уникальный характер
✔ Поговорим об уникальных отличиях

14. У каждой системы свой жаргон
✔ На мой взгляд это довольно глупая уникальность
✔ Но создателей CM систем тоже можно понять — они
втайне хотят, чтобы остался только один игрок
✔ Раньше я приводил в докладах словарики этого жаргона
но, говоря о четырех системах сразу, я не вижу смысла этого
делать
✔ Теперь о действительно уникальном

15. Chef: сделано рубистами для рубистов
✔ Chef-Librarian и Berkshelf — dependency managers
(то же, что Bundler (Ruby), Composer (PHP), Bower (Node), etc)
✔ Chef появился как SaaS, и в этом качестве он лучше всех
✔ Шифрование sensitive данных — функция ядра системы
(Для Puppet есть подпроект Hiera-Puppet и отдельный плагин
hiera-gpg для шифрования)
✔ foodcritic — lint tool
✔ test-kitchen — integration testing tool
✔ ChefSpec, Cucumber-chef, rspec-chef — unit testing tools

16. Puppet: сделано для RHEL
✔ В отличие от Chef, Puppet всегда таргетировался на
RHEL-based системы и нормально на них работал
✔ Полная поддержка команд Augeas
✔
Augeas — это API и tool для управления конфигурационными
файлами
✔
Сhef с Augeas не работает вообще, Salt поддерживает только
команду «set», для Ansible есть сторонний модуль

17. Выводы
✔ Знать одну CM систему лучше, чем ни одной
✔ Знать несколько CM систем лучше, чем одну
✔ План не изменился
✔ Но теперь у вас есть схема
магазина (я надеюсь)
✔ Кстати, моя торговая точка
здесь: http://gitinsky.com
✔ Заходите!

18. Спасибо за внимание!
✔ Пожалуйста, ваши вопросы!
✔ ...
✔ ...
✔ С вами был:
✔
Александр Чистяков, главный инженер, Git in Sky
✔
alex@gitinsky.com, http://gitinsky.com
✔
http://meetup.com/DevOps-40