Неспокойные книги против ролей

Ответ 1

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

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

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

Playbook - это сопоставление между хостами и ролями.

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

• Playbooks. site.yml, webservers.yml, fooservers.yml - это проигрыватели.
• Роли: 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

Если в файлах 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/без необходимости относить их относительно или абсолютно
• Любые задачи script могут ссылаться на скрипты в ролях/x/files/без необходимости относить их относительно или абсолютно
• Любые задачи шаблона могут ссылаться на файлы в ролях/x/templates/без необходимости относить их относительно или абсолютно
• Любые включенные задачи могут ссылаться на файлы в ролях/x/tasks/без необходимости относить их относительно или абсолютно

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

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

$ ansible-playbook someplaybook.yaml

Будет искать учебник в текущем каталоге.

$ ansible-playbook somedir/somedir/someplaybook.yaml

Посмотрите на playbook внутри каталога somedir/somedir/.

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

Ответ 2

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

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

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

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

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

- hosts: mail_servers
  roles:
    - postfix

- hosts: databases
  roles:
    - mysql

Если в файлах YAML определены книги, то где определены роли?

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

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

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

Ответ 3

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

Мое мнение выглядит следующим образом:

Любая система управления/развертывания системы имеет:

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

В неотвратимых терминах:

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

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

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

Резюме

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

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

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

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

P.S.

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

Ответ 4

Также имейте в виду, что 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

Ответ 5

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

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

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

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

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

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

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