среда, 29 июля 2015 г.

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

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

Для начала, хочется отметить, что перенос текущей конфигурации машины в ansible сделать получилось, c недоработами, вынесено туда хорошо если процентов 70 от всех настроек, но все же работает и уже приносит пользу при синхронизации машин. Текущий вариант можно посмотреть тут, если кому-то станет любопытно.

А теперь к впечатлениям от ansible:
Простота. Этого не отнять, доступная документация, понятная логика работы, простые исходные коды. Пока идёшь в той канве, которую проложили разработчики - проблем никаких нет, все легко, понятно и просто. Даже если отклоняешься - по крайней мере ясно куда положить самописный модуль или плагин. Высокая популярность ведёт к тому, что интернет наводнён разного рода статьями и советами, в том числе и на русском языке. Если задача популярна, то скорее всего кто-то уже подробно описал её решение или посоветовал обходной путь.

Негатив вызывает, в основном, их язык описания на yaml для playbook. С одной стороны идея понятна - хотелось сделать простой, понятный, универсальный декларативный независимый от реализации язык. За этим фасадом потом можно легко менять внутренности не ломая интерфейс, можно например даже сменить язык реализации. Но вышло ужасно. То что на чистом python реализуется в пару строк, обычным циклом, тут превращается в модуль на 200-300 строк, плюс столько же документации, а ещё парой десятков issue на GitHub от пользователей, которые хотели чуточку отойти от линии партии. И ладно бы это работало, но нет, любая хоть немного нетривиальная ситуация после пары часов в google, с большой вероятностью в итоге выливается в собственный плагин.

Как решение ситуации - я бы предложил в качестве языка playbook использовать python. Возможно стоило бы ввести ограничения, например запретить импортировать все кроме стандартных библиотек. Благо язык позволяет выделывать с ним разные фокусы. А вместо написания плагинов замещающих стандартные циклы и условия - сосредоточиться на написании полезных, многофункциональных и кроссплатформенных библиотек по работе с системой.

Универсальность готовых модулей - так же далека от совершенства. Ну вот как можно объяснить, почему, например, при замене какого-то объекта на ссылку, модуль file вполне способен удалить директорию по пути куда должна указывать ссылка, но вот если эта директория не пустая, то он падает с ошибкой? Или почему настолько урезана возможность работы с шифрованными файлами напрямую из playbook? И есть масса других примеров, когда очень востребованная функциональность отсутствует. Складывается впечатление, что те модули, что там есть - не продуманная стандартная библиотека, а набор решений частных проблем, которые возникали у разработчиков.

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

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

Все плохо, пишем своё? Скорее нет, на горизонте вторая версия, где похоже многое исправят. Продукт активно развивается, появляются новые полезные модули. Даже если использовать процентов 50 встроенного функционала, а остальную половину реализовывать в личных плагинах, то и в этом случае ansible стоит того, что бы им пользоваться, по крайней мере в сравнении с полностью самописным решением. Думаю нелишним будет - взглянуть на конкурентов, хотя бы с точки зрения расширения кругозора.

Комментариев нет:

Отправить комментарий