Ansible Playbooks против ролей

Согласно документам Ansible, Playbook :

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

И, опять же, согласно тем же документам, Роли :

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

Однако различие между ними и их разными вариантами использования для меня не сразу очевидно. Например, если я настрою свой /etc/ansible/hostsфайл так, чтобы он выглядел так:

[databases]
mydb01.example.org
mydb02.example.org

[mail_servers]
mymail01.example.org
mymail_dr.example.org

... тогда что это за " [databases]" запись ... роль ? Или где-нибудь имя YAML-файла playbook? Или что-то другое?!?

Если бы кто-нибудь мог объяснить мне различия в них, мое понимание Ansible значительно улучшилось!

• Playbook vs Role vs [databases]и подобные записи в/etc/ansible/hosts
• Если Playbook определены внутри файлов YAML, то где же определяются роли?
• Помимо ansible.cfgживого на сервере Ansible, как мне добавить / настроить Ansible с доступными Playbooks / ролями? Например, когда я бегу ansible-playbook someplaybook.yaml, как Ansible узнает, где найти эту книгу?

Playbook vs Role vs [databases] и аналогичные записи в / etc / ansible / hosts

[databases]одно имя для группы хостов. Это позволяет вам ссылаться на несколько хостов по одному имени.

Роль - это набор задач и дополнительных файлов для настройки хоста для выполнения определенной роли .

Playbook - это сопоставление хостов и ролей.

Пример из документации описывает пример проекта. Он содержит две вещи:

• Пособия. site.yml, webservers.yml, fooservers.ymlЯвляются playbooks.
• Роли: roles/common/и roles/webservers/содержат определения commonи webserversроли соответственно.

Внутри playbook ( webservers.yml) у вас есть что-то вроде:

---
- hosts: webservers <- this group of hosts defined in /etc/ansible/hosts, databases and mail_servers in example from your question
  roles: <- this is list of roles to assign to these hosts
     - common
     - webservers

Если Playbook определены внутри файлов YAML, то где же определяются роли?

Они определены внутри roles/*каталогов. Роли определяются в основном с помощью файлов YAML, но также могут содержать ресурсы любых типов ( files/, templates/). Согласно документации определение роли структурировано следующим образом:

• Если роли / x / tasks / main.yml существует, перечисленные в них задачи будут добавлены в игру.
• Если роли / x / handlers / main.yml существуют, перечисленные в них обработчики будут добавлены в игру.
• Если роли / x / vars / main.yml существуют, перечисленные в них переменные будут добавлены в игру.
• Если роли / x / meta / main.yml существуют, любые зависимости ролей, перечисленные в нем, будут добавлены в список ролей (1.3 и новее)
• Любые задачи копирования могут ссылаться на файлы в ролях / x / files / без необходимости относительного или абсолютного пути к ним.
• Любые задачи сценария могут ссылаться на сценарии в ролях / x / files / без необходимости относительного или абсолютного пути к ним.
• Любые задачи шаблона могут ссылаться на файлы в ролях / x / templates / без необходимости относительного или абсолютного пути к ним.
• Любые включаемые задачи могут ссылаться на файлы в ролях / x / tasks / без необходимости относительного или абсолютного пути к ним.

Самый важный файл - roles/x/tasks/main.ymlздесь вы определяете задачи, которые будут выполняться при выполнении роли.

Помимо файла ansible.cfg, который находится на сервере Ansible, как мне добавить / настроить Ansible с доступными Playbooks / ролями? Например, когда я запускаю ansible-playbook someplaybook.yaml, как Ansible узнает, где найти этот playbook?

$ ansible-playbook someplaybook.yaml

Будет искать пьесу внутри текущего каталога.

$ ansible-playbook somedir/somedir/someplaybook.yaml

Буду искать пьесу внутри somedir/somedir/каталога.

Вы обязаны разместить свой проект со всеми сценариями и ролями на сервере. Ansible не имеет к этому никакого отношения.

Playbook vs Role vs [databases] и аналогичные записи в / etc / ansible / hosts

Роли - это способ группировать задачи в один контейнер. У вас может быть роль для настройки MySQL, другая - для настройки Postfix и т. Д.

Пособие определяет, что и где происходит . Это место, где вы определяете хосты (группы хостов, см. Ниже) и роли, которые будут применяться к этим хостам.

[databases]а другие записи в вашем инвентаре - это группы хостов. Группы хостов определяют набор хостов, на которых будет проходить игра.

Игра - это набор задач или ролей (или и того, и другого) внутри сборника пьес. В большинстве случаев (и примеров) playbook будет содержать только одну игру. Но вы можете иметь столько, сколько захотите. Это означает, что у вас может быть playbook, который будет запускать роль postfixв группе хостов mail_serversи роль mysqlв группе хостов databases:

- hosts: mail_servers
  roles:
    - postfix

- hosts: databases
  roles:
    - mysql

Если Playbook определены внутри файлов YAML, то где же определяются роли?

В Ansible практически все определяется в YAML, что учитывается для ролей и сценариев.

Помимо файла ansible.cfg, который находится на сервере Ansible, как мне добавить / настроить Ansible с доступными Playbooks / ролями? Например, когда я запускаю ansible-playbook someplaybook.yaml, как Ansible узнает, где найти этот playbook?

AFAIK вы должны указать путь к playbook при вызове ansible-playbook. Так ansible-playbook someplaybook.yamlбыло бы ожидать , someplaybook.yamlчтобы быть в вас текущем каталоге. Но вы можете указать полный путь:ansible-playbook /path/to/someplaybook.yaml

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

Моя точка зрения такова:

Любая система управления конфигурацией / развертывания имеет:

1. source data - данные, используемые для создания конфигурации целевого хоста
2. target data - данные, используемые для идентификации целевых хостов
3. config changes- список / набор правил / действий, которые мы применяем к source dataцелевому хосту на основеtarget data

В терминах Ansible:

1. source data- это различные места, в которые мы можем поместить данные - group_vars, playbookvars, rolevars и т. д. Эти места влияют на приоритет (если переменная с таким же именем переопределяется в разных местах, существуют очень конкретные правила того, каким будет значение переменная во время ansible/ ansible-playbookвыполнение
2. target data - это инвентарь (и, также можно определить переменные инвентаря / группы хостов внутри инвентаря!)
3. config changes - ansible имеет 4 уровня абстракции:
   1. задача - одно действие
   2. список задач - список действий
   3. роль - список действий (или список списков), сгруппированных по одному «субъекту», обычно все цели работают на одном хосте / группе хостов
   4. playbook - список игр, каждая из которых работает, возможно, в разных группах хостов, с применением нескольких roles / tasks / списков задач (и специальных задач, например handlers)

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

Также в некоторых (довольно больших) организациях «роли» поставляются группой A, тогда как они используются в сценариях, поддерживаемых группой B.

резюме

Все вышесказанное позволяет сгруппировать похожие конфигурации - в файл role. группирование связанных подсистем / компонентов в однуplaybook . Кроме того , стоит упомянуть, 1 YAML пункт в сборник пьес ( в том числе hosts:и один или tasks, pre_tasks, post_tasks, roles) называетсяplay

Теперь к вашему вопросу:

Да, это сначала сбивает с толку.

Обычно вы связываете source dataсебя с семантикой своей роли, поэтому, когда вы видите эту рольsetup_db применяется в игре к связанной группе хостов (например, db_hosts), но playможет выполняться объединение нескольких групп хостов. Это просто вопрос условности против гибкости.

PS

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

Также имейте в виду, что playbook может вызывать несколько ролей, если используется метафайл, предназначенный для воздействия на разные роли.

Пример пособия: dual_role-playbook.yml

- name: Some Action for two roles
  hosts: localhost

  vars_files:
    - roles/dual_role/meta/main.yml

  roles:
    - dual_role/container-1
    - dual_role/container-2

Схема папок и файлов ролей будет выглядеть так:

dual_role-playbook.yml
  -- roles
     -- dual_role
        -- meta/main.yml
        -- container-1
           -- tasks/main.yml
           -- templates/template.j2
        -- container-2
           -- tasks/main.yml
           -- templates/template.j2

Проще говоря:

Playbook похож на основную программу, он содержит полные инструкции для завершения работы. Однако для больших проектов нежелательно вдаваться в подробности. Итак, вам нужна роль.

Роль - это подпрограмма, которая обычно достигает одной цели, например, настраивает сервер базы данных. Вы можете поместить его в roles/каталог или загрузить сторонние роли, указав URI rolesfile.ymlи спросив ansible-galaxy загрузить их для вас.

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

[web]
web1.example.com
web2.example.com

Группа webили databaseзатем может использоваться в сценариях или ролях для указания применяемых хостов.

Группы также можно использовать в команде ansibleдля выполнения специальных команд.