« Rev
@pro_ansible   1387
Fwd »


Dmitry
И вы продолжаете путать явное и неявное. Прописанная в роли зависимость - _явная_. Неявная это когда мы просто используем роли вместе.
Sergey
Предлагаемое использование ролей. Не надо так.
Dmitry
Я не вижу аргументов или хотя бы примера. Мантры меня не интересуют.
Dmitry
Как должно быть: есть роль сайта, в ней прописана зависимость от роли nginx, в playbook упоминается только сайт, все счастливы. Изменился nginx на апач, изменили роль вместе с зависимостью, все счастливы. При отсутствии зависимости забыли добавить апач (во все!) плейбуки - получили то что на гифке.
Sergey
Я не вижу аргументов или хотя бы примера. Мантры меня не интересуют.
Ты имеешь полное право писать сложноотлаживаемый код с нестандартными подходами, полностью игнорируя лучшие практики, объектную модель самого инструмента и запрошенные советы более опытных коллег. Только вопросы по этому странному сюда заносить неконструктивно: мы тут всё-таки обсуждаем использование инструмента по назначению, а сюда могут заходить новички, и им может на секундочку показаться, что ты предлагаешь что-то классное.
Aleksey
Чятик. Я очень слабо понимаю как работает ансибл, но я тут кубспрей ковыряю и возникли вопрсоы. Если коротко, то я хочу перопределить переменную из кишок в рамках своей иерархии папок. Вот репа, чтоб ориентироваться в том, что я говорю: https://github.com/kubernetes-sigs/kubespray, далее все пути относительно корня репы Хочется сложить все изменения в рамках inventory/sample, там даже есть нечто похожее — group_vars/all/all.yml Меня интересует kube_proxy_metrics_bind_address, нашёл в файлах: roles/kubernetes/master/defaults/main/kube-proxy.yml extra_playbooks/roles/kubernetes/master/defaults/main/kube-proxy.yml Подскажите что и куда можно написать в рамках inventory/sample для переопределния kube_proxy_metrics_bind_address? Подозреваю, что там всё просто, но я вообще не уверен в том какие там области видимости и как это вообще взаимодействует
Pavel
для этого и есть плейбуки - для одних сайтов том один набор ролей, для других - другой
Sergey
Чятик. Я очень слабо понимаю как работает ансибл, но я тут кубспрей ковыряю и возникли вопрсоы. Если коротко, то я хочу перопределить переменную из кишок в рамках своей иерархии папок. Вот репа, чтоб ориентироваться в том, что я говорю: https://github.com/kubernetes-sigs/kubespray, далее все пути относительно корня репы Хочется сложить все изменения в рамках inventory/sample, там даже есть нечто похожее — group_vars/all/all.yml Меня интересует kube_proxy_metrics_bind_address, нашёл в файлах: roles/kubernetes/master/defaults/main/kube-proxy.yml extra_playbooks/roles/kubernetes/master/defaults/main/kube-proxy.yml Подскажите что и куда можно написать в рамках inventory/sample для переопределния kube_proxy_metrics_bind_address? Подозреваю, что там всё просто, но я вообще не уверен в том какие там области видимости и как это вообще взаимодействует
Любые переменные, определённые в роль/defaults, можно переопределить в inventory, в group_vars, в host_vars - где удобно.
citius
Как должно быть: есть роль сайта, в ней прописана зависимость от роли nginx, в playbook упоминается только сайт, все счастливы. Изменился nginx на апач, изменили роль вместе с зависимостью, все счастливы. При отсутствии зависимости забыли добавить апач (во все!) плейбуки - получили то что на гифке.
Мне кажется лучше абстрагироваться от "роль сайта" и для сайта все таки сделать параметризуемые плейбуки с плеями. Но при этом плейбуков может быть всего два: apache_site.yml и nginx_site.yml, а все детали им передавать через инвентари и переменные. Тогда не нужно будет "менять все(!) плейбуки", а нужно будет менять только один. Насчёт зависимостей ролей от ролей - это реальная боль, когда ты берешь например с галакси какую-то роль условного редиса, которая по зависимостям потом за собой тянет пачку мелких ролей, включая в итоге какую-нибудь bootstrap_server.role которая тебе в итоге переделываает нахрен весь твой сервер самым неожиданным образом.
Aleksey
Любые переменные, определённые в роль/defaults, можно переопределить в inventory, в group_vars, в host_vars - где удобно.
Спасибо! То есть, я могу сунуть в `group_vars/all/all.yml` нужную пару и оно точно будет переписано? ТЫ вроде это и сказал, но уже вечер пятницы и я туплю.
Dmitry
Ты имеешь полное право писать сложноотлаживаемый код с нестандартными подходами, полностью игнорируя лучшие практики, объектную модель самого инструмента и запрошенные советы более опытных коллег. Только вопросы по этому странному сюда заносить неконструктивно: мы тут всё-таки обсуждаем использование инструмента по назначению, а сюда могут заходить новички, и им может на секундочку показаться, что ты предлагаешь что-то классное.
Звиняйте, но если вы не можете объяснить в чём лучшесть ваших практик, то грош им цена. Мне начинает казаться что вы за них просто выдаёте ограничения инструмента. Безотносительно ansible, зависимости - распространённая концепция, использующаяся много где, включая например разработку, управлении пакетами и разделяемыми библиотеками, и везде она работает замечательно и переносимо, и ни у кого не возникает мысли, например, в приложении на питоне указать в зависимостях все модули которые загружаются в процессе работы вместо только непосредственных зависимостей Так вот не вижу чем использование зависимостей здесь будет отличаться. Собственно, расскажите как предполагается "правильно" действовать в ситуации описанного примера - есть "условный сайт" и есть "условный nginx" без которого он работать не может. Нужно поднять хост с этим сайтом. Насколько я понял, предлагается "явно" прописать в playbook'е обе роли. Тогда: - откуда вообще человек который пишет playbook узнает что сайту нужен nginx? - что будет когда сайту перестанет быть нужен nginx, а понадобится апач?
Aleksey
Да, верно.
ну ты просто сделал мой день! ❤️ Понимаю, что лениться не хорошо, но сил на доку уже вообще нет.
Sergey
Звиняйте, но если вы не можете объяснить в чём лучшесть ваших практик, то грош им цена. Мне начинает казаться что вы за них просто выдаёте ограничения инструмента. Безотносительно ansible, зависимости - распространённая концепция, использующаяся много где, включая например разработку, управлении пакетами и разделяемыми библиотеками, и везде она работает замечательно и переносимо, и ни у кого не возникает мысли, например, в приложении на питоне указать в зависимостях все модули которые загружаются в процессе работы вместо только непосредственных зависимостей Так вот не вижу чем использование зависимостей здесь будет отличаться. Собственно, расскажите как предполагается "правильно" действовать в ситуации описанного примера - есть "условный сайт" и есть "условный nginx" без которого он работать не может. Нужно поднять хост с этим сайтом. Насколько я понял, предлагается "явно" прописать в playbook'е обе роли. Тогда: - откуда вообще человек который пишет playbook узнает что сайту нужен nginx? - что будет когда сайту перестанет быть нужен nginx, а понадобится апач?
Не извиняю, и вот почему. Я что-то объясняю только тем людям, которые готовы слушать и слышать. Таких, кстати, хватает на митапах, на работе, и даже недавно на конференции, не говоря уже про этот чат. А ты можешь делать так, как сочтёшь нужным. Дальнейшие набросы - прямой путь в R/O.
simplemice.eth
Не извиняю, и вот почему. Я что-то объясняю только тем людям, которые готовы слушать и слышать. Таких, кстати, хватает на митапах, на работе, и даже недавно на конференции, не говоря уже про этот чат. А ты можешь делать так, как сочтёшь нужным. Дальнейшие набросы - прямой путь в R/O.
короткий ответ: нет, нельзя. длинный ответ: нет, нельзя, и почему это так, я рассказываю на курсах за деньги супердлинный ответ: можно, но для того, чтобы это настроить, надо быть очень прошаренным экспертом
simplemice.eth
можно переделать под нужды
Отделение Bereke Bank
@tnt4brain ты ведёшь курсы по ансиболи за деньги? 🤔 яб послушал
Павел П.
Звиняйте, но если вы не можете объяснить в чём лучшесть ваших практик, то грош им цена. Мне начинает казаться что вы за них просто выдаёте ограничения инструмента. Безотносительно ansible, зависимости - распространённая концепция, использующаяся много где, включая например разработку, управлении пакетами и разделяемыми библиотеками, и везде она работает замечательно и переносимо, и ни у кого не возникает мысли, например, в приложении на питоне указать в зависимостях все модули которые загружаются в процессе работы вместо только непосредственных зависимостей Так вот не вижу чем использование зависимостей здесь будет отличаться. Собственно, расскажите как предполагается "правильно" действовать в ситуации описанного примера - есть "условный сайт" и есть "условный nginx" без которого он работать не может. Нужно поднять хост с этим сайтом. Насколько я понял, предлагается "явно" прописать в playbook'е обе роли. Тогда: - откуда вообще человек который пишет playbook узнает что сайту нужен nginx? - что будет когда сайту перестанет быть нужен nginx, а понадобится апач?
Улыбнулся на «зависимости в управлении пакетами работают замечательно»
Отделение Bereke Bank
А блин это вообще от другого человека сообщение
Отделение Bereke Bank
Звиняйте, но если вы не можете объяснить в чём лучшесть ваших практик, то грош им цена. Мне начинает казаться что вы за них просто выдаёте ограничения инструмента. Безотносительно ansible, зависимости - распространённая концепция, использующаяся много где, включая например разработку, управлении пакетами и разделяемыми библиотеками, и везде она работает замечательно и переносимо, и ни у кого не возникает мысли, например, в приложении на питоне указать в зависимостях все модули которые загружаются в процессе работы вместо только непосредственных зависимостей Так вот не вижу чем использование зависимостей здесь будет отличаться. Собственно, расскажите как предполагается "правильно" действовать в ситуации описанного примера - есть "условный сайт" и есть "условный nginx" без которого он работать не может. Нужно поднять хост с этим сайтом. Насколько я понял, предлагается "явно" прописать в playbook'е обе роли. Тогда: - откуда вообще человек который пишет playbook узнает что сайту нужен nginx? - что будет когда сайту перестанет быть нужен nginx, а понадобится апач?
Прописать роли явно в плейбуке - наглядно и читаемо Сносишь nginx, ставишь апач другой ролью, которую ставишь в плейбук вместо Nginx
Sergey
А блин это вообще от другого человека сообщение
Я на работе курсы по Ансиблу читаю, и подумываю отдельно свои запилить с ИП, оплатой картой и прочим.
Dmitry
Не извиняю, и вот почему. Я что-то объясняю только тем людям, которые готовы слушать и слышать. Таких, кстати, хватает на митапах, на работе, и даже недавно на конференции, не говоря уже про этот чат. А ты можешь делать так, как сочтёшь нужным. Дальнейшие набросы - прямой путь в R/O.
А что слышать-то? От вас услышал пока +++ и гифку, товарищ который рассказывал про выстрел в ногу тоже замолчал. Не нужно себя лучше других считать, я тоже на конференциях выступаю - это не повод высказать догму, не аргументировать её и считать что тебе должны просто поверить
Dan
Звиняйте, но если вы не можете объяснить в чём лучшесть ваших практик, то грош им цена. Мне начинает казаться что вы за них просто выдаёте ограничения инструмента. Безотносительно ansible, зависимости - распространённая концепция, использующаяся много где, включая например разработку, управлении пакетами и разделяемыми библиотеками, и везде она работает замечательно и переносимо, и ни у кого не возникает мысли, например, в приложении на питоне указать в зависимостях все модули которые загружаются в процессе работы вместо только непосредственных зависимостей Так вот не вижу чем использование зависимостей здесь будет отличаться. Собственно, расскажите как предполагается "правильно" действовать в ситуации описанного примера - есть "условный сайт" и есть "условный nginx" без которого он работать не может. Нужно поднять хост с этим сайтом. Насколько я понял, предлагается "явно" прописать в playbook'е обе роли. Тогда: - откуда вообще человек который пишет playbook узнает что сайту нужен nginx? - что будет когда сайту перестанет быть нужен nginx, а понадобится апач?
стандартная практика в ролях просто указывать какие еще роли нужны. пример: https://github.com/geerlingguy/ansible-role-glusterfs#requirements
Dan
или я не понял вопрос?
Sergey
или я не понял вопрос?
Человек хочет странное. Ему сказали - не надо. Он против. Ему сказали - ок, делай как знаешь. Он опять против. Результат предсказуем.
k
Прописать роли явно в плейбуке - наглядно и читаемо Сносишь nginx, ставишь апач другой ролью, которую ставишь в плейбук вместо Nginx
Указывать все зависимости прямо в буке - хорошее решение, если оперировать плейбуками на уровне "я хочу поставить сначала это, а потом это". Но так мы отказываемся от декларативной сути плейбука и превращаем его в императивный скрипт, верно? Более сильным решением будет просто написать в плейбуке, что вам надо получить вот такой вот сервис, доверив роли установку нижележашего софта. Тот же geerlingguy вполне использует зависимости: https://github.com/geerlingguy/ansible-role-jenkins/blob/master/meta/main.yml#L2-L3
Отделение Bereke Bank
Мне как-то проще посмотреть в плейбук чем в мету роли. Хз насколько это корректно - я делаю роли максимально независимыми от других. Надо поставить зависимости - пропиши их установку в той же роли.
Dan
это может создать лишние телодвижения когда надо накатить несколько ролей на один хост
Dan
когда я пишу роли не для галакси а для себя, у меня просто отдельный шаг для всех зависимостей, делаю как привык еще со времен requirements.txt
Отделение Bereke Bank
либо, если это возможно - сделай проверку на наличие пакетов (того же nginx-а) и определяй поведение роли уже исходя из этого. Например, есть роль для прометея. в ней package check в самом начале Если nginx есть - ок грузи конфиг vhost-а и релоадь nginx Если нет - ничего страшного, прометей работает и без него
Dan
да, вариантов на самом деле куча, просто мои плейбуки обычно бегут по несколько часов, и я стараюсь оптимизировать их по максимуму (ансибль хорош, но тормозит жутко)
Отделение Bereke Bank
Тормознутость это да. Нам значительно помогло перетаскивание кучи тасок по «первоначальной настройке» в packer. Но вот что делать с тормозным slurp copy который активно используется в кубернетес плейбуке хз.
Dan
у всех там хз :) у меня тут до абсурда доходило - надо было автоматизировать подъем системы с очень быстрой БД, плюс хосты генерирующие нагрузку плюс мониторинг, чтоб загрузить базу по быстрому, вытащить полученные данные из мониторинга и все убить нафиг. Подъем системы занимал дольше чем запихать в базу несколько триллионов записей
Igor
как в ансибле сделать аналог mkdir -p /opt/folder1/folder2
Igor
хочу в одном таске две папки создать - folder1 folder2
Dan
емнип никак, кроме как через shell/command
Igor
жаль, думал без шелл модуля этоможно
Igor
башсибл все таки не очень хочется городить))
k
хочу в одном таске две папки создать - folder1 folder2
- name: ... file: path: /opt/folder1/folder2 state: directory recurse: true
Dan
recurse уже работает? У меня отваливался
Timur
Сутки R/O
Ох, суров ты, царь-батюшка...
k
Мне как-то проще посмотреть в плейбук чем в мету роли. Хз насколько это корректно - я делаю роли максимально независимыми от других. Надо поставить зависимости - пропиши их установку в той же роли.
Я бы сказал, что роли должны быть разные - одни для базовой установки вспомогательного софта (docker, nginx, postgresql), а другие для описания какого-то сервиса (jira, mywebsite, postgresql_cluster) и могут включать в себя более базовые роли. Оперировать сущностями всё-таки хочется на уровне логических групп/сервисов, а не отдельными хостами и пакетами. Вроде в этом и была суть ансибла когда-то.
k
На этой мысли уйду, всем хороших выходных!
Отделение Bereke Bank
recurse уже работает? У меня отваливался
Хз почему отваливается - можешь сделать тем же модулем и через loop
Igor
А в чем проблема?
у меня не создавало без рекурса
Igor
не знал про эту опцию
Отделение Bereke Bank
у меня не создавало без рекурса
Странно учитывая что If directory, all intermediate subdirectories will be created if they do not exist.
Timur
у меня не создавало без рекурса
Так без рекурсии и не должно
Lamobot
у меня не создавало без рекурса
recurse это про установку атрибутов всем файлам в директории А создается со всеми уровнями вложенности обычным: - file: path: /etc/ansible/test/test/test/test/final state: directory
да, это я
Вотета пожар. Кому хоть пишешь-то?
да, это я
Ну ты его тэгни хоть, а то пишешь в пустоту, а потом будешь кричать что этот Сергей слился. У подавляющего большинства чаты на мьюте.
да, это я
А, ну лан.
да, это я
Куда? На деревню дедушке?
да, это я
С попенсорцом лично мне всё давно понятно, хз чё ты горишь.
да, это я
Телепаты в отпуске. Ты припёрся в публичный чат с личными претензиями, откуда я знаю, с чего у тебя срака горит?
да, это я
Понятно, что речь про Энсибл.
да, это я
Я вот человек совсем со стороны, но могу сказать, что если ты решился вынести проблему в паблик, то делай по-нормальному, с доводами, скринами, обрисовыванием сути проблемы наконец, а не как истеричная баба пиши намёками и разводи скандал. Вопросы решаются по сути, сути пока нет, зато есть ошмётки твоей сраки по всему чату. И я не удивлюсь если тебя с таким подходом пошлют ещё дальше, адекватность ты пока не демонстрируешь, даже если ты прав по сути.
да, это я
Мне? Да ни с какого. Ты же хотел публичного обсуждения? Ты его получил. Пока ты выглядишь как обиженка. Повторюсь, даже если изначально ты прав.
да, это я
И шёл бы в личку, раз тебе достаточно его ответа. Зачем это здесь тогда?
да, это я
Ну вот тебе мой совет, оформи свои претензии по-человечески, никто вникать в суть проблемы с такой подачей не будет. Тем более если правда на твоей стороне, чего стоит написать, что я-де предложил такое, оно полезно тем-то тем-то, а Сергей редиска не принимает, настучите ему по одному месту. Чего истерить-то?
да, это я
Ещё не поздно его заточить и описать суть проблемы по полочкам.
да, это я
Ладно. Я попытался.
да, это я
Гм. А как связаны го и Энсибл? P.S. Загугли Kubespray.
да, это я
Ясно всё с тобой.
да, это я
И что?
« Rev
@pro_ansible   1387
Fwd »