Бродячий Ansible и роли модуля

Будет ли это включать в себя создание нескольких пьес? Один для Vagrant и один для каждой конфигурации? Если так, это может привести к большому дублированию кода.

Для этого не нужно дублировать код. Playbooks могут включать другие playbooks. Таким образом, вы можете разделить свои плейбуки по типу, а затем для бродяги иметь плейбук верхнего уровня, который включает в себя другие плейбуки, в то время как для производственных серверов эти плейбуки выполняются отдельно.

- include: webserver.yml
- include: database.yml
- include: application.yml

Другая идея - просто иметь условные роли. Если я правильно вас понял, у вас есть группы nginxServer, djangoServer и postgresServer, и ваша тестовая виртуальная машина входит во все 3 группы, а ваша производственная только хозяева входят в одну или две группы. Если это верно, вы можете просто добавить условия к ролям.

Например:

  roles:
    - role: supervisor
      tags: supervisor
      when: "nginxServer" in group_names

    - role: nginx
      tags: nginx
      when: "nginxServer" in group_names

Однако время выполнения будет больше, поскольку Ansible по-прежнему будет обрабатывать все роли. Фактически условия передаются каждой задаче внутри ролей, поэтому тогда у вас будет много пропущенных задач.

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

Например, если у вас есть установка с одним веб-сервером, одним сервером приложений и одним сервером базы данных, то ваш инвентарь будет выглядеть следующим образом:

[nginxServer]
web.example.org

[djangoServer]
app.example.org

[postgresServer]
database.example.org

Или, если вы хотите только отделить базу данных от объединенного окна веб-приложения / приложения, у вас будет что-то вроде:

[nginxServer]
app.example.org

[djangoServer]
app.example.org

[postgresServer]
database.example.org

Что запустит ваш nginx, и приложение будет играть против того же app.example.org хоста.

Точно так же вы можете легко распространить вещи на более крупную среду:

[nginxServer]
web-1.example.org
web-2.example.org

[djangoServer]
app-1.example.org
app-2.example.org
app-3.example.org
app-4.example.org

[postgresServer:children]
postgresMaster
postgresSlave

[postgresMaster]
database-1.example.org

[postgresSlave]
database-2.example.org

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

Если вы хотите настроить таргетинг только на отдельные группы хостов (например, nginxServers), вы можете сделать это, просто используя _ 6_ со своим исходным учебником или вы можете написать более конкретные учебники, которые нацелена только на эту группу хостов для роли, а затем создайте сценарий верхнего уровня, который запускает все другие сценарии, когда вы хотите подготовить все:

site.yml

- include: webserver.yml
- include: database.yml
- include: application.yml

webserver.yml

- name: Nginx Host
  hosts: nginxServer
  vars:
    - update_apt_cache: yes
  vars_files:
    - env_vars/base.yml
  roles:
    - { role: supervisor, tags: ['supervisor'] }
    - { role: nginx, tags: ['nginx'] }

Что касается базовой игры, я бы предпочел сделать эту роль зависимостью, поскольку на всех других ваших серверах базовая роль всегда должна запускаться против них, независимо от того, как эта роль называется. Вы можете сделать это, создав папку meta для каждой из трех основных ролей и включив туда main.yml файл со следующим содержимым:

dependencies:
    -   role: base
    - { role: users, tags: ['users'] }
    - { role: sites, tags: ['sites'] }