È possibile definire le variabili globali di Playbook in Ansible?

Question

Ho un grande playbook Ansible in cui vengono create le immagini Docker durante l'esecuzione. Sto usando un numero crescente come tag per la versione. Attualmente, devo specificarlo in ogni sezione hosts:.

So che ci sono variabili globali, ma da quello che ho trovato attraverso la ricerca di "variabili globali "ansible"", devono definito al di fuori del playbook. È possibile definire variabili globali che sono globali per il playbook?

Answer 1

Se il tag/versione utilizzata è applicabile a tutti gli host, quindi utilizzando group_vars/all è una valida opzione.

Se i numeri di revisione sono specifici per ciascuna voce host in un file host_vars/nome_host potrebbe essere migliore.

Se si desidera leggere e inizializzare var e quindi incrementarlo dopo ogni riproduzione, diventa un po 'più difficile mantenere tali informazioni attraverso le riproduzioni (o ogni host come si dice) nel playbook. Per esempio, se state cercando di distribuire le istanze della finestra mobile N si potrebbe fare un po 'di magia inventario dinamico come questo:

- hosts: localhost 
    tasks: 
    - add_host: name=docker_{{item}} groups="dockers,other" tag={{item}} 
    with_sequence: start={{ext_def_start}} count={{ext_def_num}} 


- hosts: dockers 
    tasks: 
    - debug: var=tag 

Answer 2

Ansible ha un all gruppo predefinito che, stranamente, contiene tutti gli host del file di inventario.

Come tale si può fare come con nessun gruppo di accoglienza e di fornire group_vars per il gruppo host.

Come mostrato nel collegamento precedente, questi possono essere definiti direttamente nel file di inventario oppure possono essere contenuti in un file separato denominato dopo il gruppo in una directory group_vars allo stesso livello di directory del file di inventario.

Un esempio struttura di directory potrebbe quindi cercare qualcosa di simile:

-ansible 
|--inventory 
| |--group_vars 
| | |--all 
| | |--dev 
| | |--test 
| | |--prod 
| | |--webservers 
| | |--databases 
| |--dev 
| |--test 
| |--prod 
|--roles 
    ... 

Il file di inventario dev potrebbe quindi cercare qualcosa di simile:

[dev:children] 
webservers 
databases 

[webservers] 
web1.dev 
web2.dev 

[databases] 
database-master.dev 
database-slave.dev 

Tutti questi eserciti ora raccogliere qualsiasi configurazione specifica ospite (che potrebbe essere definito in linea o, proprio come con group_vars possono essere messi in una cartella host_vars) e config per i gruppi specifici che sono come e poi i gruppi che ereditano anche da come dev b ut anche, per impostazione predefinita, all.

Questo può quindi essere utilizzato per configurare le cose in modo più grossolana rispetto per host.

Le cose come i server NTP possono essere definite in tutto, mentre i server DNS potrebbero essere definiti a livello di ambiente (se la rete è segmentata in dev, test e produzione potrebbero aver bisogno di diversi server DNS in /etc/resolv.conf) mentre diversi tipi di server possono avere configurazioni diverse attorno a cose come liste di pacchetti da installare. Infine, alcune cose potrebbero dover essere specifiche dell'host come l'impostazione dell'ID del server MySQL in un gruppo di replica.

Se, invece, si desidera solo per definire le impostazioni globali playbook piuttosto che attraverso l'inventario (e così è stato possibile accedere da altri Playbook), allora è sufficiente un blocco vars nella vostra play definizione in questo modo:

- hosts: webservers 
    vars: 
    http_port: 80 
    tasks: 
    - name: Task1 to be ran against all the webservers 
     ... 

Come accennato prima, si può sempre utilizzare il gruppo all anche qui:

- hosts: all 
    vars: 
    ntp_pool: 
     - ntp1.domain 
     - ntp2.domain 
    tasks: 
    - name: Task1 to be ran against all the servers 
     ... 

In generale, comunque, mi sento di raccomandare vivamente di utilizzare i ruoli di strutturare ciò che le cose sono corse contro certa h host e quindi utilizzare l'inventario per spiegare quali server sono di tipo e quindi utilizzare una directory group_vars a livello di inventario per contenere tutte le variabili per quei gruppi di host. Fare le cose in questo modo ti aiuterà a mantenere le cose in luoghi sensibili e ti permetterà di riutilizzare facilmente il tuo codice base.

Answer 3

Sì, vars globali sono possibili in questo modo,

campione configurazione splunk playbook

splunk/ 
    setup_splunk_playbook.yaml 
    roles/base 
      /tasks/main.yaml 
      /tasks/install.yaml 
     search_head 
      /tasks/configure.yaml 
     indexer 
      /tasks/configure.yaml 
     some_other_role 
      /tasks/some_task.yaml 
    hosts 
    config.yaml 

Posizionare i vostri Vars in config.yaml

gatto Splunk/config.yaml

--- 
# global Splunk variables 
splunk_version: 7.0.0 

nel playbook, comprendono i ruoli

gatto setup_splunk_playbook.yaml

- hosts: "search_heads" 
    become_user: root 
    become: true 
    gather_facts: true 

    roles: 
    - base 
    - search_head 

nel tuo ruolo, includere le Vars globali all'interno di un compito

ruoli gatto/base/compiti/main.yaml

--- 
# install Splunk Base 

- name: include vars 
    include_vars: "{{ playbook_dir }}/config.yaml" 

- include: install.yaml 

Vars sono accessibili in compiti a questa parte, i ruoli

gatto/base/attività/install.yaml

- name: echo version 
    debug: splunk version is {{ splunk_version }}