Подтвердить что ты не робот

Можно ли определить переменные playbook-global в Ansible?

У меня есть большой Ansible playbook, где изображения Docker создаются при его запуске. Я использую все большее число в качестве тега для их версии. В настоящее время я должен указать это в каждом разделе hosts:.

Я знаю, что есть глобальные переменные, но из того, что я нашел, ища "доступные" "глобальные переменные", они должны определяться вне игровой книги. Можно ли определить глобальные переменные, которые являются глобальными для учебника?

4b9b3361

Ответ 1

Если используемый тег/версия применим ко всем хостам, использование group_vars/all является жизнеспособным вариантом.

Если номера версий специфичны для каждой записи хоста в файле host_vars/host_name, это может быть лучше.

Если вы хотите читать и начинать var, а затем увеличивать его после каждой игры, становится немного сложнее сохранить эту информацию во всех играх (или каждый -hosts, как вы говорите) в playbook. Например, если вы хотите развернуть N экземпляров docker, вы можете сделать магию динамического инвентаря следующим образом:

- hosts: localhost
  tasks:
  - add_host: name=docker_{{item}} groups="dockers,other" tag={{item}}
    with_sequence: start={{ext_def_start}} count={{ext_def_num}}


- hosts: dockers
  tasks:
  - debug: var=tag

Ответ 2

У 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 для определенных групп, в которых они находятся, например webservers, а затем группы, на которые они также наследуются, например, dev, но также по умолчанию all.

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

Такие вещи, как серверы NTP, могут быть определены во всех, в то время как DNS-серверы могут быть определены на уровне среды (если ваша сеть сегментирована в dev, тестировать и производить, для них могут потребоваться разные настройки DNS-серверов в /etc/resolv.conf), в то время как разные типы серверов могут иметь разные конфигурации вокруг таких вещей, как списки устанавливаемых пакетов. Наконец, некоторые вещи, возможно, должны быть конкретными узлами, такими как установка идентификатора сервера MySQL в группе репликации.

Если вместо этого вы хотите определить только глобальные настройки воспроизведения, а не через инвентарь (и к ним могут быть доступны другие проигрыватели), вам просто нужен блок 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
      ...

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

Ответ 3

Да, глобальные вары возможны, например,

программа для создания плейлинов с образцами

splunk/
   setup_splunk_playbook.yaml
   roles/base
           /tasks/main.yaml
           /tasks/install.yaml
         search_head
           /tasks/configure.yaml
         indexer
           /tasks/configure.yaml
         some_other_role
           /tasks/some_task.yaml
   hosts
   config.yaml

Поместите свои vars в config.yaml

cat splunk/config.yaml

--- 
# global Splunk variables
splunk_version: 7.0.0

в вашей книге воспроизведения, включите роли

cat setup_splunk_playbook.yaml

- hosts: "search_heads"  
  become_user: root
  become: true
  gather_facts: true

  roles:
    - base
    - search_head

в вашей роли, включите Глобальные Vars внутри задачи

роли cat/base/tasks/main.yaml

---
# install Splunk Base

- name: include vars
  include_vars: "{{ playbook_dir }}/config.yaml"

- include: install.yaml

vars теперь доступны в задачах,

роли cat/base/tasks/install.yaml

- name: echo version
  debug: splunk version is {{ splunk_version }}