Там же есть возможность prompt limit сделать

Ага, я это и сделал) а то что в лимит можно ничего не писать..?))

Не пробовал такой бекдор)

Ага, я это и сделал) а то что в лимит можно ничего не писать..?))

Limit вроде в отдельную переменную попадает https://stackoverflow.com/questions/44855892/how-to-get-value-of-limit-argument-inside-an-ansible-playbook Но я не проверял работает оно или нет)

Limit вроде в отдельную переменную попадает https://stackoverflow.com/questions/44855892/how-to-get-value-of-limit-argument-inside-an-ansible-playbook Но я не проверял работает оно или нет)

О, спасибо

ansible_play_hosts ещё в первом комменте. Завтра и попробую)

И git pull недостаточно в вашем случае. Вам приходится ещё делать крайне сложную структуру роли с лишней логикой

Откуда такие далеко идущие выводы? Ставите диагноз по фотографии? )) Я вижу с вашей стороны желание представить себе картину оторванную от реальности - а потом ее критиковать. В последний раз попробую пояснить: в нашем случае версии ролей в директориях, это альтернатива использованию бранчей, т.е. если бы это было реализовано через git, то версия роли это не commit, а branch.

Откуда такие далеко идущие выводы? Ставите диагноз по фотографии? )) Я вижу с вашей стороны желание представить себе картину оторванную от реальности - а потом ее критиковать. В последний раз попробую пояснить: в нашем случае версии ролей в директориях, это альтернатива использованию бранчей, т.е. если бы это было реализовано через git, то версия роли это не commit, а branch.

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

И только одним репозиторием

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

Если роли лежат больше, чем в одной репе - аналогично

В итоге вы просто дублируете функции гита с непонятной целью, попутно сильно усложняя структуру ролей

Откуда такие далеко идущие выводы? Ставите диагноз по фотографии? )) Я вижу с вашей стороны желание представить себе картину оторванную от реальности - а потом ее критиковать. В последний раз попробую пояснить: в нашем случае версии ролей в директориях, это альтернатива использованию бранчей, т.е. если бы это было реализовано через git, то версия роли это не commit, а branch.

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

Много хостов. накатанных одной ролью, но причём разными версиями O_o Люди упарываются, топят за однообразие, IaaC, servers as cattle, а тут... "..И поднимал он тяжёлые камни, и говорил с ними, вспоминая их имена." Какой тогда вообще смысл Ansible использовать? Скорее всего, из-за башсибла в ролях.

Люди любят усложнять себе. Пока народ стремиться сделать одинаковые прод и дев стенды, другие делают разнообразие прод стендов...

Люди любят усложнять себе. Пока народ стремиться сделать одинаковые прод и дев стенды, другие делают разнообразие прод стендов...

Много хостов. накатанных одной ролью, но причём разными версиями O_o Люди упарываются, топят за однообразие, IaaC, servers as cattle, а тут... "..И поднимал он тяжёлые камни, и говорил с ними, вспоминая их имена." Какой тогда вообще смысл Ansible использовать? Скорее всего, из-за башсибла в ролях.

Во первых, разные проекты внутри компании могут использовать разные версии ролей, во вторых в моменте может быть две версии: текущая и ту на которую переходишь. В третьих возможность задать версию роли через group_vars позволяет не править лишний раз плейбук и переключаться через репу с inventory.

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

ну а третье есть из коробки в ансибле, называется инвентори

И только одним репозиторием

Так и есть, все роли в одной репе. Интересно было бы узнать use case при котором требуется собирать роли из разных реп. Кроме случая притащить какое-нибудь непроверенное г. из чужого репо, ничего не могу представить.

Уф, монорепа с версиями ролей через переименование каталогов, я правильно понял?

Во первых, разные проекты внутри компании могут использовать разные версии ролей, во вторых в моменте может быть две версии: текущая и ту на которую переходишь. В третьих возможность задать версию роли через group_vars позволяет не править лишний раз плейбук и переключаться через репу с inventory.

Ещё раз - это фу, и это - полное непонимание ролей. Роль - это самодостаточная единица, в best practices по Ansible этого что-то не видать, чтобы так над ролями издевались. Во-вторых, это, к сожалению, многое говорит о состоянии инфраструктуры. Здесь эта роль - вот такой версии, здесь - другой, а здесь - третьей. Второе фу. Ну и переизобрести гит в group_vars - это, конечно, сильно, повторюсь, но нет, you shall not pass. Третье фу.

Ох, версия роли в groupvars?

Ох, версия роли в groupvars?

Подаётся это под соусом "зашёл в груп_варс и выбрал версию".

Уф, монорепа с версиями ролей через переименование каталогов, я правильно понял?

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

ну вот >разные проекты внутри компании могут использовать разные версии ролей

вот дали rolesfile.yml, ну пользуйся же, нет?

тут тебе и версии, и гарантированный чекаут вместо "ой, а тут версионность роли не сработала"

Ещё раз - это фу, и это - полное непонимание ролей. Роль - это самодостаточная единица, в best practices по Ansible этого что-то не видать, чтобы так над ролями издевались. Во-вторых, это, к сожалению, многое говорит о состоянии инфраструктуры. Здесь эта роль - вот такой версии, здесь - другой, а здесь - третьей. Второе фу. Ну и переизобрести гит в group_vars - это, конечно, сильно, повторюсь, но нет, you shall not pass. Третье фу.

Хорошо. Расскажите свой способ перевода прода на новую роль? Всё и сразу? ))

О, это моя любимая часть

"ага, вы тут все такие умные, тогда прочитайте мне тут документацию!"

Хорошо. Расскажите свой способ перевода прода на новую роль? Всё и сразу? ))

Вообще-то да. А какие варианты есть? Либо новая роль по всему продакшну раскатана, либо надо написать петицию на change.org о профнепригодности ролеписца/опса.

Вообще-то да. А какие варианты есть? Либо новая роль по всему продакшну раскатана, либо надо написать петицию на change.org о профнепригодности ролеписца/опса.

Круто, подход настоящего самурая...

Круто, подход настоящего самурая...

А с вашим подходом, похоже, прям хромированные версии ролей тряпочкой с колой протирают. "... А ты 2.4.2 пробовал?.... - Не, не встала, не нашла чот-там. - Ну блин, ну тогда попробуй 2.5.0 хотя бы. - Да ладно, я уже 2.7.1 накатил [давит бычок в пепльнице] Пошли давай, до утра ещё сотню серверов обновить надо." (с)

"ага, вы тут все такие умные, тогда прочитайте мне тут документацию!"

+100500

причем это пуллреквест с чем-то вроде https://github.com/ljozsa/ansible-raspi/commit/9d85c83ecf95dfcd4deca8b9f7a4c38a4cbbf13c + CI

А с вашим подходом, похоже, прям хромированные версии ролей тряпочкой с колой протирают. "... А ты 2.4.2 пробовал?.... - Не, не встала, не нашла чот-там. - Ну блин, ну тогда попробуй 2.5.0 хотя бы. - Да ладно, я уже 2.7.1 накатил [давит бычок в пепльнице] Пошли давай, до утра ещё сотню серверов обновить надо." (с)

С тем что версий не должно быть много я соглашусь. Но напрасно вы отвергаете саму возможность версионирования.

С тем что версий не должно быть много я соглашусь. Но напрасно вы отвергаете саму возможность версионирования.

Да с чего бы вдруг? Лично я всегда все роли храню в репе. А Вадим уже написал, как это стОит делать по-человечески, а не через странное.

Да с чего бы вдруг? Лично я всегда все роли храню в репе. А Вадим уже написал, как это стОит делать по-человечески, а не через странное.

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

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

Что значит "не всё"? Не всё учёл - вылезет на тесте либо на стейдже. А демагогию разводить - "часть хостов, не часть хостов" - это такое себе. Для запуска Ансибла на работу только с частью хостов - если уж хочется поблем себе запилить - можно использовать ключ "-l", но это уже в доки нужно..... 😉

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

Что мешает запустить роль в тестовом инвентори и с лимитом по хостам/группам?

Я уж молчу про тестирование ролей через докеры те же например

Что значит "не всё"? Не всё учёл - вылезет на тесте либо на стейдже. А демагогию разводить - "часть хостов, не часть хостов" - это такое себе. Для запуска Ансибла на работу только с частью хостов - если уж хочется поблем себе запилить - можно использовать ключ "-l", но это уже в доки нужно..... 😉

Ок. Допустим вылезло на стейдже. Так и как вы делаете что у вас на стейдже и проде разные версии ролей?

А зачем так делать?

Точнее не так, если вам надо разные, то зачем сверять?

А если одинаковые, то зачем делать разные?

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

это называется canary deployments, да

рядом с ними еще идут blue-green или вообще colorful

казалось бы, причем тут роли?

Ок. Допустим вылезло на стейдже. Так и как вы делаете что у вас на стейдже и проде разные версии ролей?

Всё просто - я не запускаю деплой на продакшн. Есть такая категория. как вебморды. В период тестов из мастера вебморда для продакшна отключается. Опять же - в репозитории с ролями могут существовать теги, и вообще ничто не мешает деплоить продакшн по тегу (как это можно делать, впрочем, с любым кодом, хранящимся в системе контроля версий). И ещё - если всё-таки изначально одними скриптами деплоить всё, то расхождений (кроме мощности самих хостов) не будет.

казалось бы, причем тут роли?

Наверное при том что там могут завалятся темплейты конфигов... ) Всякие модные etcd и k8s пока сюда не будем приплетать... )

не умеете собирать список создаваемых артефактов? Что ж, тогда так и живите

Всё просто - я не запускаю деплой на продакшн. Есть такая категория. как вебморды. В период тестов из мастера вебморда для продакшна отключается. Опять же - в репозитории с ролями могут существовать теги, и вообще ничто не мешает деплоить продакшн по тегу (как это можно делать, впрочем, с любым кодом, хранящимся в системе контроля версий). И ещё - если всё-таки изначально одними скриптами деплоить всё, то расхождений (кроме мощности самих хостов) не будет.

В моей терминологии это load balancer и для него тоже кто-то должен через ansible конфиг принести...

В моей терминологии это load balancer и для него тоже кто-то должен через ansible конфиг принести...

Лоад балансер - это другое. Вебморда - Rundeck/AWX/Tower/polemarch/Foreman/<younameit>.

Лоад балансер - это другое. Вебморда - Rundeck/AWX/Tower/polemarch/Foreman/<younameit>.

Не совсем понял. Вы при любом комите в репо с ролями, отключаете AWX от прода? Или как это выглядит?

Не совсем понял. Вы при любом комите в репо с ролями, отключаете AWX от прода? Или как это выглядит?

Нет. При любом коммите в репо с ролями я чётко себе представляю, что именно я коммичу и для чего. Места для поедания кактусов находятся на тесте и стейдже.

Но мы вообще-то в странную плоскость перешли, при чём тут вообще как именно сделано у меня?

Ресь о том, что так, как сделано в вашей компании - не надо делать.

Нет. При любом коммите в репо с ролями я чётко себе представляю, что именно я коммичу и для чего. Места для поедания кактусов находятся на тесте и стейдже.

Ну вот, а при нашем варианте, можно через group_vars разнести выкатку новой версии роли для стейджа и прода по времени.

Ну вот, а при нашем варианте, можно через group_vars разнести выкатку новой версии роли для стейджа и прода по времени.

Не стоит признаваться в этом на людях.

Ресь о том, что так, как сделано в вашей компании - не надо делать.

А я считаю что так как у вас не надо делать. Давайте исходить из того что нужны аргументы чтобы доказать оба тезиса...)

А я считаю что так как у вас не надо делать. Давайте исходить из того что нужны аргументы чтобы доказать оба тезиса...)

Я не предлагаю делать "как у меня" вообще-то.

Ну вот, а при нашем варианте, можно через group_vars разнести выкатку новой версии роли для стейджа и прода по времени.

это какой-то новый вид метапрограммирования на ямлах ящитаю

Senior YaML developer 😊

Какой у вас тут лютый пиздец. У меня файл requirements.yaml и в нём роли с версиями и именем, а не чтобы именем роли, имя РЕПО делать. Хочу одну роль под разными именами скачаю и будет у меня 2 роли разных версий под ( но это странное)

А ещё то что назвал странный человек ролью, по сути ролью не является, а просто плейбуком

Какой у вас тут лютый пиздец. У меня файл requirements.yaml и в нём роли с версиями и именем, а не чтобы именем роли, имя РЕПО делать. Хочу одну роль под разными именами скачаю и будет у меня 2 роли разных версий под ( но это странное)

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

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

Канеш могу, теги мне на что?

а, ну с тегами сфейлить слишком просто

а, ну с тегами сфейлить слишком просто

Тут и без них нафейлино дай божэ

Какой у вас тут лютый пиздец. У меня файл requirements.yaml и в нём роли с версиями и именем, а не чтобы именем роли, имя РЕПО делать. Хочу одну роль под разными именами скачаю и будет у меня 2 роли разных версий под ( но это странное)

два чаю этому реповоду, мы делали ещё типа метарепу под каждый проект, в ней в тегах выкатываемого окружения - в реквайрах теги нужных ролей, люто удобно однако

но у нас было несколько (довольно много) разных проектов, с разным набором унифицированных ролей

и все проекты в итоге могли иметь свой набор версий, как продовых, проверенных, так и стейджевых, и дев-вакханалией

ansible/ansible was tagged: v2.7.5 Link: https://github.com/ansible/ansible/releases/tag/v2.7.5 Release notes: New release v2.7.5

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

Почему проект нельзя собирать на уровне одного плея или нескольких? Зачем роль в роль? Как эти вложенные роли переиспользовать потом?

Какой у вас тут лютый пиздец. У меня файл requirements.yaml и в нём роли с версиями и именем, а не чтобы именем роли, имя РЕПО делать. Хочу одну роль под разными именами скачаю и будет у меня 2 роли разных версий под ( но это странное)

День добрый! Ошибка тупая замучила блин. Подскажите. Есть таск файл с содержимым: --- - name: Script directory create file: path: "{{ pg_script_dir }}" owner: postgres group: postgres state: directory mode: 0775 и main, который его вызывает: --- - include: create_users.yml when: users_create Ошибка такая: TASK [barman : Script directory create] ******************************************************************************************************************************************** fatal: [ip_addr]: FAILED! => {"msg": "The conditional check 'users_create' failed. The error was: error while evaluating conditional (users_create): 'users_create' is undefined\n\nThe error appears to have been in '/home/barman/git_projects/barman/tasks/create_users.yml': line 3, column 3, but may\nbe elsewhere in the file depending on the exact syntax problem.\n\nThe offending line appears to be:\n\n\n- name: Script directory create\n ^ here\n"} to retry, use: --limit @/home/barman/git_projects/barman_run.retry Возможно ошибка в отступах

версия ansible 2.7.4

Ошибка в другом таске же

Не в том, который вы показали