Где Ansible ищет ansible.cfg и какой приоритет
Главное, что надо понять про конфигурацию Ansible: файлов конфигурации может быть несколько, но рабочим становится РОВНО ОДИН. Ansible не сливает их между собой и не докидывает недостающие параметры из соседнего файла. Он идёт по списку мест сверху вниз, берёт ПЕРВЫЙ найденный ansible.cfg и на этом останавливается. Все остальные игнорируются полностью.
Порядок поиска ansible.cfg такой:
- ANSIBLE_CONFIG - если задана эта переменная окружения, берётся файл по указанному в ней пути. Высший приоритет, перебивает всё.
- ./ansible.cfg - файл в текущем каталоге, откуда ты запускаешь ansible. Это и есть локальный конфиг проекта.
- ~/.ansible.cfg - файл в домашнем каталоге пользователя.
- /etc/ansible/ansible.cfg - системный, общий для всех. Кладётся пакетом, по умолчанию почти пустой.
Код: Выделить всё
$ ansible --version
ansible [core 2.16.x]
config file = /home/devops/project/ansible.cfg
...
Ключевые параметры ansible.cfg, которые реально нужны
Файл ansible.cfg - это обычный INI: секции в квадратных скобках и пары ключ = значение. Базовая настройка Ansible живёт в секции [defaults], повышение привилегий - в [privilege_escalation]. Разберём то, что встречается каждый день.
Код: Выделить всё
[defaults]
inventory = ./inventory
remote_user = devops
host_key_checking = False
forks = 20
roles_path = ./roles
collections_path = ./collections
[privilege_escalation]
become = True
become_method = sudo
become_user = root
become_ask_pass = False
- inventory - путь к файлу или каталогу инвентаря. Задал один раз - и больше не пишешь -i в каждой команде.
- remote_user - под каким пользователем подключаться к управляемым хостам по SSH. По умолчанию берётся текущий локальный пользователь, что часто не то, что нужно.
- host_key_checking - проверка SSH-ключа хоста. На свежих хостах, которых нет в known_hosts, проверка вешает плейбук на интерактивном вопросе "yes/no". В лабе и на тестовых стендах ставят False. В проде - думай головой, это снижение безопасности.
- forks - сколько хостов Ansible обрабатывает параллельно. По умолчанию 5, что мало для большого инвентаря. 20-50 ускоряет прогон в разы.
- roles_path - где искать роли, помимо стандартного ./roles. Можно перечислять через двоеточие.
- collections_path - где искать установленные коллекции (модули вроде ansible.posix или community.general живут именно в коллекциях).
- become - включить повышение привилегий по умолчанию. Аналог sudo для всех задач, где явно не сказано иначе.
Как посмотреть всю конфигурацию: ansible-config dump и list
Руками сверять десятки параметров - путь в никуда. Для этого есть отдельная утилита ansible-config, и на экзамене она экономит время не хуже самого конфига.
Код: Выделить всё
# полный список всех параметров с описанием и значениями по умолчанию
$ ansible-config list
# текущие действующие значения (с учётом твоего ansible.cfg и переменных)
$ ansible-config dump
# только то, что ОТЛИЧАЕТСЯ от значений по умолчанию - самое полезное
$ ansible-config dump --only-changed
Переменные окружения ANSIBLE_ и общий приоритет
Почти у каждого параметра ansible.cfg есть зеркальная переменная окружения с префиксом ANSIBLE_. Это удобно для CI/CD и для разовых запусков, когда лезть в файл не хочется.
Код: Выделить всё
$ export ANSIBLE_INVENTORY=./inventory
$ export ANSIBLE_REMOTE_USER=devops
$ export ANSIBLE_HOST_KEY_CHECKING=False
$ ansible all -m ansible.builtin.ping
- значения по умолчанию, зашитые в ansible-core;
- параметры из того ansible.cfg, который победил в поиске;
- переменные окружения ANSIBLE_*;
- флаги командной строки (-u, --become, -i, -f и так далее) - перебивают всё.
Типичные грабли
- Конфиг в мире-для-всех каталоге не читается. Если каталог доступен на запись посторонним (классика - /tmp или каталог с правами 0777), Ansible из соображений безопасности откажется грузить ./ansible.cfg и просто молча проигнорирует его. В ansible --version увидишь, что config file = None или указывает на /etc/ansible. Лечится правами на каталог проекта (например 0755) и владельцем-тобой.
- Несколько файлов и сюрприз с приоритетом. Есть ~/.ansible.cfg с одними настройками и ./ansible.cfg с другими - победит локальный, и параметры из домашнего НЕ доедут. Файлы не складываются. Всегда держи полный набор нужных параметров в одном файле.
- Забытая переменная окружения. Кто-то в .bashrc прописал export ANSIBLE_REMOTE_USER=root, а ты потом полдня не понимаешь, почему подключение идёт не под тем юзером. ansible-config dump --only-changed покажет источник env.
- Параметр не в той секции. become = True, положенный в [defaults] вместо [privilege_escalation], в современных версиях ansible-core обычно ещё подхватывается, но это не по правилам и сбивает с толку. Держи become-параметры в своей секции.
- Опечатка в имени параметра. Ansible не ругается на неизвестные ключи в ansible.cfg - он их тихо пропускает. Написал host_key_check вместо host_key_checking - параметр просто не сработает, и ошибки не будет. Сверяйся через ansible-config list.
Повтори на любой машине с установленным ansible-core (на RHEL/Fedora ставится через dnf install ansible-core; на Ubuntu/Debian - apt install ansible; в RED OS и Astra тоже есть в репозиториях):
- Создай каталог проекта, например ~/ansible-lab, и зайди в него.
- Запусти ansible --version и посмотри, какой config file сейчас активен (скорее всего системный или None).
- Создай в каталоге файл ansible.cfg с секцией [defaults], пропиши inventory = ./inventory, remote_user = твой_юзер, host_key_checking = False, forks = 15.
- Снова запусти ansible --version и убедись, что config file теперь указывает на твой локальный файл.
- Выполни ansible-config dump --only-changed и найди в выводе свои значения вместе с пометкой источника.
- Экспортируй export ANSIBLE_FORKS=30, снова сделай dump --only-changed и убедись, что forks теперь приходит из env, а не из файла - так ты увидишь приоритет своими глазами.
- Сними переменную (unset ANSIBLE_FORKS) и проверь, что значение вернулось к файловому.
Связь с экзаменом RHCE (EX294)
На экзамене RHEL 9 (EX294, ansible-core свежей ветки, запуск часто через ansible-navigator с execution environment) тебе НЕ дают готовую удобную конфигурацию. Первое, что делает грамотный сдающий, - заходит в свой рабочий каталог и создаёт там ansible.cfg, где сразу прописаны inventory, remote_user и become. После этого все последующие задания запускаются простым ansible-navigator run playbook.yml без вороха флагов, и ты не теряешь время и баллы на ручном указании инвентаря в каждой команде. Это маленькая привычка, которая на длинной дистанции экзамена реально экономит минуты.
Контрольные вопросы
- В каком порядке Ansible ищет ansible.cfg и сколько файлов в итоге применяется?
- Что сильнее: remote_user в ansible.cfg, переменная ANSIBLE_REMOTE_USER или флаг -u в команде? Почему именно такой порядок?
- Какой командой быстро увидеть только изменённые относительно дефолта параметры и их источник?
- Почему Ansible может молча проигнорировать ./ansible.cfg, и как это починить?
Конфигурация Ansible - это один победивший файл, а не сумма всех. Порядок поиска: ANSIBLE_CONFIG, затем ./ansible.cfg, затем ~/.ansible.cfg, затем /etc/ansible/ansible.cfg - первый найденный выигрывает. Поверх файла всё перебивают переменные ANSIBLE_*, а поверх них - флаги командной строки. Держи локальный ansible.cfg в каталоге проекта, проверяй активный файл через ansible --version, а действующие значения - через ansible-config dump --only-changed. Сделаешь это привычкой - и настройка Ansible перестанет быть источником сюрпризов и в работе, и на RHCE.
