Ansible Playbooks vs роли

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

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

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

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

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

- hosts: mail_servers
  roles:
    - postfix

- hosts: databases
  roles:
    - mysql

если Playbooks определены внутри файлов YAML, то где определены роли?

в Ansible почти все определено в YAML, что имеет значение для ролей и playbooks.

кроме ансибля.cfg, живущий на сервере Ansible, как добавить / настроить Ansible с доступными книгами/ролями? Например, когда я запускаю 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

в Анзибль условия:

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

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

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

резюме

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

теперь для вашего вопроса:

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

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

П. С.

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

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

пример 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