I gestori Ansible definiti nei ruoli vengono eseguiti dopo l'intero playbook o il ruolo?

12

Sto eseguendo Ansible 2.0 e potrei semplicemente eseguirlo, ma potrei anche essere indotto a credere a qualcosa che non è vero nei miei test empirici e non riesco a trovare documentazione che mi dica quando si suppone che i gestori debbano essere eseguiti.

Se i gestori non vengono eseguiti alla fine delle loro attività, questo è il mio enigma. Ho un playbook con 5 ruoli in esso, voglio aggiungere un ruolo 6 alla fine che deve avere i gestori del 4 ° ruolo completati prima che possa iniziare.

Esiste un modo per eseguire Ansible per fare affidamento sul completamento di un gestore (ovvero un ruolo completamente completato) prima di fare qualcos'altro o sto usando i gestori in modo errato?

ansible 
— Peter Turner
fonte

Risposte:

15

I gestori vengono eseguiti:

  • alla fine di un'opera teatrale (non un playbook)
  • in esecuzione del meta: flush_handlerscompito

Quindi " per aggiungere un ruolo 6 alla fine che deve avere i gestori del 4 ° ruolo " è necessario:

  • o dividere l'assegnazione del ruolo in commedie separate;

  • o aggiungi una meta attività e includi il sesto ruolo con il include_rolemodulo :

    roles:
  - role4
tasks:
  - meta: flush_handlers
  - include_role:
      name: role6

Per il tuo caso d'uso, suggerirei il primo metodo poiché il include_rolemodulo è ancora molto fresco e ci sono stranezze quando lo usi (vedi questa domanda su SO ).

Inoltre, tieni presente che i nomi dei gestori e le chiamate di ascolto sono globali, quindi due gestori in ruoli separati saranno in conflitto se avessero lo stesso nome ed entrambi i ruoli fossero assegnati in una singola commedia. (ref. Handlers: Esecuzione di operazioni su modifica )

I gestori [] sono indicati da un nome univoco globale e sono notificati dai notificanti. [] un gestore, verrà eseguito una sola volta, dopo che tutte le attività sono state completate in un determinato gioco.

I nomi dei gestori e gli argomenti di ascolto vivono in uno spazio dei nomi globale.

  • Prova empirica (esegui questo script di shell per confermare che i gestori vengano eseguiti alla fine del gioco - qui c'erano commenti e risposte contraddittorie):

    #!/bin/bash

mkdir -p ./sf831880/roles/role1
mkdir -p ./sf831880/roles/role1/handlers
mkdir -p ./sf831880/roles/role1/tasks
mkdir -p ./sf831880/roles/role2
mkdir -p ./sf831880/roles/role2/handlers
mkdir -p ./sf831880/roles/role2/tasks

cat >./sf831880/roles/role1/tasks/main.yml <<TASKS1_END
---
- name: Always true in role1
  command: echo role1
  notify: handler1
TASKS1_END

cat >./sf831880/roles/role2/tasks/main.yml <<TASKS2_END
---
- name: Always true in role2
  command: echo role2
  notify: handler2
TASKS2_END

cat >./sf831880/roles/role1/handlers/main.yml <<HANDLERS1_END
---
- name: handler1
  debug:
    msg: "This is a handler in role1"
HANDLERS1_END

cat >./sf831880/roles/role2/handlers/main.yml <<HANDLERS2_END
---
- name: handler2
  debug:
    msg: "This is a handler in role2"
HANDLERS2_END

cat >./sf831880/playbook.yml <<PLAYBOOK_END
---
- hosts: localhost
  gather_facts: no
  connection: local
  roles:
    - role1
    - role2
  tasks:
    - debug:
        msg: "This is a task in a play"
PLAYBOOK_END

ansible-playbook ./sf831880/playbook.yml

    Risultato:

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

TASK [role1 : Always true in role1] ********************************************
changed: [localhost]

TASK [role2 : Always true in role2] ********************************************
changed: [localhost]

TASK [debug] *******************************************************************
ok: [localhost] => {
    "msg": "This is a task in a play"
}

RUNNING HANDLER [role1 : handler1] *********************************************
ok: [localhost] => {
    "msg": "This is a handler in role1"
}

RUNNING HANDLER [role2 : handler2] *********************************************
ok: [localhost] => {
    "msg": "This is a handler in role2"

  • Gioca modificato per contenere meta: flush_handlers:

    ---
- hosts: localhost
  gather_facts: no
  connection: local
  roles:
    - role1
    - role2
  tasks:
    - meta: flush_handlers
    - debug:
        msg: "This is a task in a play"

    Il risultato:

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

TASK [role1 : Always true in role1] ********************************************
changed: [localhost]

TASK [role2 : Always true in role2] ********************************************
changed: [localhost]

RUNNING HANDLER [role1 : handler1] *********************************************
ok: [localhost] => {
    "msg": "This is a handler in role1"
}

RUNNING HANDLER [role2 : handler2] *********************************************
ok: [localhost] => {
    "msg": "This is a handler in role2"
}

TASK [debug] *******************************************************************
ok: [localhost] => {
    "msg": "This is a task in a play"
— techraf
fonte
2

I gestori sono elenchi di attività, non molto diverse dalle attività normali, a cui fa riferimento un nome univoco globale e che vengono notificate dai notificanti. Se nulla avvisa un gestore, non verrà eseguito. Indipendentemente da quante attività notificano a un gestore, verrà eseguito una sola volta, dopo che tutte le attività sono state completate in un determinato gioco. doc doc

1) I gestori che fanno la stessa cosa dovrebbero avere lo stesso nome.
restart nginxSEMPRE riavvia nginx, non handler1ehandler2

2) I gestori vengono eseguiti alla fine di tutto il "Gioco", un gioco mirato alle sezioni.

3) Vorrei usare le funzioni registere whenper i compiti che dovrebbero essere riavviati, nota che questo var dovrebbe portare con te.

Fonte del codice

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

TASK [debug] *******************************************************************
ok: [localhost] => {
    "msg": "Play 1"
}

TASK [role1 : Always true in role1] ********************************************
changed: [localhost]

TASK [role1 : Always true in role1] ********************************************
changed: [localhost]

TASK [role1 : Always true in role1] ********************************************
changed: [localhost]

TASK [role1 : Always true in role1] ********************************************
changed: [localhost]

TASK [role1 : Always true in role1] ********************************************
changed: [localhost]

TASK [role2 : Run if change in task c of role 1] *******************************
changed: [localhost]

TASK [role2 : Always true in role2] ********************************************
changed: [localhost]

TASK [debug] *******************************************************************
ok: [localhost] => {
    "msg": "This is a task in a play"
}

RUNNING HANDLER [role1 : handler] **********************************************
ok: [localhost] => {
    "msg": "This is a handler in role1"
}

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

TASK [debug] *******************************************************************
ok: [localhost] => {
    "msg": "Play 2"
}

TASK [role1 : Always true in role1] ********************************************
changed: [localhost]

TASK [role1 : Always true in role1] ********************************************
changed: [localhost]

TASK [role1 : Always true in role1] ********************************************
changed: [localhost]

TASK [role1 : Always true in role1] ********************************************
changed: [localhost]

TASK [role1 : Always true in role1] ********************************************
changed: [localhost]

TASK [role2 : Run if change in task c of role 1] *******************************
changed: [localhost]

TASK [role2 : Always true in role2] ********************************************
changed: [localhost]

TASK [debug] *******************************************************************
ok: [localhost] => {
    "msg": "This is a task in a play"
}

RUNNING HANDLER [role1 : handler] **********************************************
ok: [localhost] => {
    "msg": "This is a handler in role1"
}

PLAY RECAP *********************************************************************
localhost                  : ok=20   changed=14   unreachable=0    failed=0

Tanti modi per svolgere la stessa attività. I gestori sono stati progettati per impedire il riavvio dello stesso processo più volte, ad esempio modifiche multiple a un server nginx con siti Web, certificati SSL e altre attività che richiedono il riavvio del servizio.

— Jacob Evans
fonte
Stai citando " esegui una sola volta, dopo che tutte le attività sono state completate in un gioco particolare " e quindi rivendichi qualcosa di completamente diverso " esegui un'attività alla fine di ogni ruolo ". Anche la tua richiesta è diversa dalla realtà.
— techraf,
no fraintendete, se chiamo lo stesso gestore dal ruolo del server 4 volte da meta. funziona solo una volta
— Jacob Evans,
La domanda è chiara: quando vengono eseguiti i gestori? Non quante volte vengono eseguite. E vengono eseguiti alla fine di un gioco, non alla fine di un ruolo. Periodo. Sei una terza persona che afferma il contrario, anche se l'hai fatto dopo che ho pubblicato la mia risposta con esempi che mostrano che questo reclamo è falso.
— techraf,
e la mia risposta è: utilizzare attività non gestori per gli elementi che devono essere riavviati all'interno del loro ruolo.
— Jacob Evans,
@techraf eccoti.
— Jacob Evans,
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.