Пока этот вариант оставляем на план Б, но в нем все равно много копипасты.

https://github.com/lyraproj/hiera ?)

https://github.com/lyraproj/hiera ?)

https://docs.ansible.com/ansible/latest/plugins/lookup/hiera.html а окей

в чем копипаста?

Я пока вижу это в таком духе: inventories/dev/group_vars/nginx.yml inventories/test/group_vars/nginx.yml И там и там будут переменные с одинаковыми именами: 1. Легко перепутать 2. Легко ошибиться В случае с отдельными репозиториями переменная в плейбуке одна и шанс ошибиться стремится к 0.

а зачем трогать group_vars?

так среды одинаковые или нет? ну тогда информации мало

вообще переменные могут и в инвентаре лежать, но я больше так не делаю по личным причинам

Парни, что не так с моей ролью: Задача скопировать файлы с локалхост на удаленный. Вопрос, как передать модулю synchronize, destination host параметр? Вот такая конструкция, не работает: - block: - name: Transfer replicationn DB from Ansible host to primary cluster synchronize: mode: push src: /tmp/backup/{{ replication_db_name.stdout }} dest: "{{ groups['new-standby_host-1'][0] }}/tmp/" rsync_opts: - "--chmod=F644" delegate_to: localhost

Парни, что не так с моей ролью: Задача скопировать файлы с локалхост на удаленный. Вопрос, как передать модулю synchronize, destination host параметр? Вот такая конструкция, не работает: - block: - name: Transfer replicationn DB from Ansible host to primary cluster synchronize: mode: push src: /tmp/backup/{{ replication_db_name.stdout }} dest: "{{ groups['new-standby_host-1'][0] }}/tmp/" rsync_opts: - "--chmod=F644" delegate_to: localhost

Всем привет! Есть роль. В ней в папке tasks есть несколько yml файлов. К примеру 1.yml 2.yml. В них tasks lists. В main.yml используется include чтобы их "подключать". Некоторые подключаются по условию ( к примеру 2.yml) . Когда условие неверно определенный таск лист пропускается. Подскажите, пожалуйста, есть ли возможность сделать так чтобы в выводе плейбука, который вызывает роль я видел только одну запись - 2.yml skipping. А не список всех тасков из 2.yml со статусом "skipping" ?

Делай import_tasks вместо include

не помогло (

А include_tasks?

Это - да. Спасибо! А что вообще лучше использовать в таком случае как у меня - Подключение yml файла в роли по определленому условию. Я понимаю историю dynamic vs static. Но,как мне кажется, здесь - в таком случае без разницы ( когда просто подлючается дополнительный функционал к роли). Правильно ли мне кажется?)

Лучше include_tasks. Мы обычно именно такой вариант используем. import_tasks более простой, он чисто для разбивки одного файла на несколько

Добрый вечер! Предлагаю обсудить кейс: много окружений, плейбуки одинаковые, инвентарь разный. Необходимо убрать копипасту плейбуков и заполнение кучи переменных. Родилась идея хранить базовую версию плейбука в одном репозитории, а в других наследоваться и при необходимости менять переменные, благо group_vars могут быть определены в playbooks(приоритет выше) директории и в inventory. Таким образом можно перетирать" defaults" плейбука. Кажется кейс очевидным и должен решаться многими. Однако сходу подтягивание плейбуков из репозитория аналогично как реализовано для ролей ansible-galaxy не нашел. Вариант держать различный инвентарь в одном репозитори нам не подходит, так как могут быть сторонние взаимодействия клиентов с плейбуками.

Опоздал немного, но может пригодится. Кейс такой же, судя по описанию, я решил складыванием настроек в консул, и кастомным варс плагином, который все подтягивает автоматом при запуске плейбука. Структура конфигов в консуле хранится в виде KV дерева, в корне которого есть дефолты для всего вообще в ветке common, дефолты для конкретного сервиса в ветках по имени сервиса, и дальше настройки конкретных проектов в ветках названых по имени проекта, которое передается в инвентаре. Внутри ветки проекта так же есть common ну и ветки по сервисам. Все это вытягивает варс плагин, и мержит в хостварс. Механизм показал себя очень гибким. Инвентари или статика, или тоже на лету генерятся из терраформ стейта. В инвентаре приезжают только имена/адреса хостов и принадлежности к группам. Ну и изредка какие то ещё параметры, например роль в консул кластере. Плейбуки и роли абсолютно статичные.

А пример кода есть?

Кстати был бы благодарен за ревью именно в плане правильности работы с хостварс, ибо не уверен что все оптимально.

Комплектный плагин умеет работать с конкретными ключами, насколько я помню, работать с деревом у меня не получилось. Ну и мержить дефолты с проектными настройками он не может точно.

у меня пожалуй сейчас не совсем то что можно назвать бест практис хоть и решает свои задачи, сейчас есть копия всей инфры в виде docker-compose - всякие штуки типа интеграционных тестов, отдельных сред, дев - все там, те есть какой-то гемор конечно в синхронизации, но в целом все связано с gitlab и переменные в нем лежат. При текущем размере основной инфры в пару десятков физических хостов с гипервизорами и всего несколько сотен виртуалок и контейнеров реально от тестов с помощью молекулы и подобного проблем оказалось больше чем реального профита. Тут можно много дискутировать, но ситуация такая что воспроизводить для разработки прод на 100% это в первую очередь геморой для разработчиков и тех кто тестирует непосредственно ПО, а когда сервис в прод уходит считай что его уже СРЕ в поддержку забирают и там все равно свои нюансы вылезают. Т.е сейчас я пришел к тому что фактически разработчикам и тестировщикам предоставляется фактически готовый сервис под капотом у которого докер композ в котором они максимум меняют несколько переменных. Это сейчас довольно хорошо себя показывает уже длительное время, Был так же проект где использовали абсолютно одинаковые роли и плейбуки, но с разными инвентарями - все переменные которые надо было переопределить выносились в инвентарь и для групп и для хостов. И это работало для сотен хостов и тысяч контейнеров, но там например не было вообще каких либо нюансов по типу сложных правил файрволла, балансировки и прочего что есть сейчас. Вообще такие "проблемы" вполне себе k8s решает(принося другие ггг). но тут опять же надо очень хорошо понимает размеры инфраструктуры, кто и как ее обслуживает, струткуру команд и как вообще работа построена, слишком много везде специфики и нюансов. Если хранить все переменные для сред в отедлном сервисе типа консула(и фактически от групварсом отказаться либо оставить там то что не требует переоределения) то инвентарь можно при запуске генерить и тогда реально нужна будет 1 репа с одним набором ролей и плейбуков, но от того что нужно следить за переменными все равно никуда не уйти

Кода варс плагина? Могу завтра скинуть, сейчас под руками нет.

Под капотом консул темплейт?

чистый питон, дергает жсон из консула по апи.

да код плейбука вообще не важен. причем тут роль я тоже не очень понял. тут речь про вынос статических настроек из инвентаря во внешнее хранилище. сильно утрированный пример кейса: есть набор площадок: условно дев, стейдж, прод. они расположены физически на разных хостингах. на каждом хостинге разное железо, и иногда операционки. например нам надо развернуть на виртуалках кластер постгреса, но на каждом хостинге будут различные имена устройств. мы определяем в консуле следующее дерево настроек: common: db_device: sdb dev: db_device: xvd prod: db_device: sdc варс плагин это дело засосет из консула при запуске плейбука, и в хостварс/групварс попадут корректные настройки для конкретного окружения/сервиса.

Не очень понятно, что мешает все эти данные хранить в инвентаре

Не очень понятно, что мешает все эти данные хранить в инвентаре

Не очень понятно, что мешает все эти данные хранить в инвентаре

дефолты нужно дублировать в каждом инвентаре

дефолты нужно дублировать в каждом инвентаре

Группы могут быть разнесены по любым файлам

нужно, потому что такие окружения есть у кучи проектов

каждый проект со своими инвентарями - это репа. поменяли дефолты для условного постгреса - надо обновить кучу реп

кроме того окей, установил я дефолты в роль. где хранить настройки окружений для динамических инвентарей?

я не упарываюсь в свои костыли, просто это удобно. :)

дополнительный бонус, что все в одном месте лежит. легко сверить настройки, легко поменять настройки. не нужно по репам все это проверять/коммитить. еще б редактор удобный запилить, когда нить руки дойдут. :D

опять #компост ? ты как избегаешь проблемы с ним или реально очень ограничили набор используемых фич?

в последний год-полтора проблем особо не ловил, обычно проблемы если и есть то это если вдруг кто-то протащил свой контейнер кривой или запустил софт внутри криво. Ну типа из серии иногда есть необходмиость переопределить команду для запуска или выполнить предварительно что-то еще, ну и например энтрипоинт переопределили как bash,а не sh и некоторые приложухи начинают себя странно вести, но это было два раза за год. А в самом композе самая "cложная" фича это разве что scale. Проблемы может возникаю у тех кто хочет фич сворма, но без сворма, но это дичь.