Триллер о настройке серверов без чудес с Configuration Management

[sysadm1989]

Мы реализовали это с помощью периодических запусков всех Ansible playbook с опцией «--check» на production-серверах.

Сколько по времени длится такой job? Запуск идет на отдельный инстанс AWX?

[JetHabr]

1. Длительность Job напрямую зависит от количества хостов в playbook и количества проверок в нем. В среднем Job отрабатывает в течение 5-10 минут. Общий цикл проверок по всем хостам конкретно в этой инсталляции укладывается в 1-1,5 часа.
2. Сейчас используется single instance AWX на виртуальном сервере. Job Slicing и тем более instance group пока не применяются – производительности single instance с базовыми настройками пока хватает.

[sysadm1989]

Общий цикл проверок по всем хостам конкретно в этой инсталляции укладывается в 1-1,5 часа.

Получается в этот промежуток нельзя создать и настроить VM, так как у вас single instance. И чем больше у вас будет VM, тем больше будет данный помежуток. Что не есть хорошо!

Mitogen вам поможет ускорить работу Ansible, но лучше уходить от одного инстанса.

[JetHabr]

В этом проекте пока все просто устроено – парк серверов не настолько большой, чтобы этот ночной тест мешал работам службы эксплуатации.
Если будут неудобства, можно и ssh pipelines включить, и mitogen в virtualenv установить, и узлов AWX добавить.
Но пока, повторюсь, – не болит)

[ardling]

С удовольствием бы почитал детали релизации инфраструктуры с описанием встреченных подводных камней и примерами конфигов.

[JetHabr]

Спасибо за готовую тему! Подумаем над ней.

[Stillgray]

Как разрешить запуск конкретных Ansible playbook только определенным сотрудникам?

Можно "ввести" сервер в домен (ms ad, freeipa или др.), при первоначальной настройке, например при помощи realmd+sssd, для linux сервера, и предоставить права подключения и администрирования для определённой группы сотрудников.
Так же необходимо включить использование gss api для sshd.

Таким образом проигрывание playbook будет завершаться с ошибкой в случае выполнения для серверов, доступ к которым отсутствует, и выполнятся под УЗ пользователя в противном случае.

Из побочных эффектов:

• отсутствие необходимости хранить секреты (точнее хранением секретов занимается kerberos),
• единый вход — подключение к консоли (и выполнения playbook) без ввода пароля,
• управление доступом в одном месте, через добавление УЗ в доменную группу,
• наличие в журналах УЗ пользователя, который запускал playbook, или выполнял команды на сервере.

Нет информации о том, можно ли использовать этот механизм с Ansible AWX/Tower, но с ansible это работает.

[JetHabr]

Anslible AWX как раз и создан для этого, (ну и не только:-)). Создаете в нем группу (Team), в нее помещаете сотрудников, выдаете на требуемый template права для этой группы.
https://docs.ansible.com/ansible-tower/latest/html/userguide/teams.html