Comments 23
С потрясающим интересом прочитал обзор, поскольку прямо сегодня с совещания мы думали о том, как нам «объединять» несколько плейбук из разных репозиториев. К сожалению, каждое из описанных решений слишком openshift/docker-centric (насколько я увидел), и вместо того, чтобы быть инструментом, каждый из них тащит в качестве полиси использование больших монстров…
Увы.
Увы.
Но создание своего решения, далеко не факт что приведет вас к счастью. Если не секрет к чему склоняетесь?
Пока что я после нескольких часов обсуждений придумал терминологию и описал проблему яснее. У ансибла нет абстракции выше playbook'и, а хочется. Мы их назвали facilities и будем вендорить. Каждая facility в своём каталоге. Инструментария не нашёл, увы. Вот неотвеченный вопрос на SO по этому поводу: stackoverflow.com/questions/54906261/integration-level-for-anisble-between-roles-and-playbooks
По-русски, плиз, тезка. Че-то слишком сложно объясняете. Ну, и можно всегда в телеграмме обсудить поднятый вопрос.
p.s. кстати, плюсанул на SO — не знаю, кто там минусанул, но среда там менее токсичная, чем здесь.
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 и там размазана логика по плэям.
Приведу пример. Пусть есть базовые роли
— install java
— install oracle
— install postgresql
— install wildfly
— install glassfish
Есть мета роль «install app 3.2.1.» установить наше приложение версии 3.2.1. поверх pg и установить такие-то пароли, она, условно инклюдает часть ролей передавая туда параметры при инклюде.
далее мета роль применяем на сервера и радуемся жизни. проблемы начинаются когда это надо множить на несколько серверов… это решается не очень удобно тем, что есть playbook установи приложение версии 1.2.3 и там размазана логика по плэям.
Есть готовый пример на гитхабе/гитлабе?
в паблике нет ничего что можно выложить. Сделал псевдо пример https://github.com/ultral/ansible-meta-roles-demo там есть роль ansible-dev можно на неё ориентироваться
Мета-роли, или роли-врапперы, это хорошо известная вещь. К сожалению, роль может работать только на тех хостах, куда её назначили, то есть роль не может определять список хостов, на которые надо выполнять задачи. И это проблема, если задача «меты» скоординировать несколько ролей на разных серверах.
да, именно про эту проблему и говорил в комментарии про плэйбуки, что логику по плэям размазываем.
А дальше проблема: а как переиспользовать чужие плейбуки в проекте? Нет механизма, нет терминологии (нам же надо не только плейбука, но и её роли, а может быть, и её files/templates).
Сейчас я думаю о том, как это вендорить. Терминологию уже придумали (facility) — но как именно её культурно вендорить надо думать.
Сейчас я думаю о том, как это вендорить. Терминологию уже придумали (facility) — но как именно её культурно вендорить надо думать.
Очень интересный доклад и статья тоже.
Жаль, что не рассмотрены альтернативные решения.
Используем gitlab-ci и хотим использовать openshift. И желательно не как кубернетес на дрожжах. А именно опеншифт. Вот и интересно послушать мнение бывалых.
Жаль, что не рассмотрены альтернативные решения.
Используем gitlab-ci и хотим использовать openshift. И желательно не как кубернетес на дрожжах. А именно опеншифт. Вот и интересно послушать мнение бывалых.
Жаль, что не рассмотрены альтернативные решения.
это какие? что упустил?
про сборку:
- Ansible bender — замена ansible container, форсится как замена ansible container
- source2image — грубо ci/cd из коробки из опешифта
про управление
- operator — мб доберусь
- Automation broker -мб доберусь
- kustomize — вмерджен в kubectl, не актуально
- helm — у нас опеншифт, извините
На тему шаблонизаторов для манифестов.
Давно и крепко подсел на envsubst из пакета gettext. Все что он делает — заменяет в входном файле переменные окружения на их значения. Очень удобно использовать в связках с современными CICD фреймворками, т. к. они экспортируют все необходимые переменные в окружение. Получается просто один пайп, например:
Единственное неудобство — этот пакет надо ставить дополнительно, т. к. в минимальных образах он отсутствует по умолчанию, хотя есть во всех репах дистров (apt, apk, yum).
Давно и крепко подсел на 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, например) и пр. интересные штуки Это бывает полезно для отладки.
Sign up to leave a comment.
Запускаем приложение в Openshift и сравниваем существующий инструментарий