Введение
Многократно используемый плейбук должен использовать данные окружения, а не жёстко задавать отдельные ответы для разработки и эксплуатации. Выбор инвентаря, область действия переменных и факты целевых узлов определяют, что получает каждый узел.
Вы используете два инвентаря, выбирающих разные узлы SSH, сохраните данные групп и хостов рядом с каждым источником и сформируете настройки одним плейбуком. Вы также примените временное переопределение дополнительной переменной и восстановите стабильное исходное состояние.
Разделите данные инвентаря по окружениям
На этом шаге вы зададите отдельные источники инвентаря и значения переменных групп для разработки и эксплуатации.
Перейдите в проект:
cd /home/labex/project
Лабораторная работа предоставляет два небольших инвентаря. Прочитайте каждый перед запуском автоматизации:
cat inventories/dev/hosts.ini
cat inventories/prod/hosts.ini
Группа app окружения dev содержит web1; группа app окружения prod содержит web2. Их адреса и настройки SSH подготовлены. Это действительно разные узлы, а не два имени localhost.
-i выбирает источник инвентаря для данного вызова, переопределяя инвентарь проекта по умолчанию. Предварительно просмотрите каждое окружение отдельно:
ansible app -i inventories/dev/hosts.ini --list-hosts
ansible app -i inventories/prod/hosts.ini --list-hosts
Ожидайте web1 для dev и web2 для prod. Не объединяйте эти два источника для имитации изолированных окружений: источники могут объединяться, а одно имя хоста инвентаря по-прежнему обозначает один хост. Явно указывайте окружение при каждом вызове.
Переменная — именованное значение, используемое автоматизацией. Отображение YAML использует строки name: value. Ansible загружает group_vars/app.yml рядом с инвентарём для его группы app. Создайте разные данные для одинакового имени группы в каждом окружении:
cat > inventories/dev/group_vars/app.yml <<'EOF'
environment_label: development
release_channel: preview
EOF
cat > inventories/prod/group_vars/app.yml <<'EOF'
environment_label: production
release_channel: stable
EOF
Изучите разрешённые данные инвентаря. --list возвращает JSON, включая объект _meta.hostvars со значениями хостов:
ansible-inventory -i inventories/dev/hosts.ini --list
ansible-inventory -i inventories/prod/hosts.ini --list
Для хоста dev должны разрешаться development/preview; для хоста prod — production/stable. Файл переменных полезен только тогда, когда нужный инвентарь и группа действительно его загружают.
Используйте переменные хостов и реальные факты
На этом шаге вы переопределите значение группы для одного хоста и сформируете реальные управляемые настройки из данных окружения.
Файл в host_vars называется по имени хоста инвентаря. Для одного хоста и ключа его переменная хоста переопределяет используемую здесь переменную группы. Задайте canary окружения разработки канал выпуска для конкретного хоста:
cat > inventories/dev/host_vars/web1.yml <<'EOF'
release_channel: canary
EOF
В окружении разработки environment_label по-прежнему равен development, но для web1 release_channel теперь разрешается как canary. Эксплуатация остаётся stable. Подтвердите разрешение dev:
ansible-inventory -i inventories/dev/hosts.ini --list
Напишите один многократно используемый плейбук для любого из инвентарей:
cat > deploy-info.yml <<'EOF'
- name: Configure environment-specific application settings
hosts: app
gather_facts: true
vars:
banner_prefix: Managed environment
tasks:
- name: Write settings from variables and facts
ansible.builtin.copy:
dest: /home/automation/app-settings.conf
content: |
[application]
environment={{ environment_label }}
channel={{ release_channel }}
host={{ inventory_hostname }}
distribution={{ ansible_facts.distribution }}
label={{ banner_prefix }}
mode: "0640"
EOF
vars определяет значение уровня play — banner_prefix. В содержимом copy {{ variable_name }} вставляет значение во время выполнения. Это простая подстановка значений; в одной из последующих лабораторных работ вы будете управлять отдельными шаблонами Jinja.
Символ YAML | сохраняет следующий текст с отступом как многострочный текст, включая завершающий перевод строки. inventory_hostname — текущее имя в инвентаре. При gather_facts true Ansible собирает данные целевого узла перед задачами; ansible_facts.distribution предоставляет настоящий дистрибутив операционной системы. Это данные целевого узла, а не факт об управляющем узле.
Проверьте синтаксис, затем выполните один плейбук отдельно для каждого окружения:
ansible-playbook -i inventories/dev/hosts.ini deploy-info.yml --syntax-check
ansible-playbook -i inventories/dev/hosts.ini deploy-info.yml
ansible-playbook -i inventories/prod/hosts.ini deploy-info.yml
Прочитайте оба настоящих файла через соответствующие инвентари:
ansible app -i inventories/dev/hosts.ini -m ansible.builtin.command -a 'cat /home/automation/app-settings.conf'
ansible app -i inventories/prod/hosts.ini -m ansible.builtin.command -a 'cat /home/automation/app-settings.conf'
Окружение разработки должно содержать environment=development, channel=canary и host=web1. Эксплуатация должна содержать environment=production, channel=stable и host=web2. Оба должны содержать distribution=Ubuntu и label=Managed environment. Общий плейбук создал разное содержимое на целевых узлах, используя разные данные.
Переопределите один вызов и восстановите исходное состояние
На этом шаге вы используете дополнительную переменную без редактирования сохранённых данных инвентаря, затем вернётесь к достигнутому исходному состоянию.
-e передаёт дополнительную переменную для данного выполнения. Она переопределяет показанные здесь значения группы и хоста. Временно выберите канал hotfix только для разработки:
ansible-playbook -i inventories/dev/hosts.ini deploy-info.yml -e release_channel=hotfix
Прочитайте полученную конфигурацию dev:
ansible app -i inventories/dev/hosts.ini -m ansible.builtin.command -a 'cat /home/automation/app-settings.conf'
Её канал должен быть hotfix. Исходные файлы group_vars и host_vars не редактировались параметром -e, а эксплуатация не была выбрана.
Запустите без дополнительной переменной, чтобы восстановить сохранённый канал canary хоста web1:
ansible-playbook -i inventories/dev/hosts.ini deploy-info.yml
Теперь предварительно проверьте исходное состояние обоих окружений:
ansible-playbook -i inventories/dev/hosts.ini deploy-info.yml --check
ansible-playbook -i inventories/prod/hosts.ini deploy-info.yml --check
Каждый выбранный хост должен сообщать ноль ожидающих изменений и отсутствие сбоев или недоступных результатов. Ограниченный набор отношений приоритета, отработанный здесь, — данные группы, переопределение хоста и переопределение дополнительной переменной. Более сложные правила приоритета находятся вне этого упражнения.
Резюме
Вы выбрали отдельные инвентари окружений, загрузили данные групп, применили переопределение конкретного хоста и сформировали содержимое с реальными фактами целевых узлов общим плейбуком. Временная дополнительная переменная изменила один вызов, а последующие запуски без переопределений вернули оба окружения к стабильным объявленным настройкам.
