Ansible переменные extra-vars. lesson 9

Переменные словаря

Словарь хранит данные в парах ключ-значение.Обычно словари используются для хранения сопутствующих данных,таких как информация,содержащаяся в идентификаторе или профиле пользователя.

Определение переменных как словари key:value

Более сложные переменные можно определить с помощью словарей YAML.Словарь YAML сопоставляет ключи к значениям.Например:

foo:
  field1: one
  field2: two

Ключ ссылки:переменные словаря значений

Когда вы используете переменные,определяемые как словарь key:value (также называемый хэшем),вы можете использовать отдельные,специфические поля из этого словаря,используя либо нотацию в скобках,либо точечную нотацию:

foo
foo.field1

Оба этих примера ссылаются на одно и то же значение («один»). Обозначение скобок всегда работает. Точечная запись может вызвать проблемы, потому что некоторые ключи конфликтуют с атрибутами и методами словарей Python. Используйте скобки, если вы используете ключи, которые начинаются и заканчиваются двумя символами подчеркивания (которые зарезервированы для специальных значений в python) или являются одними из известных общедоступных атрибутов:

, , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , значения , .

Connecting to hosts: behavioral inventory parameters

As described above, setting the following variables control how Ansible interacts with remote hosts.

Host connection:

Note

Ansible does not expose a channel to allow communication between the user and the ssh process to accept a password manually to decrypt an ssh key when using the ssh connection plugin (which is the default). The use of is highly recommended.

ansible_connection

Connection type to the host. This can be the name of any of ansible’s connection plugins. SSH protocol types are , or . The default is smart. Non-SSH based types are described in the next section.

General for all connections:

ansible_host

The name of the host to connect to, if different from the alias you wish to give to it.

ansible_port

The connection port number, if not the default (22 for ssh)

ansible_user

The user name to use when connecting to the host

ansible_password

The password to use to authenticate to the host (never store this variable in plain text; always use a vault. See )

Specific to the SSH connection:

ansible_ssh_private_key_file

Private key file used by ssh. Useful if using multiple keys and you don’t want to use SSH agent.

ansible_ssh_common_args

This setting is always appended to the default command line for sftp, scp,
and ssh. Useful to configure a for a certain host (or
group).

ansible_sftp_extra_args

This setting is always appended to the default sftp command line.

ansible_scp_extra_args

This setting is always appended to the default scp command line.

ansible_ssh_extra_args

This setting is always appended to the default ssh command line.

ansible_ssh_pipelining

Determines whether or not to use SSH pipelining. This can override the setting in .

ansible_ssh_executable (added in version 2.2)

This setting overrides the default behavior to use the system ssh. This can override the setting in .

Privilege escalation (see for further details):

ansible_become

Equivalent to or , allows to force privilege escalation

ansible_become_method

Allows to set privilege escalation method

ansible_become_user

Equivalent to or , allows to set the user you become through privilege escalation

ansible_become_password

Equivalent to or , allows you to set the privilege escalation password (never store this variable in plain text; always use a vault. See )

ansible_become_exe

Equivalent to or , allows you to set the executable for the escalation method selected

ansible_become_flags

Equivalent to or , allows you to set the flags passed to the selected escalation method. This can be also set globally in in the option

Remote host environment parameters:

ansible_shell_type

The shell type of the target system. You should not use this setting unless you have set the
to a non-Bourne (sh) compatible shell. By default commands are
formatted using -style syntax. Setting this to or will cause commands
executed on target systems to follow those shell’s syntax instead.

ansible_python_interpreter

The target host python path. This is useful for systems with more
than one Python or not located at /usr/bin/python such as *BSD, or where /usr/bin/python
is not a 2.X series Python. We do not use the /usr/bin/env mechanism as that requires the remote user’s
path to be set right and also assumes the python executable is named python, where the executable might
be named something like python2.6.

ansible_*_interpreter

Works for anything such as ruby or perl and works just like .
This replaces shebang of modules which will run on that host.

New in version 2.1.

ansible_shell_executable

This sets the shell the ansible controller will use on the target machine,
overrides in which defaults to
/bin/sh. You should really only change it if is not possible
to use /bin/sh (in other words, if /bin/sh is not installed on the target
machine or cannot be run from sudo.).

Examples from an Ansible-INI host file:

some_host         ansible_port=2222     ansible_user=manager
aws_host          ansible_ssh_private_key_file=/home/example/.ssh/aws.pem
freebsd_host      ansible_python_interpreter=/usr/local/bin/python
ruby_module_host  ansible_ruby_interpreter=/usr/bin/ruby.1.9.3

Специальные теги:всегда и никогда

Ansible reserves two tag names for special behavior: always and never. If you assign the tag to a task or play, Ansible will always run that task or play, unless you specifically skip it ( ).

Например:

tasks:
- name: Print a message
  ansible.builtin.debug:
    msg: "Always runs"
  tags:
  - always

- name: Print a message
  ansible.builtin.debug:
    msg: "runs when you use tag1"
  tags:
  - tag1

Warning

Сбор фактов по умолчанию помечен тегом «всегда». Он пропускается, только если вы применяете тег, а затем используете другой тег в —tags или тот же тег в —skip-tags .

Warning

Задача проверки спецификации аргумента роли по умолчанию помечена тегом «всегда». Эта проверка будет пропущена, если вы —skip-tags always используете —skip-tags .

Новинка в версии 2.5.

Если вы назначите тег задаче или игре, Ansible пропустит эту задачу или воспроизведение, если вы специально этого не запросите ( ).

Например:

tasks:
  - name: Run the rarely-used debug task
    ansible.builtin.debug:
     msg: '` showmevar `'
    tags: 

Редко используемая задача отладки в приведенном выше примере запускается только тогда, когда вы специально запрашиваете теги или .

Comparing loop and with_*

• The keywords rely on — even is a lookup.

• The keyword is equivalent to , and is the best choice for simple loops.

• The keyword will not accept a string as input, see .

• Generally speaking, any use of covered in can be updated to use .

• Be careful when changing to , as performed implicit single-level flattening. You may need to use with to match the exact outcome. For example, to get the same output as:

  

  

  

  

  

  

  

  

  

  

with_items
  - 1
  - 2,3
  - 4

you would need

loop "{{ 1, 2, 3], 4 | flatten(1) }}"

Any with_* statement that requires using lookup within a loop should not be converted to use the loop keyword. For example, instead of doing:

loop "{{ lookup('fileglob', '*.txt', wantlist=True) }}"

it’s cleaner to keep

Создание плейбука

Создаем файл для playbook:

vi /etc/ansible/play.yml

—
— hosts: redhat-servers
  become:
    true
  become_method:
    su
  become_user:
    root
  remote_user:
    ansible
  roles:
   — epel
   — nginx
— hosts: debian-servers
  become:
    true
  become_method:
    sudo
  become_user:
    root
  remote_user:
    ansible
  roles:
   — nginx

* где:

• — — начало файла YAML. Данный формат имеет строгую структуру  — важен каждый пробел; 
• hosts — группа хостов, к которым будут применяться правила плейбука (если мы хотим, чтобы правила применялись ко всем хостам, указываем hosts: all); 
• become — указывает на необходимость эскалации привилегий; 
• become_method — метод эскалации привилегий; 
• become_user — пользователь под которым мы заходим с помощью become_method; 
• remote_user — пользователь, под которым будем подключаться к удаленным серверам; 
• roles — список ролей, которые будут применяться для плейбука.

* В данном случае мы задействуем нашу группы хостов, которые создали в самом начале; повышаем привилегии методом su под пользователем root (su — root) для группы redhat-servers и методом sudo для debian-servers; подключение к серверам выполняется от пользователя ansible; используем созданную нами роль nginx (саму роль мы создадим позже). Для систем RPM сначала выполним роль epel — она будет отвечать за установку репозитория EPEL, так как в стандартном репозитории nginx нет.

Стоит отдельно уделить внимание вопросу повышения привилегий. IT-среды могут применять разные политики относительно безопасности

Например, на серверах CentOS, по умолчанию, нет sudo и повышать привилегии нужно с помощью su. В Ubuntu наоборот — по умолчанию есть sudo, а su не работает, так как пароль на root не устанавливается. В данном случае есть несколько путей при работе с Ansible:

1. Как в нашем примере, разделить группы хостов на разные семейства операционных систем и применять к ним разные методы повышения привилегий. Чтобы данный плейбук корректно отработал, учетная запись, под которой идет удаленное подключение к серверу (в нашем примере ansible) должна иметь такой же пароль, как у пользователей root на серверах семейства Red Hat. Данный метод удобен с точки зрения отсутствия необходимости приводить к единому виду безопасность серверов разного семейства. Однако, с точки зрения безопасности лучше, чтобы пароли у root и ansible были разные.
2. Использовать метод для создания плейбука, как описан выше, но запускать его с ключом —limit, например, ansible-playbook —limit=debian-servers … — таким образом, мы запустим отдельные задания для каждого семейства операционных систем и сможем ввести индивидуальные пароли для каждого случая.
3. Мы можем на всех серверах deb установить пароль для пользователя root, таким образом, получив возможность для become_method: su.
4. И наконец, можно для серверов Red Hat установить sudo и проходить become с помощью метода sudo.

Где установить переменные

Вы можете определять переменные в различных местах, например, в инвентаре, в сборниках игр, в повторно используемых файлах, в ролях и в командной строке. Ansible загружает все возможные переменные, которые он находит, затем выбирает переменную для применения на основе .

Определение переменных в инвентаризации

Вы можете определить разные переменные для каждого отдельного хоста или установить общие переменные для группы хостов в вашем инвентаре. Например, если все машины в группе используют boston.ntp.example.com в качестве сервера NTP, вы можете установить переменную группы. На странице « есть подробные сведения о настройке и в инвентаре.

Определение переменных в пьесе

Вы можете определить переменные непосредственно в playbook play:

- hosts: webservers
  vars:
    http_port: 80

Когда вы определяете переменные в пьесе,они видны только задачам,выполняемым в этой пьесе.

Определение переменных в включаемых файлах и ролях

Вы можете определять переменные в файлах многоразовых переменных и / или в многоразовых ролях. Когда вы определяете переменные в повторно используемых файлах переменных, чувствительные переменные отделяются от playbooks. Такое разделение позволяет хранить свои плейбуки в программном обеспечении контроля версий и даже делиться плейбуками без риска раскрытия паролей или других конфиденциальных и личных данных. Для получения информации о создании повторно используемых файлов и ролей см. .

Этот пример показывает,как можно включить переменные,определенные во внешнем файле:

---

- hosts: all
  remote_user: root
  vars:
    favcolor: blue
  vars_files:
    - /vars/external_vars.yml

  tasks:

  - name: This is just a placeholder
    ansible.builtin.command: /bin/echo foo

Содержимое каждого файла переменных представляет собой простой YAML словарь.Например:

---

somevar: somevalue
password: magic

Note

Вы можете хранить переменные для каждого хоста и для группы в аналогичных файлах. Чтобы узнать об организации переменных, см. .

Определение переменных во время выполнения

Вы можете определять переменные при запуске своей playbook, передавая переменные в командной строке с помощью (или ). Вы также можете запросить ввод пользователя с помощью (см. ). Когда вы передаете переменные в командной строке, используйте одну строку в кавычках, содержащую одну или несколько переменных, в одном из форматов ниже.

формат ключ=значение

Значения, переданные с использованием синтаксиса , интерпретируются как строки. Используйте формат JSON, если вам нужно передать нестроковые значения, такие как логические значения, целые числа, числа с плавающей запятой, списки и т. Д.

ansible-playbook release.yml --extra-vars "version=1.23.45 other_variable=foo"

JSON-строковый формат

ansible-playbook release.yml --extra-vars '{"version":"1.23.45","other_variable":"foo"}'
ansible-playbook arcade.yml --extra-vars '{"pacman":"mrs","ghosts":}'

При передаче переменных с помощью необходимо экранировать кавычки и другие специальные символы как для разметки (например, JSON), так и для оболочки:

ansible-playbook arcade.yml --extra-vars "{\"name\":\"Conan O\'Brien\"}"
ansible-playbook arcade.yml --extra-vars '{"name":"Conan O'\\\''Brien"}'
ansible-playbook script.yml --extra-vars "{\"dialog\":\"He said \\\"I just can\'t get enough of those single and double-quotes"\!"\\\"\"}"

Если у вас много специальных символов,используйте JSON или YAML файл,содержащий определения переменных.

Разное

В данном разделе будет рассказано о дополнительных опциях, которые позволяют менять поведение выполнения задач, добавляет функциональности или все то, для чего не найдена отдельная подходящая категория.

1. Шифрование строки.

С помощью ansible-vault мы можем шифровать файлы и папки. Это позволит нам хранить секреты не в открытом виде. Данные расшифровываются в момент выполнения задач.

Данной командой мы получаем шифрованную строку:

ansible-vault encrypt_string

Система запросит ввести дважды пароль и предложит ввести строку, которую нужно зашифровать. После мы должны нажать 2 раза Ctrl + D — мы получим строку, которая начинается с !Vault и различные символы. 

Для того, чтобы в момент выполнения задачи ansible расшифровал данные, при запуске плейбука мы должны указать ключ —ask-vault-pass:

ansible-playbook … —ask-vault-pass

Об ansible-vault: https://docs.ansible.com/ansible/latest/user_guide/vault.html.

2. Игнорировать ошибки.

Если ansible столкнется с ошибкой при выполнении задачи, работа плейбука будет завершена. Иногда, нужно пропустить ошибку при выполнении определенной задачи, чтобы выполнение было продолжено. Для этого существует опция ignore.

а) чтобы пропустить ошибки выполнения, в настройка задачи используем:

— name: Bad Task
  …
  ignore_errors: yes 

б чтобы игнорировать ошибки при подключении к хосту:

— name: Bad Task
  …
  ignore_unreachable: yes 

3. Начинать выполнение с определенной задачи.

При выполнении отладки, полезно запустить плейбук, но начать выполнение с определенной задачи. Остальные пропустить. 

Это можно сделать с помощью опции —start-at-task:

ansible-playbook … —start-at-task=»Start Job»

* в данном примере плейбук начнет выполнять задания с задачи Start Job.

4. Завершить выполнение плейбука после определенной задачи.

С помощью данной конструкции:

— meta: end_play

5. Зависимые роли.

С помощью файла meta/main.yml в роли мы можем определить пред-роль, от которой зависит выполнение текущей роли. Для этого настраивается опция dependencies:

dependencies:
  — role: pred

6. Вставка роли и ее задач.

Позволяет в процессе выполнения задачи подключить роль. Делается при помощи include_role:

— name: «Include Other Role»
  include_role:
    name: other_role

А это пример, как подключить роль и сделать так, чтобы все ее задачи выполнились на определенном хосте:

— name: «Include Other Role»
  include_role:
    name: other_role
    apply:
      delegate_to: «` deploy_vm`.`instance`.`ipv4 `»

7. Повторы при выполнении задачи.

Мы можем управлять цикличностью выполнения задач с помощью retries (количиство повторов), delay (задержка в секундах).

Рассмотрим пример повтора выполнения задачи при возникновении ошибки:

— name: Run anything command
  command: /foo/bar/cmd
  register: result
  retries: 3
  delay: 60
  until: result is not failed

* в данном примере мы будем выполнять команду /foo/bar/cmd пока ее выполнение не закончится без ошибок. Количество повторов будет равен 3 с интервалом в 60 секунд.

Небольшой пример на странице .

8. Резервное копирование базы данных MySQL/MariaDB.

Работа с базой данных возможно с помощью коллекции mysql.mysql_db. Она не идет в комплекте к ansible и нам необходимо ее установить командой:

ansible-galaxy collection install community.mysql

Резервное копирование можно выполнить так:

— name: Dump mysql databases
  community.mysql.mysql_db:
    state: dump
    name:
      — db1
      — db2
    target: /tmp/dump.sql

* в данном примере мы создадим 2 дампа из баз db1 и db2 и сохраним результат в файл /tmp/dump.sql.

О mysql_db: https://docs.ansible.com/ansible/latest/collections/community/mysql/mysql_db_module.html.

9. Объединение задач в блоки.

Это позволит установить общие свойства и условие для нескольких задач. Такая форма записи уменьшит количиство строк и упростит восприятие.

Синтаксис записи:

— name: Block Name
  block:
     — name: Task 1
       …
     — name: Task 2
       …
     — name: Task 3
       …
  when: ansible_facts == ‘CentOS’
  become: true
  become_user: root
  ignore_errors: yes

* в данном примере будет выполнены 3 задачи, если выполнится одно условие, которое описывается не для задач, а для блока.

О block: https://docs.ansible.com/ansible/latest/user_guide/playbooks_blocks.html.

10. Перебор массива.

Предположим, нам нужно перебрать все элементы массива в шаблоне. Это можно сделать конструкцией:

{% for host in my_hosts %}
server «` host `»
{% endfor %}

* в данном примере мы сделаем перебор по переменной my_hosts. Для каждого элемента массива будет создана строка со значением server <значение переменной>.

Переменные регистрации

Вы можете создавать переменные из вывода задачи Ansible с помощью ключевого слова задачи . Вы можете использовать зарегистрированные переменные в любых последующих задачах вашей игры. Например:

- hosts: web_servers

  tasks:

     - name: Run a shell command and register its output as a variable
       ansible.builtin.shell: /usr/bin/foo
       register: foo_result
       ignore_errors: true

     - name: Run a shell command using output of the previous task
       ansible.builtin.shell: /usr/bin/bar
       when: foo_result.rc == 5

For more examples of using registered variables in conditions on later tasks, see . Registered variables may be simple variables, list variables, dictionary variables, or complex nested data structures. The documentation for each module includes a section describing the return values for that module. To see the values for a particular task, run your playbook with .

Зарегистрированные переменные хранятся в памяти.Вы не можете кэшировать зарегистрированные переменные для использования в будущих воспроизведениях.Зарегистрированные переменные действительны только на хосте в течение оставшейся части текущего проигрывания.

Зарегистрированные переменные — это переменные уровня хоста. Когда вы регистрируете переменную в задаче с циклом, зарегистрированная переменная содержит значение для каждого элемента в цикле. Структура данных, помещенная в переменную во время цикла, будет содержать атрибут , то есть список всех ответов от модуля. Более подробный пример того, как это работает, см. В разделе « » об использовании регистра с циклом.

Note

Если задача не выполняется или пропускается, Ansible по-прежнему регистрирует переменную с ошибкой или пропущенным статусом, если только задача не пропущена на основе тегов. См. Раздел для получения информации о добавлении и использовании тегов.

Background

I have been learning and heavily refactoring a playbook and role for some time. Initially I tested by specifying tags, but continued refactoring and testing just by limiting specific test hosts to run the plays against. Now that I’ve converted the main playbook and role to use and statements I found that I am also affected by the bug noted here and on : the tasks with tags specified within included role/tasks file no longer run when I specify a tag at the command-line (e.g., )

I encountered this with Ansible 2.7.1, but updated to 2.7.2 and confirmed that the issue is still present.

I’ve attempted to strip the playbook/role down to the essentials, but still clearly convey the intent.

Обновление сертификата

Так как большинство современных сервисов требуют для своей работы сертификат, рассмотрим пример централизованного их обновления. 

Предположим, что у нас есть сертификат wildcard и необходимо его копировать на все серверы компании. Если серверов много, делать это вручную при очередном его обновлении неудобно.

И так, создаем новую роль:

ansible-galaxy init Update_Certs

Открываем на редактирование файл с заданиями:

vi Update_Certs/tasks/main.yml

—
— name: Register System Services
  service_facts:
  register: services_state
— name: Create Directories For Certs
  file:
    path: ‘/etc/ssl/dmoks’
    state: directory
    owner: root
    group: root
    mode: 0755
— name: Copy Cert File If Different
  copy:
    src: «` item `»
    dest: /etc/ssl/dmosk
    remote_src: no
    mode: 0644
    owner: root
    group: root
  with_fileglob:
    — files/*
  notify:
    — reload httpd
    — reload nginx
    — reload apache2

* будут выполняться следующие задачи:

• Register System Services — получаем список всех служб, которые работают на целевом компьютере
• Create Directories For Certs — создаем каталог /etc/ssl/dmoks, в который будем копировать сертификаты
• Copy Cert File If Different — копируем сертификаты в целевой каталог. Если были изменения в любом из файлов, по очереди запускаем 3 задачи в handlers для перезагрузки сервисов. Здесь нам нужно самостоятельно перечислить все службы, которые вам нужно перезагружать.

Открываем на редактирование файл в каталоге handlers:

vi Update_Certs/handlers/main.yml

Добавим строки: 

—
— name: reload httpd
  systemd:
    name: httpd
    state: restarted
  when:
    services_state.ansible_facts.services.state == ‘running’
  ignore_errors: yes
— name: reload nginx
  systemd:
    name: nginx
    state: restarted
  when:
    services_state.ansible_facts.services.state == ‘running’
  ignore_errors: yes
— name: reload apache2
  systemd:
    name: apache2
    state: restarted
  when:
    services_state.ansible_facts.services.state == ‘running’
  ignore_errors: yes

* в задачах, в случае изменения сертификатов, мы выполняем задания reload httpd, reload nginx и reload apache2. Все задания описаны в данном файле. В данном примере мы проверяем, что сервисы запущены и если это так, перезапускаем их. Нам необходимо перезапускать все службы, которые используют сертификаты (в противном случае, обновленные сертификаты не будут использоваться). При необходимости дописать службы, делаем это по аналогии.

В каталог Update_Certs/files/ помещаем наши сертификаты — все содержимое данного каталога будет копироваться на целевые компьютеры в каталог /etc/ssl/dmosk.

Создаем файл для плейбука:

vi start_role.yml

—
— hosts: test_servers
  user: dmosk
  become: true
  become_method: su
  become_user: root
  roles:
    — Update_Certs

* в данном примере мы запускаем выполнение роли Update_Certs на серверы из группы test_servers.

Запускаем созданный плейбук:

ansible-playbook start_role.yml -kK

Registering variables with a loop

You can register the output of a loop as a variable. For example

- name Register loop output as a variable
  ansible.builtin.shell "echo{{ item }}"
  loop
    - "one"
    - "two"
  register echo

When you use with a loop, the data structure placed in the variable will contain a attribute that is a list of all responses from the module. This differs from the data structure returned when using without a loop.

{
    "changed" true,
    "msg" "All items completed",
    "results" 
        {
            "changed" true,
            "cmd" "echo \"one\" ",
            "delta" "0:00:00.003110",
            "end" "2013-12-19 12:00:05.187153",
            "invocation" {
                "module_args" "echo \"one\"",
                "module_name" "shell"
            },
            "item" "one",
            "rc" ,
            "start" "2013-12-19 12:00:05.184043",
            "stderr" "",
            "stdout" "one"
        },
        {
            "changed" true,
            "cmd" "echo \"two\" ",
            "delta" "0:00:00.002920",
            "end" "2013-12-19 12:00:05.245502",
            "invocation" {
                "module_args" "echo \"two\"",
                "module_name" "shell"
            },
            "item" "two",
            "rc" ,
            "start" "2013-12-19 12:00:05.242582",
            "stderr" "",
            "stdout" "two"
        }
    
}

Subsequent loops over the registered variable to inspect the results may look like

- name Fail if return code is not 0
  ansible.builtin.fail
    msg "Thecommand({{ item.cmd }})didnothaveareturncode"
  when item.rc != 0
  loop "{{ echo.results }}"

During iteration, the result of the current item will be placed in the variable.

Introduction¶

While it is possible to write a playbook in one very large file (and you might start out learning playbooks this way),
eventually you’ll want to reuse files and start to organize things.

At a basic level, including task files allows you to break up bits of
configuration policy into smaller files. Task includes pull in tasks from other
files. Since handlers are tasks too, you can also include handler files from
the ‘handler’ section.

See Playbooks if you need a review of these concepts.

Playbooks can also include plays from other playbook files. When that is done, the plays will be inserted into the playbook to form
a longer list of plays.

When you start to think about it – tasks, handlers, variables, and so on – begin to form larger concepts. You start to think about modeling
what something is, rather than how to make something look like something. It’s no longer “apply this handful of THINGS to these hosts”, you say “these hosts are dbservers” or “these hosts are webservers”. In programming, we might call that “encapsulating” how things work. For instance,
you can drive a car without knowing how the engine works.

Roles in Ansible build on the idea of include files and combine them to form clean, reusable abstractions – they allow you to focus
more on the big picture and only dive down into the details when needed.

We’ll start with understanding includes so roles make more sense, but our ultimate goal should be understanding roles – roles
are great and you should use them every time you write playbooks.

Часть 3: Захват вывода с помощью регистров в Ansible

Некоторые задачи не отображают никаких результатов при запуске playbook. Например, выполнение команд на ваших управляемых узлах с использованием команд , оболочки или необработанных модулей не будет отображать никаких выходных данных при запуске playbook.

Вы можете использовать регистр для захвата вывода задачи и сохранения его в переменной. Это позволяет вам использовать вывод задачи в другом месте книги, просто обращаясь к зарегистрированной переменной.

Следующий файл register-playbook.yml показывает вам, как записать вывод задачи в зарегистрированной переменной, а затем отобразить его содержимое:

$ cat register-playbook.yml 
--- 
- name: Register Playbook
  hosts: proxy
  tasks:
    - name: Run a command
      command: uptime
      register: server_uptime

    - name: Inspect the server_uptime variable
      debug:
        var: server_uptime

    - name: Show the server uptime
      debug:
        msg: "` server_uptime`.`stdout `"

Playbook запускается с выполнения команды uptime на хостах группы прокси (node1) и регистрирует выходные данные команды в переменной server_uptime.

Затем вы используете модуль отладки вместе с параметром var module для проверки переменной server_uptime. Обратите внимание, что здесь не нужно заключать переменную в фигурные скобки. Наконец, последняя задача в playbook показывает вывод (stdout) зарегистрированной переменной server_uptime

Наконец, последняя задача в playbook показывает вывод (stdout) зарегистрированной переменной server_uptime.

Запустите playbook, чтобы увидеть все это в действии:

$ ansible-playbook register-playbook.yml 

PLAY  **********************************************

TASK  *********************************************************
ok: 

TASK  ***********************************************************
changed: 

TASK  **************************************
ok:  => {
    "server_uptime": {
        "changed": true,
        "cmd": ,
        "delta": "0:00:00.004221",
        "end": "2020-10-29 05:04:36.646712",
        "failed": false,
        "rc": 0,
        "start": "2020-10-29 05:04:36.642491",
        "stderr": "",
        "stderr_lines": [],
        "stdout": " 05:04:36 up 3 days,  6:56,  1 user,  load average: 0.24, 0.07, 0.02",
        "stdout_lines": 
    }
}

TASK  **************************************************
ok:  => {
    "msg": " 05:04:36 up 3 days,  6:56,  1 user,  load average: 0.24, 0.07, 0.02"
}

PLAY RECAP *********************************************************************
node1                      : ok=4    changed=1    unreachable=0    failed=0    skipped=0    rescued=0    ignored=0

Обратите внимание, что зарегистрированная переменная server_uptime на самом деле является словарем, содержащим множество других ключей помимо ключа stdout. Она также содержит другие ключи, такие как rc (код возврата), start (время выполнения команды), end (время завершения команды), stderr (любые ошибки) и т

д.