Управление выполнением плейбука
Вы можете использовать опцию –start-at-task, чтобы определить новую точку входа вашего плейбука. Затем Ansible пропустит все, что предшествует указанной задаче, выполнив оставшуюся часть play с заданного момента. Эта опция в качестве аргумента требует правильное имя задачи:
Чтобы выполнять только задачи, связанные с конкретными тегами, вы можете использовать опцию –tags. Например, если вы хотите выполнить только задачи, помеченные как nginx или mysql, вы можете использовать:
Если вы хотите пропустить все задачи, которые находятся под определенными тегами, используйте –skip-tags. Следующая команда будет выполнять myplaybook.yml, пропуская все задачи, помеченные как mysql:
Using multiple inventory sources
You can target multiple inventory sources (directories, dynamic inventory scripts
or files supported by inventory plugins) at the same time by giving multiple inventory parameters from the command
line or by configuring . This can be useful when you want to target normally
separate environments, like staging and production, at the same time for a specific action.
Target two sources from the command line like this:
ansible-playbook get_logs.yml -i staging -i production
Keep in mind that if there are variable conflicts in the inventories, they are resolved according
to the rules described in and .
The merging order is controlled by the order of the inventory source parameters.
If in staging inventory defines , but production inventory defines ,
the playbook will be run with . The result would be reversed if the playbook was run with
.
Aggregating inventory sources with a directory
You can also create an inventory by combining multiple inventory sources and source types under a directory.
This can be useful for combining static and dynamic hosts and managing them as one inventory.
The following inventory combines an inventory plugin source, a dynamic inventory script,
and a file with static hosts:
inventory/
openstack.yml # configure inventory plugin to get hosts from Openstack cloud
dynamic-inventory.py # add additional hosts with dynamic inventory script
static-inventory # add static hosts and groups
group_vars/
all.yml # assign variables to all hosts
You can target this inventory directory simply like this:
ansible-playbook example.yml -i inventory
It can be useful to control the merging order of the inventory sources if there’s variable
conflicts or group of groups dependencies to the other inventory sources. The inventories
are merged in ASCII order according to the filenames so the result can
be controlled by adding prefixes to the files:
inventory/
01-openstack.yml # configure inventory plugin to get hosts from Openstack cloud
02-dynamic-inventory.py # add additional hosts with dynamic inventory script
03-static-inventory # add static hosts
group_vars/
all.yml # assign variables to all hosts
If defines for the group , defines ,
and defines , the playbook will be run with .
Assigning a variable to many machines: group variables
If all hosts in a group share a variable value, you can apply that variable to an entire group at once. In INI:
host1 host2 ntp_server=ntp.atlanta.example.com proxy=proxy.atlanta.example.com
In YAML:
atlanta
hosts
host1
host2
vars
ntp_server ntp.atlanta.example.com
proxy proxy.atlanta.example.com
Group variables are a convenient way to apply variables to multiple hosts at once. Before executing, however, Ansible always flattens variables, including inventory variables, to the host level. If a host is a member of multiple groups, Ansible reads variable values from all of those groups. If you assign different values to the same variable in different groups, Ansible chooses which value to use based on internal .
Файл инвентаря Ansible
Файл инвентаря содержит информацию о хостах, которыми вы будете управлять с помощью Ansible. В этот файл можно включить от одного до нескольких сотен серверов. Хосты в нем могут быть организованы в группы и подгруппы. Файл инвентаря также часто используется для установки переменных, действительных только для определенных хостов и групп, которые затем можно использовать в плейбуках и шаблонах. Некоторые переменные также могут влиять на способ запуска плейбука, например ansible_python_interpreter.
Чтобы просмотреть содержимое инвентаря Ansible по умолчанию, откройте файл /etc/ansible/hosts с помощью редактора на локальном компьютере или на Ansible Control Node:
Примечание: Некоторые установки Ansible не создают файл инвентаря по умолчанию. Если в вашей системе файл не существует, вы можете создать файл /etc/ansible/hosts самостоятельно или указать собственный путь к инвентарю с помощью параметра -i при запуске команд и плейбуков.
Файл инвентаря по умолчанию, предоставляемый установкой Ansible, содержит несколько примеров, которые вы можете использовать в качестве шаблона для настройки. В следующем примере мы определим группу из трех именованных серверов, каждый из которых идентифицируется по своему псевдониму: server1, server2 и server3.
Подгруппа server:vars устанавливает параметр хоста ansible_python_interpreter, который будет действителен для всех хостов, включенных в группу servers. Этот параметр гарантирует, что удаленный сервер использует исполняемый файл Python 3 /usr/bin/python3, а не /usr/bin/python (Python 2.7), которого нет в последних версиях Ubuntu.
Чтобы завершить настройку файла инвентаря, замените условные IP-адреса в файле IP-адресами ваших серверов. Когда вы закончите, сохраните и закройте файл (Ctrl + X, затем y, чтобы сохранить изменения, а затем Enter).
Теперь, когда ваш файл инвентаря готов, пришло время проверить подключение к вашим нодам.
Inventory basics: formats, hosts, and groups
The inventory file can be in one of many formats, depending on the inventory plugins you have.
The most common formats are INI and YAML. A basic INI might look like this:
mail.example.com foo.example.com bar.example.com one.example.com two.example.com three.example.com
The headings in brackets are group names, which are used in classifying hosts
and deciding what hosts you are controlling at what times and for what purpose.
Group names should follow the same guidelines as .
Here’s that same basic inventory file in YAML format:
all
hosts
mail.example.com
children
webservers
hosts
foo.example.com
bar.example.com
dbservers
hosts
one.example.com
two.example.com
three.example.com
There are two default groups: and . The group contains every host.
The group contains all hosts that don’t have another group aside from .
Every host will always belong to at least 2 groups ( and or and some other group). Though and are always present, they can be implicit and not appear in group listings like .
You can (and probably will) put each host in more than one group. For example a production webserver in a datacenter in Atlanta might be included in groups called and and . You can create groups that track:
-
What — An application, stack or microservice (for example, database servers, web servers, and so on).
-
Where — A datacenter or region, to talk to local DNS, storage, and so on (for example, east, west).
-
When — The development stage, to avoid testing on production resources (for example, prod, test).
Extending the previous YAML inventory to include what, when, and where would look like:
all
hosts
mail.example.com
children
webservers
hosts
foo.example.com
bar.example.com
dbservers
hosts
one.example.com
two.example.com
three.example.com
east
hosts
foo.example.com
one.example.com
two.example.com
west
hosts
bar.example.com
three.example.com
prod
hosts
foo.example.com
one.example.com
two.example.com
test
hosts
bar.example.com
three.example.com
You can see that exists in the , , and groups.
You can also use nested groups to simplify and in this inventory, for the same result:
all
hosts
mail.example.com
children
webservers
hosts
foo.example.com
bar.example.com
dbservers
hosts
one.example.com
two.example.com
three.example.com
east
hosts
foo.example.com
one.example.com
two.example.com
west
hosts
bar.example.com
three.example.com
prod
children
east
test
children
west
You can find more examples on how to organize your inventories and group your hosts in .
Advanced pattern options
The common patterns described above will meet most of your needs, but Ansible offers several other ways to define the hosts and groups you want to target.
You can use variables to enable passing group specifiers via the argument to ansible-playbook:
webservers:!{{ excluded }}:&{{ required }}
You can define a host or subset of hosts by its position in a group. For example, given the following group:
cobweb webbing weber
you can use subscripts to select individual hosts or ranges within the webservers group:
webservers # == cobweb
webservers # == weber
webservers # == webservers,webservers
# == cobweb,webbing
webservers # == webbing,weber
webservers # == cobweb,webbing,weber
How variables are merged
By default variables are merged/flattened to the specific host before a play is run. This keeps Ansible focused on the Host and Task, so groups don’t really survive outside of inventory and host matching. By default, Ansible overwrites variables including the ones defined for a group and/or host (see ). The order/precedence is (from lowest to highest):
-
all group (because it is the ‘parent’ of all other groups)
-
parent group
-
child group
-
host
By default Ansible merges groups at the same parent/child level in ASCII order, and the last group loaded overwrites the previous groups. For example, an a_group will be merged with b_group and b_group vars that match will overwrite the ones in a_group.
You can change this behavior by setting the group variable to change the merge order for groups of the same level (after the parent/child order is resolved). The larger the number, the later it will be merged, giving it higher priority. This variable defaults to if not set. For example:
a_group
vars
testvar a
ansible_group_priority 10
b_group
vars
testvar b
In this example, if both groups have the same priority, the result would normally have been , but since we are giving the a higher priority the result will be .
Ansible Vault для хранения конфиденциальных данных
Если ваши плейбуки Ansible содержат конфиденциальные данные, такие как пароли, ключи API и учетные данные, важно обеспечить их безопасность с помощью шифрования. Ansible предоставляет ansible-vault для шифрования файлов и переменных
Несмотря на то, что любой файл данных Ansible, а также двоичные файлы, возможно зашифровать изначально, чаще для шифрования переменных файлов, содержащих конфиденциальные данные, используется ansible-vault. После шифрования файла с помощью этого инструмента вы сможете выполнять, редактировать или просматривать его, только предоставив соответствующий пароль, указанный при первом шифровании файла.
Создание нового зашифрованного файла
Вы можете создать новый зашифрованный файл Ansible с помощью:
Эта команда выполнит следующие действия:
- Сначала вам будет предложено ввести новый пароль. Вам нужно будет указывать этот пароль при каждом доступе к содержимому файла, будь то редактирование, просмотр или просто запуск плейбука (или команд с использованием его значений).
- Затем откроется редактор командной строки по умолчанию, чтобы вы могли заполнить файл требуемым содержимым.
- Наконец, когда вы закончите редактирование, ansible-vault сохранит файл как зашифрованный.
Шифрование существующего файла Ansible
Чтобы зашифровать существующий файл Ansible, вы можете использовать следующую команду:
Эта команда запросит у вас пароль, который вам нужно будет вводить при каждом доступе к файлу credentials.yml.
Просмотр содержимого зашифрованного файла
Если вы хотите просмотреть содержимое файла, который ранее был зашифрован с помощью ansible-vault, и вам не нужно изменять его содержимое, вы можете использовать команду:
Она предложит вам указать пароль, который вы выбрали при первом шифровании файла с помощью ansible-vault.
Редактирование зашифрованного файла
Чтобы изменить содержимое файла, который ранее был зашифрован с помощью Ansible Vault, выполните:
Эта команда предложит вам указать пароль, который вы выбрали при первом шифровании файла credentials.yml. После проверки пароля откроется редактор командной строки по умолчанию с незашифрованным содержимым файла, что позволит вам внести нужные изменения. По завершении вы можете сохранить и закрыть файл, как обычно, и обновленное содержимое будет сохранено и зашифровано.
Расшифровка файлов
Если вы хотите навсегда расшифровать файл, ранее зашифрованный с помощью ansible-vault, вы можете сделать это с помощью следующего синтаксиса:
Эта команда предложит вам ввести тот пароль, который использовался при первом шифровании файла. После проверки пароля содержимое файла будет сохранено на диск в виде незашифрованных данных.
Как использовать этот плейбук?
Для начала мы загрузим содержимое плейбука на Ansible Control Node. Это может быть либо локальный компьютер, либо удаленный сервер, на котором установлен Ansible и настроен инвентарь.
Чтобы скачать этот плейбук с помощью командной строки, вы можете использовать curl:
Это загрузит содержимое плейбука в файл initial_server_setup.yml по вашему текущему локальному пути. Вы можете просмотреть содержимое плейбука, открыв файл в редакторе:
Открыв файл, найдите раздел vars с тремя различными переменными, которые требуют вашего внимания:
- create_user: имя учетной записи пользователя без полномочий root, для создания и предоставления привилегий sudo. В нашем примере используется 8host, но вы можете использовать другое имя пользователя.
- copy_local_key: локальный путь к действительному открытому ключу SSH, который будет использоваться в качестве авторизованного ключа для новой учетной записи sudo. Значение по умолчанию указывает на открытый ключ текущего локального пользователя, расположенный в ~/.ssh/id_rsa.pub.
- sys_packages: список основных системных пакетов, которые будут установлены с помощью менеджера пакетов apt.
Когда вы закончите обновлять переменные в initial_server_setup.yml, сохраните и закройте файл.
Теперь вы готовы запустить свой плейбук на одном или нескольких серверах. По умолчанию большинство плейбуков настроено на выполнение на всех серверах из инвентаря. Вы можете использовать флаг -l, чтобы плейбук затронул только конкретное подмножество серверов или один сервер. Чтобы выполнить плейбук только на сервере server1, вы можете использовать следующую команду:
Вы получите такой вывод:
Как только плейбук будет выполнен, вы сможете войти на сервер с помощью команды:
Не забудьте заменить 8host именем вашего пользователя из переменной create_user, а server_domain_or_IP именем хоста или IP-адресом вашего сервера.
Если вы установили открытый ключ с переменной copy_local_key, вам нужно будет указать дополнительный параметр, указывающий расположение его закрытого ключа:
После входа на сервер вы можете проверить активные правила брандмауэра UFW и убедиться, что он правильно настроен:
Вы должны получить похожий вывод:
Это означает, что брандмауэр UFW успешно включен. Это было последнее задание плейбука, а потому это подтверждает, что плейбук был полностью выполнен на этом сервере.
