Запускаем приложение в Openshift и сравниваем существующий инструментарий

[amarao]

С потрясающим интересом прочитал обзор, поскольку прямо сегодня с совещания мы думали о том, как нам «объединять» несколько плейбук из разных репозиториев. К сожалению, каждое из описанных решений слишком openshift/docker-centric (насколько я увидел), и вместо того, чтобы быть инструментом, каждый из них тащит в качестве полиси использование больших монстров…
Увы.

[ultral]

Но создание своего решения, далеко не факт что приведет вас к счастью. Если не секрет к чему склоняетесь?

[amarao]

Пока что я после нескольких часов обсуждений придумал терминологию и описал проблему яснее. У ансибла нет абстракции выше playbook'и, а хочется. Мы их назвали facilities и будем вендорить. Каждая facility в своём каталоге. Инструментария не нашёл, увы. Вот неотвеченный вопрос на SO по этому поводу: stackoverflow.com/questions/54906261/integration-level-for-anisble-between-roles-and-playbooks

[gecube]

По-русски, плиз, тезка. Че-то слишком сложно объясняете. Ну, и можно всегда в телеграмме обсудить поднятый вопрос.
p.s. кстати, плюсанул на SO — не знаю, кто там минусанул, но среда там менее токсичная, чем здесь.

[ultral]

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

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

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

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

[gecube]

Есть готовый пример на гитхабе/гитлабе?

[ultral]

в паблике нет ничего что можно выложить. Сделал псевдо пример https://github.com/ultral/ansible-meta-roles-demo там есть роль ansible-dev можно на неё ориентироваться

[amarao]

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

[ultral]

да, именно про эту проблему и говорил в комментарии про плэйбуки, что логику по плэям размазываем.

[amarao]

А дальше проблема: а как переиспользовать чужие плейбуки в проекте? Нет механизма, нет терминологии (нам же надо не только плейбука, но и её роли, а может быть, и её files/templates).

Сейчас я думаю о том, как это вендорить. Терминологию уже придумали (facility) — но как именно её культурно вендорить надо думать.

[ultral]

добавить новый слой вложености и генерировать плэйбуки на лету?

[amarao]

Самомодифицирующиеся playbook'и — отличный метод увеличить сложность и снизить вероятность отладки.

[ultral]

снизить вероятность удачной отладки? или снизить вероятность самого процесса отладки?

[amarao]

Я пострадал день, пострадал два. Моё текущее решение — git-vendor (гуглябельно). Не очень удобная структура получается, но всё-таки хоть что-то.

[gecube]

Очень интересный доклад и статья тоже.
Жаль, что не рассмотрены альтернативные решения.
Используем gitlab-ci и хотим использовать openshift. И желательно не как кубернетес на дрожжах. А именно опеншифт. Вот и интересно послушать мнение бывалых.

[ultral]

Жаль, что не рассмотрены альтернативные решения.
это какие? что упустил?

про сборку:

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

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

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

[mommys_little_hacker]

На тему шаблонизаторов для манифестов.

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

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

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

[gecube]

Может лучше jinja2 или gomplate? Минус в том, что их тоже нужно устанавливать дополнительно, а плюс в том, что они мощнее, чем envsubst.

[ultral]

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

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

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

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

[mommys_little_hacker]

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

[gecube]

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

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

[mommys_little_hacker]

Буду честен, у меня такого юз-кейса не было. А еще я знаю только bash :)

Но, возможно, вам имеет смысл подумать о написании полноценных helm чартов. ЕМНИП, они изначально задумывались для подобного.

[gecube]

Пока не будет HELM v3 — нет, увольте.