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

если нигде в роли твоей нет

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

если очень хочется, то ансибл умеет мержить хеши, это в ansible.cfg включается. Но обычно это стремная идея

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

Фишка в том, что нужно по group_vars раскидать что и в каких группах должно быть

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

Фишка в том, что нужно по group_vars раскидать что и в каких группах должно быть

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

чот так себе автоматизация 😄

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

roles -> users: [] group_vars/server01.yml -> users: ['admin1','project1'] group_vars/server02.yml -> users: ['admin2','project2']

roles -> users: [] group_vars/server01.yml -> users: ['admin1','project1'] group_vars/server02.yml -> users: ['admin2','project2']

ммм, то есть пер-сервер, а не пер-роль?

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

Никто не запрещает group_vars/*.yml генерить тоже

ммм, то есть пер-сервер, а не пер-роль?

Пер-группа) Пер-хост - это host_vars

Никто не запрещает group_vars/*.yml генерить тоже

а есть какая-то генерилка? или самому ямлопарсер написать?

а есть какая-то генерилка? или самому ямлопарсер написать?

Плейбук просто пишешь на localhost и все. Или delegate_to: local

а есть какая-то генерилка? или самому ямлопарсер написать?

Генерить имеет смысл, если описание этих пользователей не в yaml. На основании папок с ssh ключами, например. А если можно описать в yaml, то проще просто в конфиг все положить. Зачем генерить тогда?

нене, всё в ямле описато там либо сам паблик-кей, либо ссылка на гитхаб

нене, всё в ямле описато там либо сам паблик-кей, либо ссылка на гитхаб

Тогда в чем проблема?

в ролях что-то вроде вот такого: https://gist.github.com/59a544101f10766712bfe77a229b7447

но я упёрся в то, как этот словарь заранее подготовить

но я упёрся в то, как этот словарь заранее подготовить

А как его еще можно подготовить? Только описать

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

я чот не нашёл каких-то best practices по этому поводу

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

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

делают, откуда у вас сомнения?

ну просто не нашёл никаких общеупотребляемых практик

полез колхозить, а там всё как-то небанально

если есть какие-то ссылки на сакцесс-стори, то был бы весьма признателен

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

Структура везде одинаковая

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

И описывать их всех только один раз

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

Не так давно имел приватную беседу с @freeseacher, который и сказал, что я хочу странного, и так никто не делает

Ну и собственно не нагуглились какие-то общие практики по этому вопросу

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

вы не думали использовать yaml anchors для этого? http://termbin.com/jbpx ?

но это в рамках ондого yaml документа

то есть задача в конкретизированном виде выглядит так: есть контора, которая делает всякий маркетинговый треш есть ряд админов, который довольно фиксирован есть команды разработчиков, которые меняются от проекта к проекту, а так же - пересекаются между проектами есть сервера, которые бывают выделенные для проекта, а бывают предназначены для N проектов одновременно цель задачи: завести всех админов и всех проектных юзеров на целевом сервере учитывая довольно лютую перемешанность разработчиков между проектами хочется держать список (детальный - с ключами, группами, etc) всех юзеров в каком-то строго одном месте, а в роли рассовывать только "указатели" на элементы этого списка для серверов, предназначенных для N проектов одновременно, эти списки из ролей должны как-то мержиться а админы в полном составе должны присутствовать на всех серверах

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

Да это мой поинт.

Такое вам не подходит?

вы не думали использовать yaml anchors для этого? http://termbin.com/jbpx ?

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

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

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

вы не думали использовать yaml anchors для этого? http://termbin.com/jbpx ?

тут есть пара нюансов: 1. насколько я понимаю, это можно только в рамках одного файла делать (то есть будут перемешаны "справочники" юзеров с данными о проектах) 2. не совсем понятно, как это потом в роли заносить

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

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

дане, как-раз где там ключ проверить не сложно

тут есть пара нюансов: 1. насколько я понимаю, это можно только в рамках одного файла делать (то есть будут перемешаны "справочники" юзеров с данными о проектах) 2. не совсем понятно, как это потом в роли заносить

я пока не вижу противоречий. подкладывается этот yaml (одним документом) с описанием всех пользователей и группы в которые они входят допустим в inventory/users.yaml далее в плейбуках просто использовать: user: with_items: project_name1

а админов копипастить в каждое проектное множество?

или можно как-то сложить?

можно и сложить, я могу это сделать за вас

там что-то вроде with_items: admins + project_name

вытягивать админов для проекта через json_query, например

или по-другому как-то?

вытягивать админов для проекта через json_query, например

админы не per-project, они "глобальные"

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

не обязательно, можно сделать следующим образом users: .... global_admins: &global_admins - <<: *admin1 - <<: *admin2 project_admins: <<: *global_admins - *project_admin - *project_admin2

о, можно свести копипасту к одной строчке

круто

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

ну то что эти юзеры будут в разном порядке приезжать - это же вроде не так страшно

или я что-то упускаю?

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

Все зависит от качества кода. Так же, как и в паппете

ну то что эти юзеры будут в разном порядке приезжать - это же вроде не так страшно

зависит от реализации интепретатора yaml'a.

в каком плане?

то что элементы в массиве будут отсортированы по-разному вроде бы в любом случае не страшно же

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

или я по-прежнему чего-то не понимаю?

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

а под тыквой что подразумеваете? все так пришлось за вас рабочий вариант накидать, держите http://termbin.com/jnfs

Тыква это а не вариант. Комбинаторный взрыв проектов пользователей и их прав.

а под тыквой что подразумеваете? все так пришлось за вас рабочий вариант накидать, держите http://termbin.com/jnfs

используйте https://github.com/kislyuk/yq что-бы валидировать что получилось, найдете более удобный для вас формат ну и читайте спецификацию http://yaml.org/spec/1.2/spec.html

Ребят, а как вы плэйбуки с letsencrypt тестируете? Есть --stage флаг у certbotа, но он все равно пытается провести dns проверку, а я просто на локальном окружении хочу потестить, что все хорошо работает, пусть и с фэйковыми сертификатами

—stage - это обращение к staging api со стороны letsencrypt, проверка происходит таже самая, только 1. отдается не "зеленый сертификат" 2. отсутствуют лимиты на количество запросов и сертиифатов, как раз для того что-бы не попасть под баны на prod letsencrypt'e во время множества тестирований

—stage - это обращение к staging api со стороны letsencrypt, проверка происходит таже самая, только 1. отдается не "зеленый сертификат" 2. отсутствуют лимиты на количество запросов и сертиифатов, как раз для того что-бы не попасть под баны на prod letsencrypt'e во время множества тестирований

Ну это я знаю, мне инетересно, можно ли как-то потестировать без DNS проверки, то есть чтобы с локальной виртуалки в вагранте или из докер контейнера Пока пришла в голову мысль поискать контейнер, или север, который на любой запрос от certbot на него будет отвечать, что все ок. Чтобы генерились левые сертификаты без проверки по DNS, этого бы вполне хватило

в ваших тестовых окружениях нет доступа до интернетов?

в ваших тестовых окружениях нет доступа до интернетов?

а как образы качать без инета)00

в ваших тестовых окружениях нет доступа до интернетов?

Из интернета нет доступа до моих образов =)

а как образы качать без инета)00

локальный артифактори видимо. хотя нужно как-то прокидывать внутрь http порт, или менеджить тестовую зону в dns вообщем, не до конца понятно что будет тестироваться, работоспособность самого letsencrypt или то что letsencrypt клиент вызывается с нужными параметрами. впрочем, это уже оффтопик. в k8s есть letsencrypt Issuer для докера есть letsnecrypt-companion https://github.com/JrCs/docker-letsencrypt-nginx-proxy-companion

локальный артифактори видимо. хотя нужно как-то прокидывать внутрь http порт, или менеджить тестовую зону в dns вообщем, не до конца понятно что будет тестироваться, работоспособность самого letsencrypt или то что letsencrypt клиент вызывается с нужными параметрами. впрочем, это уже оффтопик. в k8s есть letsencrypt Issuer для докера есть letsnecrypt-companion https://github.com/JrCs/docker-letsencrypt-nginx-proxy-companion

Спасибо! Сейчас посмотрю

локальный артифактори видимо. хотя нужно как-то прокидывать внутрь http порт, или менеджить тестовую зону в dns вообщем, не до конца понятно что будет тестироваться, работоспособность самого letsencrypt или то что letsencrypt клиент вызывается с нужными параметрами. впрочем, это уже оффтопик. в k8s есть letsencrypt Issuer для докера есть letsnecrypt-companion https://github.com/JrCs/docker-letsencrypt-nginx-proxy-companion

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

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

для этого существует letsencrypt-companion, если у вас ворклоады в докерах

работает прямо из коробки, вам про него расскажут в @devops_ru