Playbook Ansible vs ruoli

Secondo i documenti Ansible, un Playbook è:

... la base per un sistema di gestione della configurazione e distribuzione multi-macchina davvero semplice, diverso da quelli già esistenti, e molto adatto per la distribuzione di applicazioni complesse.

E, ancora una volta, secondo quegli stessi documenti, i ruoli sono:

... modi per caricare automaticamente determinati vars_file, attività e gestori in base a una struttura di file nota. Il raggruppamento dei contenuti per ruoli consente inoltre una facile condivisione dei ruoli con altri utenti.

Tuttavia la distinzione tra questi ei loro diversi casi d'uso non è immediatamente ovvia per me. Ad esempio, se configuro il mio /etc/ansible/hostsfile in modo che assomigli a:

[databases]
mydb01.example.org
mydb02.example.org

[mail_servers]
mymail01.example.org
mymail_dr.example.org

... allora cos'è questa " [databases]" voce ... un ruolo ? O il nome di un file YAML del playbook da qualche parte? O qualcos'altro?!?

Se qualcuno potesse spiegarmi le differenze su questi, la mia comprensione di Ansible sarebbe notevolmente migliorata!

• Playbook vs ruolo vs [databases]e voci simili in/etc/ansible/hosts
• Se i Playbook sono definiti all'interno dei file YAML, dove vengono definiti i ruoli?
• A parte la ansible.cfgvita sul server Ansible, come posso aggiungere / configurare Ansible con Playbook / ruoli disponibili? Ad esempio, quando corro ansible-playbook someplaybook.yaml, come fa Ansible a sapere dove trovare quel playbook?

Playbook vs Ruolo vs [database] e voci simili in / etc / ansible / hosts

[databases]è un unico nome per un gruppo di host. Ti consente di fare riferimento a più host con un unico nome.

Il ruolo è un insieme di attività e file aggiuntivi per configurare l'host per servire per un determinato ruolo .

Playbook è una mappatura tra host e ruoli.

L'esempio dalla documentazione descrive il progetto di esempio. Contiene due cose:

• Playbook. site.yml, webservers.yml, fooservers.ymlSono Playbook.
• Ruoli: roles/common/e roles/webservers/contengono definizioni commone webserversruoli di conseguenza.

All'interno del playbook ( webservers.yml) hai qualcosa come:

---
- 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

Se i Playbook sono definiti all'interno dei file YAML, dove vengono definiti i ruoli?

Sono definiti all'interno di roles/*directory. I ruoli vengono definiti principalmente utilizzando file YAML, ma possono anche contenere risorse di qualsiasi tipo ( files/, templates/). Secondo la documentazione, la definizione del ruolo è strutturata in questo modo:

• Se i ruoli / x / tasks / main.yml esistono, le attività elencate in esso verranno aggiunte al gioco
• Se i ruoli / x / handlers / main.yml esistono, i gestori elencati in esso verranno aggiunti al gioco
• Se i ruoli / x / vars / main.yml esistono, le variabili elencate in esso verranno aggiunte al gioco
• Se ruoli / x / meta / main.yml esiste, tutte le dipendenze di ruolo ivi elencate verranno aggiunte all'elenco dei ruoli (1.3 e versioni successive)
• Qualsiasi attività di copia può fare riferimento a file in ruoli / x / file / senza doverli tracciare in modo relativo o assoluto
• Qualsiasi attività di script può fare riferimento a script in ruoli / x / files / senza doverli tracciare in modo relativo o assoluto
• Qualsiasi attività modello può fare riferimento a file in ruoli / x / templates / senza doverli tracciare in modo relativo o assoluto
• Qualsiasi attività di inclusione può fare riferimento a file in ruoli / x / attività / senza doverli tracciare in modo relativo o assoluto

Il file più importante è che roles/x/tasks/main.ymlqui si definiscono le attività, che verranno eseguite quando viene eseguito il ruolo.

A parte ansible.cfg che risiede sul server Ansible, come posso aggiungere / configurare Ansible con Playbook / ruoli disponibili? Ad esempio, quando eseguo ansible-playbook someplaybook.yaml, come fa Ansible a sapere dove trovare quel playbook?

$ ansible-playbook someplaybook.yaml

Cercherà un playbook all'interno della directory corrente.

$ ansible-playbook somedir/somedir/someplaybook.yaml

Cercherà un playbook all'interno della somedir/somedir/directory.

È tua responsabilità mettere il tuo progetto con tutti i playbook e i ruoli sul server. Ansible non ha nulla a che fare con questo.

Playbook vs Ruolo vs [database] e voci simili in / etc / ansible / hosts

I ruoli sono un modo per raggruppare le attività in un unico contenitore. Potresti avere un ruolo per configurare MySQL, un altro per configurare Postfix ecc.

Un playbook definisce cosa sta succedendo e dove . Questo è il luogo in cui si definiscono gli host (gruppi di host, vedere di seguito) ei ruoli che verranno applicati a tali host.

[databases]e le altre voci nel tuo inventario sono gruppi host. I gruppi host definiscono un insieme di host su cui verrà eseguita una partita.

Un gioco è un insieme di compiti o ruoli (o entrambi) all'interno di un playbook. Nella maggior parte dei casi (ed esempi) un playbook conterrà solo una singola riproduzione. Ma puoi averne quante ne vuoi. Ciò significa che potresti avere un playbook che eseguirà il ruolo postfixnel gruppo host mail_serverse il ruolo mysqlnel gruppo host databases:

- hosts: mail_servers
  roles:
    - postfix

- hosts: databases
  roles:
    - mysql

Se i Playbook sono definiti all'interno dei file YAML, dove vengono definiti i ruoli?

In Ansible praticamente tutto è definito in YAML, che conta per ruoli e playbook.

A parte ansible.cfg che risiede sul server Ansible, come posso aggiungere / configurare Ansible con Playbook / ruoli disponibili? Ad esempio, quando eseguo ansible-playbook someplaybook.yaml, come fa Ansible a sapere dove trovare quel playbook?

Per quanto ne so, devi fornire il percorso al playbook quando invoca ansible-playbook. Quindi ansible-playbook someplaybook.yamlci si aspetterebbe someplaybook.yamldi essere nella directory corrente. Ma puoi fornire il percorso completo:ansible-playbook /path/to/someplaybook.yaml

È una domanda terminologica / semantica. Può essere soggettivo, anche se esiste una definizione di base.

La mia opinione è la seguente:

Qualsiasi sistema di gestione / distribuzione della configurazione ha:

1. source data - dati utilizzati per creare la configurazione dell'host di destinazione
2. target data - dati utilizzati per identificare gli host di destinazione
3. config changes- elenco / insieme di regole / azioni che applichiamo con source datal'host di destinazione in base atarget data

In termini di Ansible:

1. source data- sono i vari luoghi in cui possiamo inserire i dati - group_vars, playbookvars, rolevars, ecc., Questi luoghi influenzano la precedenza (se una variabile denominata la stessa viene ridefinita in posizioni diverse, ci sono regole molto specifiche su quale sarebbe il valore della variabile durante ansible/ ansible-playbookesecuzione
2. target data - è l'inventario (ed è anche possibile definire variabili inventario / gruppo host all'interno dell'inventario!)
3. config changes - ansible ha 4 livelli di astrazione per esso:
   1. compito - azione singola
   2. elenco delle attività - elenco delle azioni
   3. ruolo - elenco di azioni (o elenco di elenchi) raggruppati per lo stesso "soggetto", di solito tutti i target operano sullo stesso host / gruppo host
   4. playbook - elenco di riproduzioni, ognuna operante su un gruppo host possibilmente diverso, applicando diversi roles / tasks / elenchi di attività (e attività speciali come handlers)

Dal punto di vista del "software", il ruolo dovrebbe essere sufficientemente generico da essere riutilizzato .

Anche in alcune organizzazioni (piuttosto grandi), i "ruoli" vengono forniti dal gruppo A, mentre vengono utilizzati nei playbook gestiti dal gruppo B.

sommario

Tutto quanto sopra consente il raggruppamento di configurazioni simili - in un file role. raggruppare sottosistemi / componenti correlati in uno playbook. Inoltre, vale la pena menzionare, 1 YAML elemento in un playbook (compresi hosts:e uno o tasks, pre_tasks, post_tasks, roles) è chiamatoplay

Ora per la tua domanda:

Sì, all'inizio crea confusione.

Di solito colleghi il source datatuo alla semantica del tuo ruolo, quindi quando vedi che il ruolo setup_dbviene applicato in un gioco al gruppo host correlato (ad esempio db_hosts), ma a playpuò essere eseguito su un'unione di diversi gruppi host. È solo una questione di convenzione contro flessibilità.

PS

Per favore, scrivimi se questo ha aggiunto alla confusione o chiarito. Grazie.

Inoltre, tieni presente che un playbook può chiamare più di un ruolo se viene utilizzato un meta file destinato a influenzare i diversi ruoli.

Playbook di esempio: 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

La cartella dei ruoli e lo schema dei file appariranno così:

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

In poche parole:

Un playbook è come il programma principale, contiene istruzioni complete per completare il lavoro. Tuttavia, per i grandi progetti, non è desiderabile inserirci effettivamente ogni dettaglio. Quindi hai bisogno di un ruolo.

Un ruolo è una subroutine e di solito raggiunge un obiettivo, ad esempio configurare un server di database. Puoi metterlo nella roles/directory o scaricare ruoli di terze parti fornendo URI rolesfile.ymle chiedere ad ansible-galaxy di scaricarli per te.

Il [database]è un gruppo host definito nel file di inventario in cui sono elencati gli host che appartengono al databasegruppo. Puoi anche specificare un gruppo di server web specificando qualcosa di simile

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

Raggruppa webo databasepuò quindi essere utilizzato nei playbook o nei ruoli per specificare gli host da applicare.

I gruppi possono essere utilizzati anche al comando ansible per eseguire comandi ad-hoc.