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

потому, что "когда стоит become"

но когда я хочу например создать директорию или скопировать файл, become необходим? верно?

вовсе не обязательно. все зависит от прав

просто сейчас другая ошибка. Находил решение remote_tmp = /tmp/.ansible-${USER}/tmp Не помогло

ленивый и не правильный вариант: в файл /etc/sudoers.d/ИМЯ_ПОЛЬЗОВАТЕЛЯ %ИМЯ_ПОЛЬЗОВАТЕЛЯ ALL=(ALL) NOPASSWD: ALL

единственно верный must have

а не лучше ли использовать vault?

Народ, а если инвентори в ini - там шаблонизатор работает? hostname="{{inventory_hostname}}" Такое сработает? Или только в ямлах? В доке явных упоминаний не нашел.

Друзья, кто-нибудь может показать пример удачного статического инвентори, где хосты делятся одновременно по окружению (prod/stage) и по функционалу (web/db/etc)? Хочется добавить хост в инвентори в одной точке, но чтобы он попал во все нужные группы Кажется, так не получается - надо отдельно добавлять в группу по окружению и отдельно в функциональную

в ини нет. но если в *_vars в ямлах, то должно

Для prod и stage лучше вообще разные инвентари иметь

Для prod и stage лучше вообще разные инвентари иметь

а пароли пользователей в волте хранить не стоит?

Не всегда У меня, например, выигрыша от выноса окружений в отдельный инвентори нет

Типа задеплоить на прод вместо стейджа

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

Как к authorized_key прикрутить when, чтобы проверял наличие ключа в каталоге. Если есть - катает, если нет - скипает

в чем разница указать разный инвентарь или указать разные группы в едином инвентаре?

проверить файл и зарегать ответ, затем when по результату

полностью и безоговорочно с Вами согласен. Однако, чтобы быть объективным и полностью закрыть вопрос, предположу, что наша дискуссия, касаемо параноиков в контексте безопасности, могла бы сильно развиться и зависнуть примерно на этом - https://stopdisablingselinux.com/

Выигрыш в том, что минимизируется риск любых накладок

Как к authorized_key прикрутить when, чтобы проверял наличие ключа в каталоге. Если есть - катает, если нет - скипает

А зачем разные группы? Чтобы на прод и стейдж еще и разные плейбуки?

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

Всем привет! А можно в host_vars добавить переменную которая бы добавляла данные в переменную из all, а не заменяла её?

Про идемпотентность слышали что-нибудь?

Всем привет! А можно в host_vars добавить переменную которая бы добавляла данные в переменную из all, а не заменяла её?

Пока не очень понимаю, при чем здесь это?

Почитайте

Если у вас на прод и стейдж разная логика - вы что-то делаете не так

бро, ты же сам написал "А зачем разные группы? Чтобы на прод и стейдж еще и разные плейбуки?" )))) и? в зеркало посмотри! это у тебя разная логика

Ничего не понял, если честно. Какая задача решается?

Мой пойнт как раз в том, что разной логики быть не должно

например в all.yml прописываю переменную со списком параметров, как сделать чтобы для хоста список параметров добавился, а не заменился. ну или просто скопировать всё в хост параметры?:)

А разница между продом и стейджем - в разных инвентарях

ну дык, рули логику по группам! если уже так, то зачем тебе еще и рулилка по инвентарю?

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

ну дык, рули логику по группам! если уже так, то зачем тебе еще и рулилка по инвентарю?

Вообще есть мнение, что инвентори концептуально должен быть список *тегированных* хостов, а не *сгрупированных*

что есть инвентарь, как не набор групп)))

Вообще есть мнение, что инвентори концептуально должен быть список *тегированных* хостов, а не *сгрупированных*

Какая еще рулилка по инвентарю?

слушай, зачем я тебе цитирую твои же мессаги? ))) ты все забываешь? сам же предложил иметь два инвентаря и рулит логикой меняя инвентари.

Так набор групп на проде и стейдже один и тот же

а что мешает сделать еще группы)))

С чем вы спорите-то?

с двумя инвентарями. нафига?

В чём разница-то?

Потому что это best practice.

В том, что в текущей модели один и тот же хост надо несколько раз объявлять в разных группах Это неэффективно

о! тогда можно пойди дальше: сделать еще и два резелвера имен, чтобы не ошибаться, и два роутера)))

В том, что в текущей модели один и тот же хост надо несколько раз объявлять в разных группах Это неэффективно

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

Это не задача, а вариант решения. Какова исходная задача?

Чтобы соответствовать реальному положению дел Там и приложение, и база данных, и какие-нибудь cron-джобы Это уже три логические группы, условно: app, db, jobs

Зачем?

ну да. много буков...) а вы начните инвентарь просто генерить автоматически и НИКОГДА в него руками не залезайте, чтобы не пугаться

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

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

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

по взрослому "потому что мультитеннантность", по пацански "потому что там не одно приложение/свойство/назначение/..."