Настройка ansible.cfg и параметров проекта по умолчанию

AnsibleBeginner
Практиковаться сейчас

Введение

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

В этой лабораторной работе вы создадите небольшой проект, напишете ansible.cfg, определите параметры инвентаря по умолчанию, добавите общие переменные и выполните свои первые проверки Ansible из директории проекта.

Создание минимального проекта и инвентаря

На этом этапе вы создадите директории и файл инвентаря, необходимые для конфигурации Ansible на уровне проекта. Эта лабораторная работа начинается с чистой виртуальной машины, поэтому вы создадите только те файлы, которые необходимы.

Создайте структуру проекта.

cd /home/labex/project
mkdir -p rhce-ansible/{inventory,group_vars,playbooks}

В этой лабораторной работе проект намеренно остается небольшим. В inventory будет храниться список управляемых хостов, в group_vars — переменные, которые Ansible загружает автоматически, а playbooks зарезервирована для будущих файлов автоматизации.

Перейдите в директорию проекта.

cd rhce-ansible

Создайте инвентарь с одним локальным управляемым хостом.

cat > inventory/hosts <<'EOF'
[managed]
node1 ansible_connection=local
EOF

Имя хоста node1 — это псевдоним в инвентаре, а не отдельная виртуальная машина. Настройка ansible_connection=local заставляет Ansible запускать модули на этой же системе RHEL, позволяя при этом практиковаться в таргетировании групп.

Написание ansible.cfg для проекта

На этом этапе вы создадите файл ansible.cfg. Секция [defaults] управляет общим поведением. Настройка inventory означает, что вам не нужно вводить -i inventory/hosts для каждой команды.

Перед выполнением команд на этом этапе вернитесь в директорию проекта, чтобы относительные пути указывали на проект Ansible.

cd /home/labex/project/rhce-ansible

Запишите конфигурационный файл.

cat > ansible.cfg <<'EOF'
[defaults]
inventory = ./inventory/hosts
remote_user = labex
host_key_checking = False
retry_files_enabled = False
interpreter_python = auto_silent
stdout_callback = default
EOF

Каждая настройка избавляет от необходимости повторять выбор в командной строке. inventory указывает на статический файл инвентаря, remote_user задает пользователя для входа по умолчанию, host_key_checking = False позволяет избежать запросов SSH-ключей хоста в лабораторных средах, а interpreter_python = auto_silent позволяет Ansible выбирать Python без вывода назойливых предупреждений об обнаружении.

Узнайте у Ansible, какой конфигурационный файл он использует.

ansible --version | sed -n '1,4p'

Вывод должен содержать строку config file = /home/labex/project/rhce-ansible/ansible.cfg.

Это важная привычка: если Ansible считывает другой конфигурационный файл, последующие команды могут использовать другой инвентарь, callback или параметры подключения, отличные от ожидаемых в лабораторной работе.

Проверка инвентаря через параметры проекта по умолчанию

На этом этапе вы проверите, действительно ли ansible.cfg указывает Ansible на ваш инвентарь. Поскольку путь к инвентарю настроен, этой команде не требуется опция -i.

Перед выполнением команд на этом этапе вернитесь в директорию проекта.

cd /home/labex/project/rhce-ansible

Отобразите граф инвентаря.

ansible-inventory --graph

Граф должен показать группу managed и хост node1.

Просмотр графа полезен перед выполнением команд, так как он показывает инвентарь после того, как Ansible его проанализировал. Если группа или хост здесь отсутствуют, цель плейбука также не сможет их найти.

Выведите переменные хоста для node1.

ansible-inventory --host node1

Вы должны увидеть, что ansible_connection установлено в значение local.

Представление хоста показывает разрешенные переменные хоста, а не просто необработанную строку инвентаря. В последующих лабораторных работах эта же команда будет использоваться для устранения неполадок, чтобы понять, откуда пришли переменные: из инвентаря, group_vars или host_vars.

Добавление общих переменных

На этом этапе вы добавите переменные для всех управляемых хостов. Файлы в group_vars загружаются автоматически, когда их имена совпадают с группами инвентаря или all.

Перед выполнением команд на этом этапе вернитесь в директорию проекта.

cd /home/labex/project/rhce-ansible

Создайте group_vars/all.yml. YAML использует пары key: value. Оставляйте пробел после каждого двоеточия.

cat > group_vars/all.yml <<'EOF'
project_owner: labex
baseline_message: Managed by the RHCE Ansible prep project
EOF

Имя файла all.yml имеет особое значение: Ansible применяет его к каждому хосту инвентаря. Поскольку это YAML, отступы и пробел после каждого двоеточия являются частью синтаксиса, делающего файл корректным.

Используйте модуль debug, чтобы вывести одну переменную с управляемого хоста.

ansible managed -m ansible.builtin.debug -a 'var=baseline_message'

Вывод должен содержать сообщение из group_vars/all.yml.

Специальная (ad hoc) команда состоит из трех частей: managed — это шаблон хоста, -m выбирает модуль, а -a передает аргументы модуля. Успешный результат доказывает, что настроенный инвентарь и загрузка переменных работают корректно.

Выполнение проверки подключения

На этом этапе вы запустите модуль ping. Это не ICMP ping; это модуль Ansible, который проверяет, может ли Ansible выполнить Python на целевом хосте.

Перед выполнением команд на этом этапе вернитесь в директорию проекта.

cd /home/labex/project/rhce-ansible

Запустите проверку для группы managed.

ansible managed -m ansible.builtin.ping

Успешный результат включает pong.

Модуль ping в Ansible — это тест выполнения модуля, а не сетевой ICMP ping. Он доказывает, что Ansible может связаться с хостом, запустить Python и вернуть результат работы модуля.

Сохраните небольшой проверочный файл с помощью специальной команды. Модуль copy записывает содержимое в целевой путь.

ansible managed -m ansible.builtin.copy -a 'content=ansible_cfg_ready dest=/home/labex/project/rhce-ansible/config-check.txt mode=0644'

Когда эта команда сообщает changed, это означает, что Ansible создал или обновил файл. Если вы запустите её снова с тем же содержимым и правами доступа, результат должен стать ok, так как желаемое состояние уже существует.

Резюме

Вы создали файл ansible.cfg на уровне проекта, подтвердили, что Ansible загружает настроенный инвентарь, добавили общие переменные и выполнили проверки с помощью специальных модулей. В последующих лабораторных работах вы будете развивать эту воспроизводимую конфигурацию проекта.