LINUX.ORG.RU
ФорумAdmin

Декларативное управление конфирурацией (локалхоста)

 , , ,


0

1

Ищется инструмент для декларативного управления конфигурациями. Что-то для личного пользования, с минимальными порогом вхождения - применяться будет к двум локалхостам и одному vps, дирижировать сотнями серверов не предполагается.

Хочется описательно задавать желаемое состояние системы (пакеты, конфиги, сервисы и т.п), и потом иметь возможность быстро его воспроизвести, на этой или другой машине. Судя по страничке в Википедии, я ищу что-то похожее на NixOS, но в рамках более мейнстримных дистрибутивов.

Из нагугленного понравились ansible playbooks, но смущает, что декларативность там оставлена на совести автора плейбука - если по неумению начать писать императивно аналог обычного скрипта, ansible ругаться не станет.

Опыта в использовании подобных инструментов ноль, соответственно, не могу оценить, какой лучше подойдёт к задаче. Что посоветуете? Что нравится/используете?

★★★

Конечно 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 оно само пойдет.

alpha ★★★★★ ()

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

system-root ★★★★ ()
Ответ на: комментарий от system-root

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

stave ★★★★★ ()
Ответ на: комментарий от stave

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

Xwo ()

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

anonymous ()
Ответ на: комментарий от anonymous

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

anonymous ()

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

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

beastie ★★★★★ ()
Последнее исправление: beastie (всего исправлений: 1)
Ответ на: комментарий от Xwo

проблема инфраструктуры не в том, чтобы сделать так как тебе хочется, проблема в том чтобы понять 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 по состоянию трех-летней давности.

alpha ★★★★★ ()
Ответ на: комментарий от alpha

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

anonymous ()
Ответ на: комментарий от Xwo

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

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

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

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

alpha ★★★★★ ()
Ответ на: комментарий от alpha

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

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

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

Xwo ()
Последнее исправление: Xwo (всего исправлений: 1)
Ответ на: комментарий от Xwo

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

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

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

alpha ★★★★★ ()
Последнее исправление: alpha (всего исправлений: 2)
Ответ на: комментарий от system-root

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

DALDON ★★★★★ ()
Ответ на: комментарий от alpha

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

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

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

anonymous ()
Ответ на: Глобальный, надёжный от anonymous

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

alpha ★★★★★ ()
Последнее исправление: alpha (всего исправлений: 2)
Ответ на: комментарий от alpha

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

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

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

anonymous ()
Ответ на: комментарий от anonymous

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

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

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

alpha ★★★★★ ()
Ответ на: комментарий от anonymous

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

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

mos ★★☆☆☆ ()
Ответ на: комментарий от Xwo

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

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

pod ★★ ()
Ответ на: комментарий от anonymous

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

pod ★★ ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.