Ansible vs. Puppet: лирическое отступление.

puppet-ffffuuuuAnsible считается наипростейшим способом автоматизировать IT инфраструктуру — это то, что написано на сайте производителя. Так это или не так, судить не берусь. Однако, имея небольшой опыт почти одновременного кавыряния в Puppet и Ansible, неавторитетно заявляю: Ansible действительно проще в освоении нежели Puppet.

Puppet’овая боротьба

Вначале своего пути автоматизационщика и будучи по натуре инженер-программистом я тут же начал искать в Puppet циклы, когда нашёл их в документации, потратил ещё N-ное время, чтобы понять, что в дефолтном репозитарии (remi или epel, сейчас уж не помню) пакет слишком старый, либо не старый, но циклы включаются магическим флажком с другими экспериментальными (???) фичами.. Ну да бох с ними с флажками и фичами, поставили флажок — тут же посыпались уже написанные одмином существующие манифесты.. В конце концов всё пофиксили, всё заработало. Через какое-то время обновили пакет из дефолтного репозитория до последней версии — циклы & Co пропали — магический флажок перестал работать — откатились обратно.. Из последнего: обновился пакет — в хэшах стал магически интерпретироваться ключ «type» — пришлось закавычить %)

Правда прикольно?

Вполне допускаю, что моё вхождение в Puppet было несколько сумбурным, я заплывал за буйки, трогал то, что нормальные люди не трогают, дёргался попусту, и из-за этого всё у меня сыпалось из рук, вылазили всякие сюрпризы неведомые бывалым дядькам, но, тем не менее, именно эта магия и иллюзия нестабильности продукта меня и добили, через три недели (пару потратил на боротьбу c мэджиками) обратил свой взор на Ansible.

И это я ещё ничего не сказал про кошмарные зависимости и невнятную документацию — тут допускаю, что документация внятная, а всё дело в чрезмерной сложности продукта. В финале я уже Hiera не осилил — слабак, осознаю. Тут уж мне помешало знание, что в Ansible оно есть из коробки.

Стало быть, обратил свой взор на Ansible (на самом деле куда смотреть подсказали матёрые чуваки из PCextreme). Как я уже сказал, Hiera (подход в описании конфигурации хостов и приложений в них и наоборот в Yaml-файлах отдельно от сценариев развёртывания) в ём была из коробки. А вот коварных Зависимостей не было.

Ansible технология для дебилов!

Таким образом, если вы дебил, не понимаете в программировании, достаточно неряшливы, чтоб следить там за какими-то зависимостями и какими-то говно-конструкциями сложнее, чем инструкция «сделать то-то» — Ansible ваш выбор! Максимально простой вход в технологию, максимально простая и целостная документация. Сиди себе как нанайский мальчик — что вижу, то и пою — и фигачьте инструкции одна за другой, и тут же их исполняйте на удалённых серверах — Ansible ходит по SSH, посему каких-то доп знаний, как в Puppet, для добавления ключей вам тоже не понадобится.

Тут нужно признать, что на Ansible можно и посложнее, чем списки элементарных инструкций. Можно инструкции и в композиции сложных объектов объединять.

Что вижу о том и пою

Раз пошла такая пьянка я ж даже shell’овские команды сразу в инструкции (tasks) к Ansible пишу и оттуда отлаживаю. Т.е., получается, пока с чем-то экспериментировал, тут же и задокументировал это в ямликах, да и в git закоммитил, а не так, что весь день изыски проводил, а в конце из bash history выкавыриваешь, что надо и что не надо. Удобно. Да и оттестировать сразу можно на нескольких разных серверах. Ляпота!

Школоте выдумывать с нуля новый язык — грех

Почему-то мне кажется, что решение выдумать новый язык программирования было основным фейлом команды Puppet. Всё ж таки поддерживать новый язык — это вам не хухры мухры. Да и реализовывать его на Ruby так себе идея, я щетаю (оценочное суждение). Пацаны с Ansible пошли путём максимального упрощения — простая последовательность инструкций — и победили.

Немного жаль времени потраченного мною на Puppet — потрачено оно было на то, чтобы убедиться, что Puppet слишком сложен для моего скудного понимания, и выискать несколько несоответствий между его документацией и реальным миром, в то время как трудозатраты на Ansible были в том числе инвестированы в освоение элементарных навыков программирования на православном Python (потребовался для реализации элементарного фильтра массива). Мелочь, а приятно. Да и Python более достойный язык дабы в него инвестировать нежели Puppet  🙂

Как-то так.

 

UPD

Ложка дёгтя 1

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

И вместо того, чтобы написать что-то типа:

приходится для каждого нового формата списка с аргументами (list_of_dicts) вытаскивать содержимое include и оборачивать каждую инструкцию в with_items.

Можно было бы передавать список нужного формата в vars. Но тогда возникает вопрос:

Как сконвертировать список с хэшами (dicts) одного формата в другой?

 

  • Max Treskin

    Руби-пидерсия не нужна

    • otokarev

      Воистину так! По мне так лучше уж православный PHP — привычнее 🙂 Питон тоже ништяк.

  • Aleksey Karelin

    Ansible действительно подкупает своей простотой и порядком выплнения тасков, в отличии dependency hell и декларативности puppet. Пожалуй лучшее решение развернуть разово определенный деплоймент как задумал. Но вся простота исчезает когда деплоймент нужно развренуть на > 50 и видеть четкую лаконичную картинку где прошло, где нет и что именно пошло не так. stdout ansible шлет увы слишком сырые данные.

    Проблема Dsl Puppet, пожалуй не в самом Dsl, а в идеологии и паттернах, «жестко рекомендуемых» создателями puppet. В сухом остатке имеем кучу модулей puppet на все случае жизнии, более менее следующих общей идеологии и остается только написать классы для профилей и классы ролей, компанующих профили. В Ansible увы пока каждый пишет как он хочет и вникнуть в кучу *.yml уже имеющихся у команды новому человеку будет гораздо сложнее, нежели в тоже самое, написанное на puppet.

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

    • otokarev

      Спасибо за комментарий, Алексей.

      Да, пожалуй, вы правильно сформулировали наш случай: разово развернуть деплоймент. Даже не весь, а часть — один/группу хостов с определённой ролью.

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

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

      ***

      > В Ansible увы пока каждый пишет как он хочет и вникнуть в кучу *.yml уже
      имеющихся у команды новому человеку будет гораздо сложнее, нежели в
      тоже самое, написанное на puppet.

      Эта проблема решаема достаточно просто у команды программистов — через жёсткое code-review. Однако ж, по моему, прежде чем пускать в плэйбуки новых программистов, желательно чтоб там уже была напрототипирована критическая масса «велосипедов». Чтоб копипастерам было откуда копипастить 🙂

      ***

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