Введение
Ansible может быть установлен правильно, но использовать неверный инвентарь, интерпретатор или привилегии. Надёжный проект явно задаёт эти параметры и подтверждает их действие на настоящих целевых узлах.
В этой лабораторной работе вы создадите конфигурацию проекта, изучите загруженные значения, зададите Python целевых узлов через инвентарь и сравните обычное выполнение с явным повышением привилегий на двух подготовленных узлах SSH. Это независимое окружение предоставляет Ansible и соединения; установка пакетов и изменения сервера SSH не требуются.
Создайте и загрузите конфигурацию проекта
На этом шаге вы создадите конфигурацию проекта и убедитесь, что Ansible действительно её загружает.
Вы уже установили Ansible в предыдущей лабораторной работе. Это независимое окружение предоставляет общую установку курса, чтобы вы могли сосредоточиться на конфигурации. Откройте терминал и выберите рабочий каталог:
cd /home/labex/project
Ansible использует один файл конфигурации, выбирая первый доступный из ANSIBLE_CONFIG, ansible.cfg текущего каталога, конфигурации в домашнем каталоге пользователя и системной конфигурации. Поэтому смена каталога может изменить загружаемую конфигурацию проекта. Переменная окружения может выбрать другой файл, даже если файл проекта существует.
Подготовленный connection-reference.cfg содержит исходные параметры учебного соединения. Команда cat выводит его:
cat connection-reference.cfg
Он выбирает инвентарь проекта и файл доверенных ключей хостов. Ключи и узлы уже созданы в лабораторной работе; не меняйте вход на платформу и сервер SSH.
Создайте показанный ниже ansible.cfg. cat > записывает стандартный ввод в файл, заменяя существующее содержимое. <<'EOF' начинает here-document: вставьте все строки до завершающего EOF включительно. Кавычки вокруг маркера сохраняют текст буквально. Имена секций INI в квадратных скобках группируют настройки, а каждая строка name = value задаёт параметр.
cat > ansible.cfg <<'EOF'
[defaults]
inventory = /home/labex/project/inventory.ini
host_key_checking = True
interpreter_python = /usr/bin/python3
[privilege_escalation]
become = False
[ssh_connection]
ssh_args = -o UserKnownHostsFile=/home/labex/.local/share/ansible-course/known_hosts -o StrictHostKeyChecking=yes -o ControlMaster=auto -o ControlPersist=30s
EOF
inventory выбирает список хостов. host_key_checking сохраняет проверку подлинности сервера включённой. interpreter_python задаёт Python целевого узла по умолчанию, а не интерпретатор управляющего узла. become = False сохраняет обычные задачи непривилегированными. Подготовленный ssh_args использует учебный файл known_hosts, требует доверенных ключей и повторно использует кратковременные соединения SSH.
Выведите сведения о версии и конфигурации:
ansible --version
Найдите config file = /home/labex/project/ansible.cfg. В этой лабораторной работе путь модуля относится к общей установке курса; в предыдущем упражнении по установке использовалось отдельное окружение учащегося.
ansible-config dump показывает действующую конфигурацию. --only-changed ограничивает вывод настройками, отличающимися от значений по умолчанию, и указывает источник каждой из них:
ansible-config dump --only-changed
Найдите CONFIG_FILE() = /home/labex/project/ansible.cfg, DEFAULT_HOST_LIST проекта и INTERPRETER_PYTHON со значением /usr/bin/python3. В выводе используются внутренние имена параметров, которые могут отличаться от написания в INI. Одно лишь чтение файла не подтверждает, что Ansible его загрузил.
Проверьте конфигурацию проекта с помощью уже знакомого модуля Python ping:
ansible all -m ansible.builtin.ping
И web1, и web2 должны вернуть pong. Продолжайте выполнять команды в этом рабочем каталоге, чтобы нужная конфигурация оставалась активной.
Задайте интерпретатор целевых узлов в инвентаре
На этом шаге вы зададите переменную соединения для обоих хостов и разберётесь, как она связана со значением проекта по умолчанию.
Прочитайте подготовленный инвентарь:
cat inventory.ini
В нём указаны два разных адреса назначения ansible_host, за которыми следует [all:vars]. Настройки после этой секции применяются к обоим хостам, включая ansible_user=automation и путь учебного закрытого ключа. Они описывают учётную запись SSH и аутентификацию на управляемых узлах.
Переменная соединения ansible_python_interpreter переопределяет значение конфигурации по умолчанию interpreter_python для своих хостов. Используйте её, когда инвентарю нужен определённый интерпретатор целевого узла. Правильное значение по умолчанию не поможет, если переменная инвентаря указывает на отсутствующий исполняемый файл.
printf выводит текст; \n означает перевод строки. >> дописывает содержимое, не заменяя существующий инвентарь. Добавьте переменную интерпретатора в существующую секцию [all:vars]:
printf '\nansible_python_interpreter=/usr/bin/python3\n' >> inventory.ini
Снова выведите инвентарь и найдите новую настройку под [all:vars]:
cat inventory.ini
Установка Python управляющего узла остаётся без изменений. Этот путь будет выполняться отдельно внутри каждого управляемого узла. Проверьте оба целевых узла:
ansible all -m ansible.builtin.ping
Каждый по-прежнему должен вернуть pong и changed: false. Теперь у вас есть рабочая настройка интерпретатора для инвентаря наряду со значением проекта по умолчанию. Вывод конфигурации описывает значения по умолчанию; переменные соединения могут переопределять их при выполнении.
Сравните обычное выполнение и выполнение с повышенными привилегиями
На этом шаге вы увидите фактического удалённого пользователя до и после явного повышения привилегий.
Модуль command запускает программу на целевом узле. -a передаёт аргументы модуля; заключите id -un в кавычки, чтобы оболочка передала программу и её параметр одной строкой аргументов. id -un выводит имя действующего пользователя:
ansible all -m ansible.builtin.command -a 'id -un'
Оба хоста должны сообщить automation. Это учётная запись управляемого узла, выбранная инвентарём, а не пользователь labex управляющего узла.
--become запрашивает повышение привилегий для данного вызова. Учебные узлы позволяют учётной записи automation использовать sudo без пароля; значение проекта по умолчанию по-прежнему отключает повышение привилегий для обычных запусков:
ansible all -m ansible.builtin.command -a 'id -un' --become
Оба хоста должны сообщить root. Модуль command Ansible обычно сообщает CHANGED, когда запускает команду, даже для этого запроса идентификации, который только читает данные. Сама метка не подтверждает изменения системной конфигурации; учитывайте фактический stdout и статус возврата.
Повторите без --become:
ansible all -m ansible.builtin.command -a 'id -un'
Вывод снова станет automation. Повышение привилегий было явно задано для одного вызова, а не являлось постоянным изменением учётной записи входа. Оставьте глобальное повышение привилегий отключённым и не меняйте конфигурацию учётных записей платформы.
Резюме
Вы создали и загрузили конфигурацию проекта, изучили действующие значения по умолчанию и задали интерпретатор целевых узлов с более высоким приоритетом через инвентарь. Настоящее выполнение модулей по SSH подтвердило работу обоих целевых узлов, а запросы идентификации показали различие между обычным доступом automation и явным become. Эти проверки дают основу для диагностики параметров соединения без изменения доступа к платформе.
