Введение
Разовая команда Ansible может обследовать парк серверов или применить небольшое явно заданное состояние конфигурации. Правильный выбор модуля упрощает понимание его поведения и возвращаемых результатов.
Вы обследуете два целевых узла Linux, подготовите управляемый каталог и распространите исходный файл управляющего узла. Вы сравните выполнение команд с модулями, сообщающими, требовало ли запрошенное состояние реального изменения. Инвентарь и соединения SSH уже подготовлены.
Обследуйте группу хостов с помощью модулей
На этом шаге вы выберете разовые модули Ansible для обследования двух подготовленных управляемых узлов.
Откройте терминал и выберите рабочий каталог:
cd /home/labex/project
Команда ad hoc запускает один модуль непосредственно на выбранных хостах инвентаря без плейбука. Её основная форма — ansible PATTERN -m MODULE -a ARGUMENTS. Лабораторная работа предоставляет группу webservers, содержащую оба целевых узла SSH. Предварительно просмотрите эту группу:
ansible webservers --list-hosts
Ожидайте ровно web1 и web2. Используйте модуль command из предыдущей лабораторной работы для запуска uname -s, который выводит имя ядра операционной системы:
ansible webservers -m ansible.builtin.command -a 'uname -s'
Каждый хост должен вывести Linux. Модуль command обычно сообщает CHANGED даже для запроса, который только читает данные. Изучите stdout и статус возврата, не интерпретируя эту метку как изменение конфигурации.
Модуль setup собирает факты — структурированную информацию, обнаруженную на управляемом узле. Аргумент модуля filter сужает возвращаемые факты. Проверьте название дистрибутива:
ansible webservers -m ansible.builtin.setup -a 'filter=ansible_distribution'
Каждый успешный результат должен включать объект ansible_facts, содержащий "ansible_distribution": "Ubuntu". При таком обследовании setup обычно сообщает changed: false. Факты описывают целевой узел, а не управляющий; в последующих лабораторных работах они будут использоваться в автоматизации.
Ненулевой результат задачи означает сбой, а UNREACHABLE указывает на проблему соединения. Для двух ожидаемых хостов нужны два успешных результата. Не путайте пустой выбор с завершённым обследованием.
Объявите управляемый каталог
На этом шаге вы используете модуль, ориентированный на состояние, чтобы подготовить одинаковый каталог на обоих целевых узлах.
Модуль file управляет состоянием файловой системы. Его path обозначает целевой путь, а state=directory запрашивает каталог вместо пустого файла. mode=0750 даёт владельцу полный доступ, группе — чтение и доступ к содержимому каталога, а остальным — никаких прав. Начальный ноль обозначает восьмеричное значение прав.
Обычные задачи выполняются от подготовленной учётной записи automation. Создайте каталог внутри домашнего каталога этого пользователя, чтобы become не требовался:
ansible webservers -m ansible.builtin.file -a 'path=/home/automation/ops state=directory mode=0750'
Оба хоста должны сообщить changed: true при первом создании каталога с полем path или dest, указывающим /home/automation/ops. Каталог принадлежит automation, поскольку эта учётная запись его создаёт.
Выполните то же объявление ещё раз:
ansible webservers -m ansible.builtin.file -a 'path=/home/automation/ops state=directory mode=0750'
Теперь ожидайте changed: false на обоих хостах: запрошенное состояние уже существует. Это отличается от повторного выполнения общей команды вроде touch, которая по-прежнему может обновлять временные метки.
Скопируйте файл управляющего узла на оба целевых узла
На этом шаге вы создадите небольшой исходный файл управляющего узла и развернёте его точное содержимое с явно заданными правами на целевых узлах.
printf записывает текст с завершающим переводом строки; > создаёт или заменяет исходный файл в текущем проекте. Формат в кавычках сохраняет сообщение вместе, а \n запрашивает перевод строки:
printf 'Managed by Ansible\n' > message.txt
Модуль copy переносит исходный файл управляющего узла в управляемое место назначения. src находится на управляющем узле, а dest — на каждом целевом узле. Для обычного файла mode=0640 даёт владельцу чтение и запись, группе — чтение, а остальным — никаких прав:
ansible webservers -m ansible.builtin.copy -a 'src=/home/labex/project/message.txt dest=/home/automation/ops/message.txt mode=0640'
Каждый целевой узел должен сообщить changed: true при первоначальном копировании. Выполните тот же перенос ещё раз:
ansible webservers -m ansible.builtin.copy -a 'src=/home/labex/project/message.txt dest=/home/automation/ops/message.txt mode=0640'
Ожидайте changed: false, когда байты и запрошенные права уже совпадают. Модуль file подготовил родительский каталог; копирование файла не заменяет этот шаг создания каталога.
Прочитайте фактическое удалённое содержимое с помощью модуля command:
ansible webservers -m ansible.builtin.command -a 'cat /home/automation/ops/message.txt'
Оба результата stdout должны показывать Managed by Ansible. Запрос command может сообщать CHANGED, но предыдущий результат changed:false модуля copy описывает уже соответствующий требованиям управляемый файл. Ваш исходный файл управляющего узла остаётся отдельным от обеих удалённых копий.
Резюме
Вы запустили модули ad hoc на настоящей группе из двух хостов, интерпретировали вывод command и получили факты о дистрибутиве. Вы объявили каталог, скопировали отдельный исходный файл управляющего узла с явными правами и наблюдали результаты без изменений, когда модули, ориентированные на состояние, обнаружили соответствующее состояние при повторном запуске.
