только в ansilble-playbook - > —limit '! group'

Гм, это не спасает вот при какой ситуации, если в одном плейбуке: Host: all Role: ... Host: windows App ---- ansible пытается собрать факты с помощью судо с винхостов и выдается ошибка

Когда я запускаю ansible-playbook -l windows...

gather_facts: false

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

вообщем, проблема в том, что я в одном плейбуке, где используются hosts: all hosts: windows не могу использовать

не работаю с виндой. по доке - http://docs.ansible.com/ansible/intro_windows.html#windows-facts

по доке всё ок

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

может все таки - разделяй и властвуй ?

я думаю это из раздела "мы не доработали функционал в ansible"

Гм, это не спасает вот при какой ситуации, если в одном плейбуке: Host: all Role: ... Host: windows App ---- ansible пытается собрать факты с помощью судо с винхостов и выдается ошибка

ключевой момент - с помощью sudo ) - какой sudo на винде ?

become: false

В том то и дело, что никакой

Become - не включен, become: no не помогает

ну он для галочки ) там подозреваю не может быть sudo. Хз как ансибл на винде себя ведет и под кем там работает

я понял в чём дело

- hosts: all become: yes - hosts: windows become: no TASK [Gathering Facts] ******************************************************************************************************************************************************************************************** Using module file /usr/local/lib/python2.7/dist-packages/ansible/modules/windows/setup.ps1 fatal: [app2]: FAILED! => { "failed": true, "msg": "Internal Error: this connection module does not support running commands via sudo"

become: no в группе win - игнорируется, когда become: yes в hosts: all

да и при чём тут это

когда я с помощью тэга указывааю выполнять роль только из группы windows

надо пилить багрепорт

тебе четким написано )

роли желательно накатывать с become: true как по мне... все остальное по надобности ... отключать на уровне тасков или включать... гибко можно

мне кажется ты не читаешь что я пишу

- hosts: all become: yes - hosts: windows become: no

какой к чёрту sudo?

если я выполняю только роль в группе хостов windows

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

в общем - разделяй и властвуй

мне кажется это противоречие - баг, и это недоразумение надо доработать )

да что ты ))))

представь себе

чтобы sudo не пыталось выполняться к windows модулям

это когда у тебя есть роль nginx+роль которая завязана на nginx и две группы хостов ... на одних ты ставишь nginx + на других nginx и еще что то... так вот .... если на первых у тебя по условию не должет рестартовать nginx он и на вторых не отрестратится - А ТЕБЕ НАДО ЧТОБЫ ОТРЕСТАРТИЛСЯ.... выход один - называть по разному один и тот же хендлер... либо разделять плейбуки

become паходу работает точно также

могу в коде найти

проблема в том, что become: yes не может ни при каких условиях отработать на windows модулях которые это не поддерживают, а если в ansible есть win модули которые это не поддерживают, стало быть они не должно быть попыток выполнить эти модули через sudo

я согласен на работающий become: no при host: all, become: yes

меня это устроит

господа, вот я чот затупил, спните с мертвой точки. выполняю плейбук, в нём таски. - hosts: all и мне надо, чтобы одна - две задачи выполнились на только одном хосте. писать два раза - hosts: all и - hosts: host1234 неверно. я откуда-то помню конструкцию when: blablabla in ansible_hostname но чот не могу понять рабочая ли она?

when: ansible_hostname == "host1234" спасибо :))

@lastsky - delegate_to: host and run_once: true

один раз - на конкретном хосте

можно захардкодить как when: inventory_hostname=='blablabla'

@lastsky - delegate_to: host and run_once: true

вот мне как раз так и надо. но я хотел без delegate чтобы. :) мне проще захардкодить

потому что там на самом деле будет hostname переменной

которая определяется в начале через vars_prompt

то есть, очень специфический кейс

вне best practice

Не проблема это и с delegate_to использовать

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

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

поэтому через when: ansible_hostname == "{{ target_host }}" отлично ограничивается

Привет. Объясните мне, дурачку. Почему become распостраняется на все последующие таски, а не ограничивается областью видимости задачи?

Или блока/роли.

cat ansible.cfg | grep become ?

потому что у меня есть пример таска где become: false и он выполняется как надо а последующие - без

cat ansible.cfg | grep become ?

$ cat ./.ansible.cfg |grep become # https://docs.ansible.com/ansible/become.html#becoming-an-unprivileged-user become=True become_method=sudo

ну всё понятно, закомментируй become в конфиге.

и тогда будет per-task / per-role / per-play

Вот именно, приходится добавлять become:false , что не очень удобно. Особенно при изменении порядка тасков.

и тогда будет per-task / per-role / per-play

спасибо, попробую

@FolderArchive - канал, где сливают платный полезный - образовательный контент и курсы, например можно скачать курсы "Нетологии" или все курсы "Бизнес Молодости".

Кстати, коллеги

ERROR: S client not available

а есть возможность в ansible устанавливать всякое левое ПО

через инсталляторы setup.exe всякие и управлять этим

?

проблемы виндоебов ... :)

но вообще есть что-то http://docs.ansible.com/ansible/win_package_module.html

ещё есть чоколатей

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

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

ага, спасибо

ну кмк любой msi должен уметь ставиться молча, не?

там же вроде можно как-то автоответы подсунуть

там же вроде можно как-то автоответы подсунуть

можно, но есть дятлы

так мне не msi надо

а левый софт

а осталось что-то левое без msi?

нахер оно такое, совсем уж самопал какой-то

одинэска7.3 какаянибудь?

полно софта которое не распространяется в формате msi

а с какими-то другими инсталляторами

хотя там внутри может быть msi, надо проверить

внутри там обычно msi

можно сходить к вендору в help и спросить умеет ли их инсталятор в quiet и кушать конфиг из кли. если не умеет то задуматься о смене вендора. или костялять на павершеле что то

обернутый каким-нить installshield'ом

а я правильно понимаю что в табличке те которые поставлены No в "Can build Windows Installer" не имеют msi внутри, да? https://en.wikipedia.org/wiki/List_of_installation_software

Видимо да

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

А чоколати круть, но вроде собственный центр обновления только по платной подписке?

винда нацелена, насолько я понимаю, на "корпоротивных клиентов" - потому считается что никаких анизимбей быть не должно - только через АД

всус там

wsus

(или он был был несколько лет назад)