Я уже делаю не первый заход на ansible. И вроде не первый playbook написал. Но каждый раз у меня какое-то двоякое ощущение. Вроде бы поставленную задачу инструмент решает, но в процессе Я выкручиваю себе руки. Возможно Я неправильно его готовлю, или возможно это инструмент только для администраторов.

Но, те же задачи решенные с помощью fabric, показывают что можно и без боли все автоматизировать.

Ansible

Ansible набрал популярность благодаря простоте, по сравнению с Chef, Puppet и SaltStack. Никакого ruby в Chef/Puppet, никакой асинхроншины в Salt, никаких агентов. Только декларативный YAML и только доступ по SSH.

Я не пробовал Chef и Puppet, но после Salt Ansible воспринимается как глоток свежего воздуха, особенно вторая версия.

Но первое впечатление обманчиво. Достаточно почитать Content Organization, Variable Precedence, Ansible Galaxy и Playbook Debugger что бы понять что инструмент совсем не простой. У него есть разухабистая структура, 2 десятка приоритетов загрузки переменных, и система управления зависимостями, и даже отладчик!

А YAML только на картинках прикольный. А в реальности вы можете убить кучу времени, пытаясь понять почему playbook или не запускается или работает не так. Потому что вы где-то поставили не тот символ, или ошиблись отступом.

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

Ansible это система управления конфигурациями (Далее SCM). А если верить wikipedia, то это инструмент должен нам ответь как минимум на один очень важный вопрос - Кто-то уже сделал нечто, как нам это воспроизвести?

Прежде чем перейти дальше давайте попытаемся разобраться с терминами. К сожалению дать четкое определение "конфигурации" нельзя. Конфигурация может быть как набором виртуальных машин, так и набором файлов настроек, и даже набором конкретных версий приложений. Но вот незадача, уведомление на почту - это SCM? А запуск скрипта в Jenkins - это SCM? А deploy артефакта в wildfly - это SCM? А Ansible все это умеет, и еще многое другое.

Нам ной взгляд, конфигурация - это некоторый элемент системы, которые имеет состояния и атрибуты.

Простейший пример - файл. Мы делаем stat что бы получить текущее состояние файла. Потом командами touch,rm меняем его состояние и командами vim,chown,chmod меняем атрибуты.

Правда под такое определение не подходят многие модули Ansible. Например для уведомления, мы не можем узнать были ли они отправлены при повторном запуске системы, и уж тем более не можем откатить их у получателей.

Как видно Ansible это больше чем SCM. И вот тут мы натыкаемся на первую проблему. Какой контекст использования данного инструмента? Где его ограничения? Официальный сайте утверждает что он поможет вам решить любые задачи. Что естественно не может быть правдой.

Программирование

У Ansible декларативный язык разметки. Но, как только вы выходите за рамки поставить пакет и скопировать файл, вы начинаете осознавать что у вас появляются циклы, условия, обработка ошибок, переиспользование кода. И вы мало по малу начинаете понимать что вы занимаетесь не чем иным как программированием. Только у вас в руках не удобные python/ruby. С десятилетиями наработок. А наколенное решение.

А дальше еще веселее. Вы упираетесь в модули обертки, например для docker-compose не проброшены какие-то команды или параметры. И вам приходится спускаться до обычного вызова shell команд.

И вот вы сидите, по локоть в "xml программировании", которое дергает обычный shell. И у вас возникает вопрос - а на кой черт все это?!

Вы конечно можете написать свой модуль. И я даже пробовал. Это то еще удовольствие. Внутрений API весьма скудный и до боли процедурный. Отладка отвратительная.

Переиспользование

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

Нам не нужно переиспользование. Нам нужна автоматизация. Переиспользование подразумевает что у всех все одинаковое. А это не так. У кого-то debian, у кого-то centos. Кто-то использует LTS пакеты, кто-то самые свежие. Кто-то тюнит приложения, кому-то хватает стандартных настроек. И т.д. Тут не то что из Galaxy брать роли, тут не факт что из команды рядом получиться что-то переиспользовать.

Docker

Основной враг Ansible это Docker и системы типа Kubernetes. Несмотря на совершенно разное предназначение, они вытесняют все SCM. Просто потому что не надо учить какой-то новый язык, можно просто написать Dockerfile на bash. Не надо думать об идемпотентности. Не надо думать об удалении старых конфигураций. Не надо ломать голову об установке двух и более java/python/ruby на одну систему.

Контейнеры сильно упростили жизнь. А установку и управлении взяли на себя Kubernetes/Mesos. Место для SCM осталось совсем немного. Установить базовые пакеты на систему, разложить конфиги/ключи. И то не факт, потому что это все можно и bash скриптом сделать.

Вывод

Я не буду утверждать что Ansible ужасен и его не стоит применять. Я думаю многие системные администраторы вполне успешно его использую, и довольны результатом. Но ставить его как "must have" инструмент я бы не стал. Стоит ли его попробовать? Думаю стоит, полезно посмотреть идею идемпотентности. Но с точки зрения удобства и простоты - Docker предпочтительнее.

Постскриптум

Я уже давно пользуюсь Fabric. Этот инструмент не навязывает сложных парадигм, а сам базируется на языке python. Мне он не раз помогал, и я всегда мог решить с ним поставленные задачи.

К сожалению у него нет такой богатой библиотеки как в Ansible. Вам придется написать для себя все руками. У него не идеальный API, однако можно попробовать alpha 2ой версии, где решены многие проблемы.

Fabric Я бы рекомендовал программистам, что бы не писать на унылом bash. На нем хорошо решаются мелкие задачи автоматизации. Или же наоборот, сложные и специфичные.