Ответ
В моей практике я предпочитаю хранить сложные и переиспользуемые роли в отдельных репозиториях, а в проекте подключать их через requirements.yml.
Плюсы такого подхода:
- Централизованное управление и версионирование: У роли есть собственная история изменений, теги релизов. Можно обновить роль в одном месте, и все проекты получат обновление, указав новую версию в зависимостях.
- Повторное использование: Одну и ту же роль (например,
nginx,postgresql,prometheus) можно использовать в десятках проектов без копирования кода. - Независимое тестирование: Для роли можно настроить отдельный CI/CD пайплайн (например, с Molecule и Testinfra), который будет проверять ее на разных ОС и сценариях.
- Четкое разделение ответственности: Разные команды могут разрабатывать и поддерживать свои роли.
Минусы и сложности:
- Управление зависимостями: Проект теперь зависит от внешних репозиториев. Нужно следить за доступностью этих репозиториев и версиями.
- Сложность отладки: Когда проблема возникает в проекте, иногда сложнее отладить код, который находится во внешней роли. Приходится клонировать репозиторий роли и проверять его отдельно.
- Накладные расходы: Для простых, одноразовых ролей создание отдельного репозитория — избыточно. В таких случаях я держу роль внутри папки
roles/проекта.
Пример requirements.yml для подключения ролей из Git:
roles:
- src: https://github.com/geerlingguy/ansible-role-nginx
version: "4.1.0"
name: nginx_role
- src: git@internal-git.company.com:infra/postgres-role.git
scm: git
version: "main"
name: postgresql