Одну работу на всех машинах группы Ansible делает одной командой — без файлов с описанием.
Разовая команда устроена так: ansible <машины> -m <модуль> -a '<аргументы>'. Машины — имя, группа или all; модуль — вид работы; аргументы — что именно сделать:
Модуль command запускает программу и возвращает её вывод. Модуль copy приводит файл к описанию: путь — dest, содержимое — content. Запусти copy дважды и прочитай файл через command.
Запусти copy дважды
В ~/ansible-lab дважды положи на машины группы web файл /home/student/note.txt модулем copy, затем прочитай его модулем command.
Сначала предположи
Третья команда только читает файл. Какой статус Ansible напишет у app1?
Теперь начни упражнение, выполни команду и сверь прогноз с выводом.
После каждой команды Ansible пишет статус машины. CHANGED — модуль что-то изменил. SUCCESS с "changed": false — всё уже было как надо. copy сравнивает файл с описанием: во второй раз файл совпал, и модуль его не тронул. command не знает, что делает запущенная программа, поэтому отвечает CHANGED всегда — даже на cat.
Свойство «повторный запуск не меняет то, что уже в нужном состоянии» называют идемпотентностью. На нём держится работа с Ansible: описание применяют сколько угодно раз, а ответ показывает, где машина отличалась.
На машинах группы web нужен файл /home/student/app.env со строкой MODE=prod, и повторный запуск должен показывать, что менять нечего. Какую разовую команду выберешь?
-
Файл получится, но command не сравнивает результат и при каждом запуске отвечает
CHANGED— по ответу не понять, отличалась ли машина. -
Файл одинаковый, а ответы разные: command пишет
CHANGEDвсегда, copy —SUCCESS, если файл уже такой. Повтор с-m copyэто покажет.
copy сравнивает файл с описанием и меняет его, только если они расходятся, поэтому повтор отвечает SUCCESS с "changed": false. command запускает программу и о результате не судит — его ответ CHANGED при каждом запуске.