Комментарии 7
Внимание: если вы работаете с несколькими идентичными средами с одной управляющей машины (blue/green развертывания, stage/prod), убедитесь, что не выстрелите себе в ногу! Если, к примеру, вы сначала скачали актуальные настройки с прода и следующим шагом хотите обновить тестовую среду новой версией компонентов, а SSH-сокеты остались открытыми от прода, то ой… Так что нужно либо делать ControlPath у этих сред разный, либо принудительно закрывать мастер-сессии или удалять сокеты перед началом работы с другой средой.
Просто используйте разные сокеты, например ControlPath ~/.ssh/master-%r@%h:%p.
Верно, я и обратил внимание на это: делать ControlPath у этих сред разный.
В проектах, где для разных сред хосты называются идентично (workerN, dbN, и т.д.), а отличаются лишь IP-адреса bastion-хостов, через которые пробрасываются ssh-подключения – имена сокетов по шаблону ~/.ssh/master-%r@%h:%p как раз не зависят от рабочей среды и инженер может попасть в описанную ситуацию! В таком случае правильнее в inventory для конкретной среды указывать шаблоны с разными префиксами (например, ~/.ssh/prod-%r@%h:%p). Либо (по аналогии с virtual env) делать разное окружения для запуска Ansible – выставлять ANSIBLE_SSH_CONTROL_PATH и выводить значение текущего окружения в prompt – меньше вероятности, что инженер запустит плейбуки не на тех серверах.
А в данном случае для профилирования profile_roles и profile_tasks callback'и не подходят?
Callback'и для профилирования скорее нужны для задач поиска узких мест. Мне для теста нужно было общее время + примитивная агрегация между повторными запусками. Для callback'ов (там есть общее время выполнения) все равно пришлось бы делать агрегацию – решил воспользоваться готовой реализацией для стандартной утилиты time. Для хардкорного профилирования (когда нужно отличать, где именно тормозит – в модуле, в соединении или во внутренностях ansible) можно использовать ANSIBLE_DEBUG=1 – тогда весь низкоуровневый вывод маркируется временнЫми штампами.
Может ли Ansible вкладывать одни модули в другие модули?
PreferredAuthentications захардкожено, добавление его в опции ничего не меняет
https://github.com/ansible/ansible/blob/0830b6905996fb02eefcba79a9b055961e251078/lib/ansible/plugins/connection/ssh.py#LL740C1-L740C105
Спасибо за хорошую статью, актуально через 9 лет :)
Вопрос: а не пробовали избавиться от sudo? Ведь довольно громоздкая штука, которая на каждый чих парсит конфиги (с поддеревом conf.d), зовёт pam, пишет в лог строчку для аудита, совершенно бесполезную, т.к. там только имена временных файлов с кодом на Питоне.
Кажется, будет быстрее, если заменить sudo на какой-от минимальный самопальный бинарь с suid, который просто проверяет, что этот пользователь, например, входит в группу ansible. А если разрешить PermitRootLogin и завести отдельного пользователя ansible с uid=0 и домашним каталогом, в котором есть какой надо .ssh/authorized_keys, то вообще можно сразу зайдя на машину Ansible творить все нужные бесчинства.
Безопасность такая же: зашедший по ключу на хост пользователь, который может делать sudo без пароля, может столько же, сколько вошедший сразу под uid=0.
Неужели никто так не делает?
Ускоряем работу Ansible