Конечно ansible.

Есть конечно умельцы которые на нем пишут playbook в виде:

- name: run script
  shell: |
   ...
   простыня на bash на четыре экрана,
   включая ssh на внешние сервера
   ..

Потом эти умельцы приходят на Docker Meetup и рассказывают всем как они это сделали.

Но это, во-первых, неизбежное зло. Во-вторых, это отчасти и снижает порог вхождения.

То есть поначалу (первые полчаса) вполне нормально использовать ansible как аннотированный bash-скрипт. Только не одной сплошной простыней, а по порядку:

- name: Install packages
  shell: apt-get install nginx

- name: Start nginx
  shell: service start nginx

(Это уже огромный шаг вперед для любого админа)

Когда через полчаса этого покажется мало, и ты откроешь http://docs.ansible.com/ansible/latest/list_of_all_modules.html оно само пойдет.

мне в ansible всего одна вещь не нравится — всё писать самому надо.
потому что вся эта дичь на гитхабе, вроде 400 ролей на установку одного пакета, бесит. пока в таком разберёшься, проще самому написать и за 200 ролей управится.

Поддерживаю. С другой стороны много ли настраивать надо. И не надо ломать мозг настройкой шефа или паппета.

Мне не нравится концепция плейхуков. Мне нравится fabric, где сделаны примитивы, которыми я могу манипулировать, как мне хочется.

Мне иногда кажется, что NixOS слишком хорош для этого мира. Люди настолько привыкли к говносовту, что при виде NixOS их накрывает когнитивный диссонанс. Типичная реакция: «Эээ... а нет ли чего-то типа NixOS, только покривее и поглючнее?»

«Эээ... а нет ли чего-то типа NixOS, только покривее и поглючнее?»

Куда уж кривее, лол.

Вызсказался - и аж потеплело, да?

dpkg --get-selection / --set-selection и самые главные конфиги в git.

Всё остальное — жуткий overkill.

проблема инфраструктуры не в том, чтобы сделать так как тебе хочется, проблема в том чтобы понять 1) чего тебе хочется, 2) как выстроить много маленьких хотелок в более менее стройную систему, чтобы потом не было мучительно больно.

Поэтому инструменты, которые «делают всё что угодно как ты скажешь», всё равно что инструменты, которые не делают ничего.

См. http://www.commitstrip.com/wp-content/uploads/2016/08/Strip-Les-specs-cest-du...

С fabric ты до концепции group_vars, host_vars, role_vars и их взаимосвязей будешь эволюционировать года-полтора. Потом будешь изобретать роли и плейбуки, потом check и debug-mode, потом тесты и molecule... и потом получится ansible по состоянию трех-летней давности.

group_vars, host_vars, role_vars там есть изначально. В любом случае хоть в ansible, хоть в fabric писать код надо.

А ещё года через три дорастёшь до NixOS, выкинешь ansible фпеч, и всё у тебя будет хорошо.

Нет, в ansible не нужно писать код, в нем нужно писать yaml.

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

В любом случае хоть в ansible, хоть в fabric писать код надо.

Так может сразу subprocess, если для тебя разницы нет.

Нет, в ansible не нужно писать код, в нем нужно писать yaml.

Да лаааадно) Плейхуки не охватывают всего и вся.

Хотя в целом, ты прав. Но пока получается на fabric - буду на fabric. Будет тесно - перееду в ansible.

playbook - это последовательность тасков. Он охватывает всё и вся, потому что всё что ни делается в принципе - это последовательность тасков.

Таски - это мелкие шаги, которые реализуются модулями.

Вот модули не охватывают всего - это конечно так. Но, во-первых, они охватывают столько, что тебе хватит, во-вторых, есть универсальные fallback-модули shell(выполняющий произвольную команду) и uri(работающий с любым REST API), в третьих, в действительно экзотичных случаях, модули действительно можно писать. Но не с нуля в чистом поле.

Удваиваю. По сему, как правило смотрю как это реализовано в тех или иных ролях и делаю сам одну роль свою. Ставить 100500 ролей утомительно...

Глобальный, надёжный

Нет, в ansible не нужно писать код, в нем нужно писать yaml.

Вот и пацаны так думали, когда писали ansible. Потом обнаружилось, что в релаьной жизни нужна подстановка переменных, условия, циклы... Да фигня, прихреначим к ямлу текстовый шаблонизатор! Ой, че-то всрато вышло. Ну тада ещё прикрутим волшебные ключи типа when и with_items. Энтерпрайз-левел, чо сказать. Типикал редхат юзер хавает и просит ещё.

Пойди посмотри на salt и страдания программистов на jinja2. Как вернешься, поймешь что with_items и include/import_tasks - это лучшее что случилось в мире configuration management за последние три года.

Так jinja2 из ансибла никуда не делась, лол.

поймешь что with_items и include/import_tasks - это лучшее что случилось в мире configuration management за последние три года.

Почему мне стыдно это читать? Ты за пределы редхат-болота вообще выглядываешь?

Так jinja2 из ансибла никуда не делась, лол.

Ты не понимаешь что такое «программирование на jinja».

В Ansible jinja используется для форматирования текста, а не для программирования execution flow.

анон тралит альфу, ня

Так его, Капитан! (с)

Долгое время пользовался фабриком. И одна из основным проблем в нём - он не имеет средств, которые позволяют не применять твои задачи, если они уже усмешно применились. Приходилось вокруг него писать кучу врапперов.

Почти всё модули ansible из коробки умеют не применять повторно то, что не нужно. То есть ты описываешь состояние хоста, а не просто поэтапный набор действий.

Не очень понятны отсылки к редхату, ansible сформировался в том виде, в каком он есть, задолго до покупки редхатом.