ansible.cfg и базовые настройки

Зачем вообще нужен ansible.cfg

Без конфига каждую команду приходится обвешивать флагами:

ansible all -i ./inventory.ini -u deploy --private-key ~/.ssh/id_rsa -b ...

Это неудобно и ломается при смене окружения. ansible.cfg позволяет вынести все повторяющиеся параметры в один файл и забыть про флаги.

Порядок поиска конфига

Ansible ищет конфиг в таком порядке и берёт первый найденный:

1. Переменная окружения ANSIBLE_CONFIG — путь к файлу.
2. ./ansible.cfg в текущем рабочем каталоге.
3. ~/.ansible.cfg в домашней директории.
4. /etc/ansible/ansible.cfg — системный дефолт.

Файлы не сливаются. Нашёл первый — остальные игнорируются целиком. Это не как ssh_config, где Include складываются.

Поэтому если ты запускаешь ansible-playbook из /srv/project/, а там лежит ansible.cfg — именно он и будет использоваться, даже если в домашней директории есть другой.

Безопасность: если текущий каталог доступен на запись всем (world-writable), Ansible намеренно игнорирует ./ansible.cfg и пишет предупреждение. Это защита от подмены конфига в shared-директориях.

Формат файла

Стандартный ini-формат, секция [defaults]:

[defaults]
inventory         = ./inventory.ini
remote_user       = deploy
private_key_file  = ~/.ssh/id_rsa
host_key_checking = False
forks             = 10

[privilege_escalation]
become       = True
become_method = sudo
become_user  = root

Комментарии начинаются с # или ;. Пробелы вокруг = допустимы.

host_key_checking = False

Это один из самых часто встречаемых параметров. Разберём, что именно он делает.

По умолчанию SSH при первом подключении к хосту спрашивает:

The authenticity of host '10.0.0.5' can't be established.
Are you sure you want to continue connecting (yes/no)?

В автоматизации никто не нажмёт yes — прогон зависнет. host_key_checking = False отключает эту проверку, и подключение проходит без вопросов.

Trade-off честно: это удобно в dev-окружениях и в динамических облаках, где IP меняются и known_hosts устаревает быстрее, чем успеваешь обновить. Но это снижает защиту от MITM: если между тобой и хостом окажется чужой сервер с поддельным ключом — ты его не заметишь.

В продакшен лучше предзаполнять ~/.ssh/known_hosts через ssh-keyscan при провижнинге хоста, а не отключать проверку совсем.

Тот же эффект через переменную окружения:

ANSIBLE_HOST_KEY_CHECKING=False ansible-playbook site.yml

Переменная окружения переопределяет конфиг, это бывает удобно в CI.

remote_user и ключи

[defaults]
remote_user      = deploy
private_key_file = ~/.ssh/deploy_ed25519

remote_user — от какого пользователя Ansible логинится на managed node. private_key_file — какой ключ использовать.

Если ключ один и совпадает с дефолтным (~/.ssh/id_rsa), private_key_file можно не указывать.

SSH-агент тоже работает — если ключ добавлен через ssh-add, Ansible подхватит его автоматически без явного private_key_file.

become: повышение прав

Большинство задач на хосте требуют sudo. Настройки — в секции [privilege_escalation]:

[privilege_escalation]
become        = True
become_method = sudo
become_user   = root

become = True включает sudo для всех задач по умолчанию. become_method — механизм (sudo, su, doas, pbrun; sudo — дефолт). become_user — от какого пользователя выполнять задачи после эскалации.

На уровне плея или задачи можно переопределить:

- name: install nginx
  hosts: webservers
  become: yes          # <-- можно здесь, даже если в cfg отключено
  tasks:
    - name: create log directory
      file:
        path: /var/log/myapp
        state: directory
      become: no       # <-- или отключить для конкретной задачи

Минимальный рабочий ansible.cfg

Вот конфиг, которого хватает для большинства проектов:

[defaults]
inventory         = ./inventory.ini
remote_user       = deploy
host_key_checking = False
forks             = 10

[privilege_escalation]
become        = True
become_method = sudo
become_user   = root

Положи этот файл в корень проекта рядом с inventory.ini и ansible-playbook подхватит его автоматически.

Как проверить, какой конфиг подхвачен

# Показывает путь к конфигу и все параметры с их источником
ansible --version

# Показывает только те параметры, которые отличаются от дефолтов
ansible-config dump --only-changed

ansible --version выведет строку вида:

  config file = /srv/project/ansible.cfg

Это самый быстрый способ убедиться, что берётся нужный файл, а не какой-то залётный из домашней директории.

Что важно запомнить

Порядок поиска: ANSIBLE_CONFIG -> ./ansible.cfg -> ~/.ansible.cfg -> /etc/ansible/ansible.cfg. Файлы не сливаются, берётся первый найденный.

host_key_checking = False — удобно в dev и CI, но снижает защиту от MITM. В проде лучше предзаполнять known_hosts.

become = True в [privilege_escalation] включает sudo глобально; на уровне задачи или плея можно переопределить.

ansible --version и ansible-config dump --only-changed сразу покажут, что именно подхвачено.

В следующем уроке разберём, как запускать Ansible на хостах без Python.