Pull to refresh

Comments 23

С потрясающим интересом прочитал обзор, поскольку прямо сегодня с совещания мы думали о том, как нам «объединять» несколько плейбук из разных репозиториев. К сожалению, каждое из описанных решений слишком openshift/docker-centric (насколько я увидел), и вместо того, чтобы быть инструментом, каждый из них тащит в качестве полиси использование больших монстров…
Увы.
Но создание своего решения, далеко не факт что приведет вас к счастью. Если не секрет к чему склоняетесь?
Пока что я после нескольких часов обсуждений придумал терминологию и описал проблему яснее. У ансибла нет абстракции выше playbook'и, а хочется. Мы их назвали facilities и будем вендорить. Каждая facility в своём каталоге. Инструментария не нашёл, увы. Вот неотвеченный вопрос на SO по этому поводу: stackoverflow.com/questions/54906261/integration-level-for-anisble-between-roles-and-playbooks
По-русски, плиз, тезка. Че-то слишком сложно объясняете. Ну, и можно всегда в телеграмме обсудить поднятый вопрос.
p.s. кстати, плюсанул на SO — не знаю, кто там минусанул, но среда там менее токсичная, чем здесь.
мы для этого используем «мета роли». Это специальный вид ролей, который инклюдает другие роли с параметрами. Мы в них собираем конфигурацию из кирпичиков.

Приведу пример. Пусть есть базовые роли
— install java
— install oracle
— install postgresql
— install wildfly
— install glassfish

Есть мета роль «install app 3.2.1.» установить наше приложение версии 3.2.1. поверх pg и установить такие-то пароли, она, условно инклюдает часть ролей передавая туда параметры при инклюде.

далее мета роль применяем на сервера и радуемся жизни. проблемы начинаются когда это надо множить на несколько серверов… это решается не очень удобно тем, что есть playbook установи приложение версии 1.2.3 и там размазана логика по плэям.

Мета-роли, или роли-врапперы, это хорошо известная вещь. К сожалению, роль может работать только на тех хостах, куда её назначили, то есть роль не может определять список хостов, на которые надо выполнять задачи. И это проблема, если задача «меты» скоординировать несколько ролей на разных серверах.
да, именно про эту проблему и говорил в комментарии про плэйбуки, что логику по плэям размазываем.
А дальше проблема: а как переиспользовать чужие плейбуки в проекте? Нет механизма, нет терминологии (нам же надо не только плейбука, но и её роли, а может быть, и её files/templates).

Сейчас я думаю о том, как это вендорить. Терминологию уже придумали (facility) — но как именно её культурно вендорить надо думать.
добавить новый слой вложености и генерировать плэйбуки на лету?
Самомодифицирующиеся playbook'и — отличный метод увеличить сложность и снизить вероятность отладки.
снизить вероятность удачной отладки? или снизить вероятность самого процесса отладки?
Я пострадал день, пострадал два. Моё текущее решение — git-vendor (гуглябельно). Не очень удобная структура получается, но всё-таки хоть что-то.
Очень интересный доклад и статья тоже.
Жаль, что не рассмотрены альтернативные решения.
Используем gitlab-ci и хотим использовать openshift. И желательно не как кубернетес на дрожжах. А именно опеншифт. Вот и интересно послушать мнение бывалых.
Жаль, что не рассмотрены альтернативные решения.
это какие? что упустил?

про сборку:


  • Ansible bender — замена ansible container, форсится как замена ansible container
  • source2image — грубо ci/cd из коробки из опешифта

про управление


  • operator — мб доберусь
  • Automation broker -мб доберусь
  • kustomize — вмерджен в kubectl, не актуально
  • helm — у нас опеншифт, извините
На тему шаблонизаторов для манифестов.

Давно и крепко подсел на envsubst из пакета gettext. Все что он делает — заменяет в входном файле переменные окружения на их значения. Очень удобно использовать в связках с современными CICD фреймворками, т. к. они экспортируют все необходимые переменные в окружение. Получается просто один пайп, например:

cat manifest-template.yml | envsubst | kubectl apply -f -


Единственное неудобство — этот пакет надо ставить дополнительно, т. к. в минимальных образах он отсутствует по умолчанию, хотя есть во всех репах дистров (apt, apk, yum).
Может лучше jinja2 или gomplate? Минус в том, что их тоже нужно устанавливать дополнительно, а плюс в том, что они мощнее, чем envsubst.

в моем обзоре это "Scripts and template". с этим жить можно но попахивает велосипедами. без понятно на то необходимости, не стал бы тащить.


Зачем может такое понадобиться? ну предположим


  • мы хотим использовать мощь ООП, описать нашу инфраструктуру и потом перенести в реальный мир… ну ок… как потом поддерживать это не понятно… могут же и узнать домашний адрес после увольнения вашего. ^_^
  • более реальный случай, у нас есть некая СМДБ, с которой мы выгружаем нашу инфру(описание стэндов каких-нибудь?), генерим шаблон и катим…

можно. но зачем?

Они безусловно мощнее, но у них и порог вхождения выше. Также, у них больше зависимостей. К тому же, мне сложно представить, зачем в манифесте нужна настолько сложная логика. Плюс envsubst в том, что он очевиден и понятен всем. Для 99% процентов случаев (подставить тег докер-образа, или какие-то данные разнящиеся на продовых и тестовых контурах) его возможностей достаточно.

Мне удобно, что


  • указанные шаблонизаторы позволяют выделять повторяющиеся блоки кода (так себе аргумент, но YAML anchor не очень удобны, все-таки jinja понятнее)
  • позволяют грузить переменные не только из env, но с stdin, другого файла (json, например) и пр. интересные штуки Это бывает полезно для отладки.
Буду честен, у меня такого юз-кейса не было. А еще я знаю только bash :)

Но, возможно, вам имеет смысл подумать о написании полноценных helm чартов. ЕМНИП, они изначально задумывались для подобного.
Only those users with full accounts are able to leave comments. Log in, please.