it-swarm.com.ru

Ansible Playbooks vs Роли

Согласно 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
  • Если Playbooks определены в файлах YAML, то где определены роли?
  • Помимо ansible.cfg, живущего на сервере Ansible, как мне добавить/настроить Ansible с доступными книгами/ролями? Например, когда я запускаю ansible-playbook someplaybook.yaml, как Ansible узнает, где найти эту пьесу?
77
smeeb

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

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

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

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

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

  • Playbooks. 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

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

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

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

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

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

$ ansible-playbook someplaybook.yaml

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

$ ansible-playbook somedir/somedir/someplaybook.yaml

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

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

84
Yaroslav Admin

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

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

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

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

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

- hosts: mail_servers
  roles:
    - postfix

- hosts: databases
  roles:
    - mysql

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

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

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

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

31
udondan

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

Мое мнение таково:

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

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

В терминах Ansible:

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

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

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

резюме

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

Теперь на ваш вопрос:

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

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

Постскриптум.

Пожалуйста, напишите мне, добавило ли это путаницу или уточнило. Благодарю.

8
mvk_il

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

Пример 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
0
Jose H. Rosa

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

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

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

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

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

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

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

0
Ding-Yi Chen