я про значения переменных через varname=1

Рекомендуют делать всё ямллайк

Нужен. Сейчас мне приходится пилить такую конструкцию зачастую: - name: Generate {{ daemon }} template: .. - name: Reload systemd systemd: .. Помоему это проще: - name: Generate {{ daemon }} template: .. handler: restart_systemd {{ daemon}}

Ну так раскатка миллиона юнитов не частое дело.

Юнит как и юзер и директории в пакете должен быть

Огромнейшее "спасибо" за то что на блок нельзя повесить loop - 2-3 шага выкидывать в отдельную таску изза позиции разрабов "Мы считаем что этого делать не нужно" просто идиотизм

Юнит как и юзер и директории в пакете должен быть

В каком пакете? Аля собирать рпм каждый раз под такую задачу?

В каком пакете? Аля собирать рпм каждый раз под такую задачу?

А юниты часто меняются?

у тебя код поменялся продукта собирай рпмку.

Я при раскатывании сервера не генерирую только 1 вещь - скопировать скрипты из гита. Все остальное - запихать в systemd, добавить на мониторинг, запустить/перезапустить у меня сделано шаблонами, генерацией и тд

И слышать что ансибл не для этого очень странно - а для чего он тогда нужен?

Ансибл для этого но и использовать его нужно так как он задумывался

Никаких шаблонов - херачим портянки аналогичные башу?

ну так класть миллион юнитов в одной роли это странный путь.

педалить киллометровые лупы тоже так себе затея. Это как регекспы на пол экрана

А у меня микросервис - не слышали о таком? Когда программа состоит из нескольних независимых модулей. И с точки зрения интеграции в systemd они отличаются только именем запускаемого скрипта

Ты для проверки нехернюлиясделал давай другим свои роли почитать. Если человек с ходу не понял как оно работает значит чтото не так

Ну так не крути микросервисы на одной ноде

Это как бы не путь микросервисов

и если всё таки очень надо собирай рпмки или дебки а ансиблом их ставь.

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

Тогда пакеты. у всех сейчас есть плагины для сборки. Собираются если спеки не кривые быстро

Получаем версионирование из коробки и быстрый откат

Или докер

Ну докер это отдельная инфраструктура к которой надо прийти

Получаем версионирование из коробки и быстрый откат

У нас для этого есть гит и тестовый стенд.

вот только нативные средства системы ничего про твой гит не знают.

а на чём у тебя микросервисы?

Руби

Это как бы не путь микросервисов

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

вот только нативные средства системы ничего про твой гит не знают.

А в чем смысл ансибла тогда? Подключить репы и накатить пакеты тогда можно простым баш скриптом

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

из контекста не вырывай. много микросервисов на одной ноде. Не путь микросервисов.

А в чем смысл ансибла тогда? Подключить репы и накатить пакеты тогда можно простым баш скриптом

Если тебе нужно только это то да. Можно и так.

но как правило нужно ещё конфиги положить чтото в системе поднастроить. И тд

из контекста не вырывай. много микросервисов на одной ноде. Не путь микросервисов.

Еще раз повторяю - каждый микросервис на ноде - интерфейс для своей задачи.

Нода упала нет твоих микросервисов

целой пачки

Горизонтальное масштабирование - не не слышали?

деградация сервиса - не не слышали?

Резервирование там. Распределенные системы?

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

И не важно работает прод при этом или нет.

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

Для микросервисов специально кубернетис придумали

Который решает все выше тобой заданные вопросы.

Вы даже не можете понять что у меня интерфейс от основной логики отделен за счет микросервисности

А пытаетесь рассказывать что я делаю все неправильно

В общем, это называется кубернетис на ансибле и костылях

Еще один аналитик от бога

из контекста не вырывай. много микросервисов на одной ноде. Не путь микросервисов.

вообще связи нет между архитектору монолит\микросервис и количеством нод. А юнихвей тоже видимо не путь линуха

Ну какбы линукс уже давно на юниксвей плевать хотел.

Пойду лучше поработаю

Тот же системд прям юниксвей,

Кстати, если у тебя все что нужно - сгенерировать шаблон и рестартануть, нафига тебе вообще хендлеры? Делай просто рестарт по changed

Об этом выше писали. Там типо кода больше.

И не красиво получается

Не, он там лепил какую-то дичь с динамической генерацией хендлеров

Я такое делал для деплоя war'ников в томкат, нормально выглядит

https://stackoverflow.com/questions/25694249/ansible-using-with-items-with-notify-handler

Нужен. Сейчас мне приходится пилить такую конструкцию зачастую: - name: Generate {{ daemon }} template: .. - name: Reload systemd systemd: .. Помоему это проще: - name: Generate {{ daemon }} template: .. handler: restart_systemd {{ daemon}}

не то?

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

я так понял ансибл читает из yaml или json

а нужно из простого файлика txt, который правит юзер

можно, конечно генерировать его в yaml или json или т.д. но может подскажите, что удобнее?

я не прошу кода, достаточно лишь ключевых слов, куда копать)

ERROR: S client not available

Yaml хорошо читаем и достаточно прост, совсем не вариант научить юзера делать в тхт файлике что то типа: variable: value ?

думаю, так и буду делать, нормальный вариант а если будут задачи брать на удаленной машине - то конвертировать в json\yaml каким-нибудь скриптом...

нужно будет просить юзера заполнить var, а затем проверить еще эти значения, видимо внешним скриптом... ай, ладно как-нибудь сделаю)

я не прошу кода, достаточно лишь ключевых слов, куда копать)

Есть slurp в ансибле

как я понял, он все переменные отдаст как контент, а переменные разные и их около 10, а не 1

Я ансиблом генерирую демонов для проектов. Или обновляю systemdшные сервисы. Поэтому постоянно приходится вызывать systemd. Хотел через шаблонный хэндлер это упростить

А вот крамолу скажу - а что мешает через systemd зависимости выставить и он сам перезапустит?

А зачем жестко прописывать зависимости? Просто если чтото заставит рестартануть target (например кривые руки эксплуатации), от которого жестко зависят все сервисы, то они тоже рестартанут.

А друг от друга сервисы не зависят

а почему ты массивом то не хочешь сделать список

А почему вы уверенны что у меня не так?

- name: Generate {{ item }} template: .. with_items: ....

и не нужны никакие хендлеры.

У меня для разных типов сервисов разные правила генерации - гдето достаточно только имени, гдето нужно описать дополнительные параметры - и список слов превращается в список списков. Хэндлер хотел использовать чтобы уйти от block/include_tasks - вместо двух шагов выполнять 1

Вообще самое позорное что могли разрабы ансибла придумать - директиву block. Loop на нее повесить нельзя (потому что это не нужно по словам разрабов), name, на который блок вешается, в лог не выводится. Поэтому его выполнение в логе выглядит не как: block: Generate daemon {{name}} -> template -> systemd А просто template -> systemd

Хочешь пояснений? Вешай на каждое действие в блоке name

И в итоге вместо аккуратной группировки получается эталонная херня

каждый таск должен быть с name, вот и все

тебе даже ansible-lint об этом скажет

У меня для разных типов сервисов разные правила генерации - гдето достаточно только имени, гдето нужно описать дополнительные параметры - и список слов превращается в список списков. Хэндлер хотел использовать чтобы уйти от block/include_tasks - вместо двух шагов выполнять 1

но у хендлера совсем другие правила выполнения

И в итоге вместо аккуратной группировки получается эталонная херня

я так понял чтобы использовать ansible в programming-style нужно копать в сторону jinga и использовать всякие макросы, ты не изучал в эту сторону? Правильно я понял или нет?

каждый таск должен быть с name, вот и все

Зачем? Что если я хочу несколько таск сгруппировать логически? Просто пример: - name: Generate monitoring target template: src=etc/systemd/monitoringLLD.target.j2 dest=/etc/systemd/system/{{ SYSTEMD_ZABBIX_MAIN_KEY|default("monitoringLLD") }}.target - name: Generate monitoring failure service template: src=etc/systemd/onfailureLLD@.service.j2 dest=/etc/systemd/system/{{ SYSTEMD_ONFAILURE|default("onfailureLLD") }}@.service - name: Generate monitoring probe template: src=etc/systemd/probeLLD@.service.j2 dest=/etc/systemd/system/{{ SYSTEMD_PROBE|default("probeLLD") }}@.service

ну вот и группируй их в блок, если очень надо

Казалось бы логично что я могу их объединить через block в одну таску: - name: Generate monitoring infrastructure. block: - template: src=etc/systemd/monitoringLLD.target.j2 dest=/etc/systemd/system/{{ SYSTEMD_ZABBIX_MAIN_KEY|default("monitoringLLD") }}.target - template: src=etc/systemd/onfailureLLD@.service.j2 dest=/etc/systemd/system/{{ SYSTEMD_ONFAILURE|default("onfailureLLD") }}@.service - template: src=etc/systemd/probeLLD@.service.j2 dest=/etc/systemd/system/{{ SYSTEMD_PROBE|default("probeLLD") }}@.service

Но изза ебанутой реализации блока приходится делать так: - name: Generate/Re-Generate monitoring infrastructure. block: - debug: msg: Generate/Re-Generate monitoring infrastructure. - template: src=etc/systemd/monitoringLLD.target.j2 dest=/etc/systemd/system/{{ SYSTEMD_ZABBIX_MAIN_KEY|default("monitoringLLD") }}.target - template: src=etc/systemd/onfailureLLD@.service.j2 dest=/etc/systemd/system/{{ SYSTEMD_ONFAILURE|default("onfailureLLD") }}@.service - template: src=etc/systemd/probeLLD@.service.j2 dest=/etc/systemd/system/{{ SYSTEMD_PROBE|default("probeLLD") }}@.service

а чем with_items \ lookup не походит?

логично-не логично, код открытый, идешь и смотришь, можно ли творить такую дичь

Не знаю для какой версии тот пример со stack overflow но в 2.6 хэндлер дергается 1 раз после отыгрывания всего плейбука. И если один и тот же хэндлер вызывается для разных переменных, то он выполнится только для самой последней. Если бы у меня был просто один список сервисов это бы полностью устраивало, но этого нет.

я так понял чтобы использовать ansible в programming-style нужно копать в сторону jinga и использовать всякие макросы, ты не изучал в эту сторону? Правильно я понял или нет?

Я пробовал в имя хэндлера макрос подпихнуть, но сходу не завелось - дальше не стал разбираться - и так на это времени много потратил

Не знаю для какой версии тот пример со stack overflow но в 2.6 хэндлер дергается 1 раз после отыгрывания всего плейбука. И если один и тот же хэндлер вызывается для разных переменных, то он выполнится только для самой последней. Если бы у меня был просто один список сервисов это бы полностью устраивало, но этого нет.

печально, спасибо что проверил, у меня руки еще не дошли, учусь пока что да и вообще я сделал выводы, что ансибл скорее всего буду использовать связкой: питон поверх ансибла, там и проверить пользовательские переменные введенные можно и самому сгенерировать хендлеры и все таски похожие генерировать функциями. Роли мне не понравились... если будут нерешаемые корявости - вообще буду чисто питон использовать с его родными модулями для тех же задач, что и ансибл хотя, возможно, сказывается малый опыт использования этого инструмента у меня и непонимание многого, роли вообще не понял зачем нужны... У меня конкретные задачи: 1 раскатать ПО из набора сервисов на хост, подменить переменные в конфиге на пользовательские. Хосты разные и не связаны с друг другом. Это виделось мне одним плейбуком. 2. Точно также, что выше- но связанные хосты с сервисами (в первом случае однонодовая инсталяция, во втором- многонодовая)

ну так и делаешь блин одну роль и вызываешь ее для разных хостов потом с разными именами

нахера это лепить одной сраной простыней на ямле?

печально, спасибо что проверил, у меня руки еще не дошли, учусь пока что да и вообще я сделал выводы, что ансибл скорее всего буду использовать связкой: питон поверх ансибла, там и проверить пользовательские переменные введенные можно и самому сгенерировать хендлеры и все таски похожие генерировать функциями. Роли мне не понравились... если будут нерешаемые корявости - вообще буду чисто питон использовать с его родными модулями для тех же задач, что и ансибл хотя, возможно, сказывается малый опыт использования этого инструмента у меня и непонимание многого, роли вообще не понял зачем нужны... У меня конкретные задачи: 1 раскатать ПО из набора сервисов на хост, подменить переменные в конфиге на пользовательские. Хосты разные и не связаны с друг другом. Это виделось мне одним плейбуком. 2. Точно также, что выше- но связанные хосты с сервисами (в первом случае однонодовая инсталяция, во втором- многонодовая)

Лучше на логические блоки разбить и из них собирать таски, а в main оставить только какую таску вызвать