У Ansible есть группа по умолчанию all
, которая, как ни странно, содержит все хосты в файле инвентаря.
Как вы можете сделать, как с любыми группами хостов, и предоставить group_vars для группы хозяев.
Как показано в предыдущей ссылке, они могут быть определены непосредственно в файле инвентаризации или могут содержаться в отдельном файле с именем после группы в каталоге group_vars
на том же уровне каталога, что и файл инвентаризации. Структура каталогов
Примером может выглядеть примерно так:
-ansible
|--inventory
| |--group_vars
| | |--all
| | |--dev
| | |--test
| | |--prod
| | |--webservers
| | |--databases
| |--dev
| |--test
| |--prod
|--roles
...
Ваш файл инвентаризации DEV может выглядеть примерно так:
[dev:children]
webservers
databases
[webservers]
web1.dev
web2.dev
[databases]
database-master.dev
database-slave.dev
Все эти хостами теперь подобрать любой хост конкретные конфигурации (которые могут быть определены либо в строке, либо как и в случае с group_vars, могут быть помещены в папку host_vars), а также config для определенных групп, в которых они находятся, например , а затем группы, на которые они также наследуются, например, dev
b ut тоже, по умолчанию, all
.
Это можно затем использовать для настройки вещей грубо, чем для каждого хоста.
Возможно, что во всех случаях могут быть определены такие типы, как серверы NTP, в то время как DNS-серверы могут быть определены на уровне среды (если ваша сеть сегментирована в dev, для тестирования и производства они могут нуждаться в разных DNS-серверах в /etc/resolv.conf
), в то время как разные типы серверов могут иметь разные конфигурации вокруг таких вещей, как списки устанавливаемых пакетов. Наконец, некоторые вещи, возможно, должны быть конкретными узлами, такими как установка идентификатора сервера MySQL в группе репликации.
Если, вместо этого, вы только хотите, чтобы определить PlayBook глобальные настройки, а не по инвентаризации (и поэтому могут быть доступны другим playbooks), то вам просто нужно vars
блок в вашем play определение следующим образом:
- hosts: webservers
vars:
http_port: 80
tasks:
- name: Task1 to be ran against all the webservers
...
Как упоминалось ранее, вы всегда можете использовать all
группу здесь:
- hosts: all
vars:
ntp_pool:
- ntp1.domain
- ntp2.domain
tasks:
- name: Task1 to be ran against all the servers
...
в общем, хотя, я бы настоятельно рекомендовал использовать роли структурировать то, что вещи побежал к определенным ч osts, а затем используя инвентарь, чтобы объяснить, какие серверы являются тем типом, а затем использовать параметр group_vars на уровне инвентаря, чтобы содержать все переменные для этих групп хостов. Ведение дел таким образом поможет вам сохранить вещи в разумных местах и позволит вам легко повторно использовать базу кода.
Я хотел иметь переменные в playbook, потому что у меня это в Git. Затем я прибегаю к обмену файлами инвентаря с переменными и должен его адаптировать. Мне нужны переменные в playbook, потому что, когда все настроено, они не меняются, но хосты в инвентаре могут. – rabejens
Способы обращения с переменными немного неудобны, но это понятно, учитывая, что он сильно зависит от неявных включений (на основе инвентаря) и невозможности легко обменивать переменные между играми. Как показывает мой пример, я прибегал к использованию модулей инвентаризации для ввода данных в инвентарные вары. Факт (см. Модуль set_fact) сохраняется во всех играх, но они основаны на каждом хосте. Имейте в виду, что вы всегда можете написать быстрый скрипт (например, python) для создания динамического инвентаря, включая vars и группировки, который выглядит точно так, как вы хотите. – Petro026
Я думал о чем-то подобном (написав сценарий, который генерирует инвентарь) сам, я думаю, что я это сделаю.Плей-лист предназначен для создания базового кластера Hadoop с поддержкой Spark/YARN, базы данных Cassandra и Zeppelin, и я могу написать сценарий, который сначала просит пользователя перечислить все хосты, а затем установить, какие хосты должны размещать какую службу. – rabejens