Несложная, выполняемая роль несколько раз с разными наборами параметров

Какова наилучшая практика для запуска одной роли с различным набором параметров?

Мне нужно несколько раз запускать одно приложение (контейнер докеров) на одном сервере с разными переменными среды для каждого.

Ответ 1

В документах Ansible есть ограничения, если дело доходит до такого рода вещей - если есть официальная лучшая практика, я не сталкивался с ней.

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

Синтаксис role: foo, var: blah, показанный немного в этом описании, является хорошим способом передать параметры и позволяет сразу же понять, что происходит. Например:

- name: Run the docker role with docker_container_state=foo
  hosts: docker-host
  roles:
  - { role: docker_container, docker_container_state: foo }

- name: Run the docker role with docker_container_state=bar
  hosts: docker-host
  roles:
  - { role: docker_container, docker_container_state: bar }

Ответ 2

Я обычно использую включает для запуска части роли (или целой роли!) несколько раз, если у меня есть достойная компоновка переменных, См. Приведенную ниже примерную книгу с ролью apply_state, которая имеет print_state.yml внутри roles/apply_state/tasks. Трюк состоит в том, чтобы передать элемент внутрь, включив его, после чего кусок пирога.

playbook.yml

- hosts: localhost
  roles:
    - { role: apply_state, states: [ state_one, state_two, state_three ] }

роли/apply_state/задачи/main.yml

- name: print all states!
  include: print_state.yml state="{{ item }}"
  with_items: "{{ states }}" 

роли/apply_state/задачи/print_state.yml

- name: echo state
  debug: msg="{{ state }}"

Смотрите результат ansible-playbook -i localhost, playbook.yml ниже:

PLAY [localhost] ***************************************************************

TASK [setup] *******************************************************************
ok: [localhost]

TASK [apply_state : print all states!] *****************************************
included: /home/user/roles/apply_state/tasks/print_state.yml for localhost
included: /home/user/roles/apply_state/tasks/print_state.yml for localhost
included: /home/user/roles/apply_state/tasks/print_state.yml for localhost

TASK [apply_state : echo state] ************************************************
ok: [localhost] => {
    "msg": "state_one"                                                                                                                 
}                                                                                                                                      

TASK [apply_state : echo state] ************************************************
ok: [localhost] => {
    "msg": "state_two"                                                                                                                 
}                                                                                                                                      

TASK [apply_state : echo state] ************************************************
ok: [localhost] => {
    "msg": "state_three"                                                                                                               
}                                                                                                                                      

PLAY RECAP *********************************************************************
localhost                  : ok=7    changed=0    unreachable=0    failed=0

Ответ 3

Если вам нужна следующая информация,

Иногда передача аргументов в роль Ansible - это искусственный способ ее эффективного многократного выполнения.

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

Решение состоит в том, чтобы добавить следующее свойство в meta/main.yml роли, которая будет выполняться несколько раз:

allow_duplicates: true

и ты в порядке!