Ansible - заключение

В предыдущих статьях (1 2 3 4) я обзорно прошёлся по основным на мой взгляд моментам ansible. Конечно очень многое осталось "за кадром", но для составления мнения мне хватило. Настало время подвести итоги и показать что получилось в результате экспериментов. Впечатления от ansible остались неоднозначные. Очень много негатива, хотя есть и положительные моменты. Если честно, я ожидал большего.

Minecraft без demo

Решил я на днях поиграть в minecraft на Linux. Зарегистрировался на сайте, установил пакет, когда launcher попросил - ввёл данные свои регистрационные, все как положено. Игра заработала - наслаждаюсь, вот думаю разработчики java молодцы, обещали что "написано один раз, работает везде" и выполнили таки обещание, несмотря на то, что игра выкуплена Microsoft - на Linux проблем нет. Но проходит пара часов - а она денег просит, прям как вирус какой поганый, про какое-то буржуйское "demo" талдычит. Я их тарабарскому наречию не обучен, чувствую только что java опять гадит, ибо других вирусов на Linux не водится.

Ansible - встроенные возможности

В предыдущих сериях 1 2 3, были примеры того какие возможности в плане расширения предоставляет ansible, на примере работы с пакетами в archlinux. Сейчас я попробую решить пару - задач декларативными средствами ansible, принципиально не используя самописные плагины и вызов внешних скриптов напрямую. Заодно будет повод ознакомиться с тем, что собственно ansible предоставляет из коробки. Тем более, что они в playbook умудрились добавить поддержку циклов, условий, переменных и т.п. Интересно понять насколько удобно ими пользоваться.

Ansible - плагины

В предыдущей статье я показал как можно написать для ansible свой модуль, на примере установки пакетов из AUR. Это делает меня на один шаг ближе к цели - создать решение для максимально полного сохранения конфигурации своего домашнего компьютера, однако остаются нерешенные задачи. В частности хотелось бы список пакетов, которые нужно устанавливать - хранить в отдельном конфигурационном файле, а не прописывать их в playbook. Это позволит н-р в одном случае прочитать конфиг и вернуть из него только неустановленные пакеты, подав их на вход модуля yaourt, в другом случае - можно будет сравнить список явно установленных пакетов в системе и выдать те, которые ещё не прописаны в конфиге и т.д.

Ansible - модули

В предыдущей статье удалось заставить ansible работать со стандартными модулями, в частности устанавливать пакеты через менеджер pacman. Однако в archlinux одним pacman сыт не будешь, большинство "вкусных" пакетов находится в пользовательском репозитории пакетов AUR. А разработчики дистрибутива заняли принципиальную позицию, что никогда не будет официального способа ставить неофициальные пакеты, мол если уж решились - то качайте и ставьте самостоятельно. Сообщество выпустило несколько альтернативных менеджеров для работы с AUR, одним из самых популярных считается yaourt. Я это всё к тому, что из ansible просто необходимо уметь вызывать yaourt, а такого модуля у них нет. В принципе это даже хорошо, поскольку даёт повод немного глубже окунуться в ansible и написать такой модуль самостоятельно.

Ansible - введение

Есть такой класс инструментов, как системы управления конфигурациями. Они сейчас довольно многочисленны: chef, puppet, salt и другие. Отличия в них не принципиальные - одна проще в настройке, другая стабильнее и чуть больше умеет, но в целом выбрав одну из них, вы так или иначе сможете добиться поставленных целей. Я к сожалению не обладаю достаточной компетенцией, что бы их сравнивать, поскольку со всеми знаком только на уровне статей\документации. Лично для себя, что бы познакомиться с этим классом инструментов я выбрал ansible. Судя по отзывам он наиболее логичен, прост в освоении, активно развивается и написан на python. Последнее важно, т.к. я более или менее знаком с этим языком, в отличии от часто используемого для таких инструментов ruby.