Credentials
Тема дорожной карты · Ansible
Учётные данные AWX — это безопасно хранимые объекты аутентификации, которые AWX внедряет в запуски заданий, исключая необходимость хранить пароли или приватные ключи в playbook или файлах inventory. AWX поддерживает несколько типов учётных данных из коробки — Machine (SSH-ключ + become-пароль), Vault (пароль Ansible Vault), Source Control (токен или пароль Git) и облачные учётные данные для AWS, Azure, GCP и других. Учётные данные AWX шифруются в хранилище с помощью секретного ключа конкретной установки и никогда не раскрываются операторам заданий в открытом виде, что делает их рекомендуемым способом управления секретами в командных средах с AWX. Учётные данные назначаются шаблонам заданий, а роли RBAC определяют, каким командам или пользователям разрешено использовать или изменять каждый объект учётных данных.
Как это работает
Credentials (теперь Red Hat Ansible Automation Platform / AAP) и его upstream AWX дают веб-UI + REST API поверх Ansible: scheduled jobs, RBAC, audit log, workflow-цепочки (job A → если success → job B), управление credentials, источники inventory. Гоняет Ansible-плейбуки в контейнерах (execution environments) со своими collections + зависимостями, отделённо от контроллера.
Когда применять
AWX или AAP — когда (а) больше 2-3 инженеров гоняют плейбуки (нужны RBAC + аудит), (б) хотите scheduled / triggered автоматизацию, (в) важна ChatOps / self-service интеграция. Для RF-инфры AWX self-hosted на control-VM — практичный выбор. AAP требует Red Hat-лицензии. Маленькие команды остаются с ansible-playbook из CI-раннеров.
Типичные ошибки
Ловушки Credentials: сложность деплоя AWX (Kubernetes-based, нетривиальная установка); путаница execution environment (плейбук падает не из-за кода, а из-за пинов collection в EE); утечка credentials через job output (маскируйте sensitive). Планируйте capacity — AWX любит много ядер + RAM для параллельных job.