Qual è la differenza tra valori predefiniti e variabili in un ruolo Ansible?

Quando si crea un nuovo ruolo Ansible, il modello crea sia una varsche una defaultsdirectory con un main.ymlfile vuoto . Quando definisco il mio ruolo, posso inserire definizioni variabili in una di queste e saranno disponibili nelle mie attività.

Qual è la differenza tra mettere le definizioni in defaultse vars? Cosa dovrebbe entrare defaultse cosa dovrebbe entrare vars? Ha senso usare entrambi per gli stessi dati?

So che c'è una differenza in precedenza / priorità tra i due, ma vorrei capire cosa dovrebbe andare dove.

Diciamo che il mio ruolo creerebbe un elenco di directory sul sistema di destinazione. Vorrei fornire un elenco di directory predefinite da creare, ma vorrei consentire all'utente di sovrascriverle durante l'utilizzo del ruolo.

Ecco come sarebbe:

---
- directories:
  - foo
  - bar
  - baz

Potrei posizionarlo nel defaults/main.ymlo nel vars/main.yml, dal punto di vista dell'esecuzione, non farebbe alcuna differenza - ma dove dovrebbe andare?

La documentazione Ansible sulla precedenza variabile riassume questa niceley:

Se più variabili con lo stesso nome sono definite in luoghi diversi, vincono in un certo ordine, che è:

• extra vars (-e nella riga di comando) vincono sempre
• poi arrivano le variabili di connessione definite nell'inventario (ansible_ssh_user, ecc.)
• poi arriva "quasi tutto il resto" (opzioni della riga di comando, vari tipi di gioco, vari tipi di ruolo inclusi
• poi arriva il resto delle variabili definite nell'inventario
• poi arrivano i fatti scoperti su un sistema
• quindi "default del ruolo", che sono i più "predefiniti" e perdono in priorità tutto.

Supponiamo quindi di avere un ruolo "tomcat" che usi per installare Tomcat su un sacco di host web, ma hai bisogno di versioni diverse di tomcat su un paio di host, ne hai bisogno per funzionare come utenti diversi in altri casi, ecc. Il defaults/main.ymlfile potrebbe apparire qualcosa come questo:

tomcat_version: 7.0.56
tomcat_user: tomcat

Poiché questi sono solo valori predefiniti, significa che verranno utilizzati se tali variabili non sono definite altrove per l'host in questione. Puoi sovrascriverli tramite extra-var, tramite fatti nel tuo file di inventario, ecc. Per specificare valori diversi per queste variabili.

Modifica: si noti che l'elenco sopra è per Ansible 1.x. In Ansible 2.x l'elenco è stato ampliato. Come sempre, la Documentazione Ansible fornisce una descrizione dettagliata della precedenza variabile per 2.x.

Le variabili di ruolo definite varhanno una priorità molto elevata: possono essere sovrascritte solo passandole sulla riga di comando, nell'attività specifica o in un blocco. Pertanto, quasi tutte le variabili dovrebbero essere definite in defaults.

Nell'articolo " Precedenza variabile - Dove mettere il tuo ruolo Vars ", l'autore fornisce un esempio di cosa inserire vars: costanti specifiche del sistema che non cambiano molto. Quindi puoi avere vars/debian.ymle vars/centos.ymlcon gli stessi nomi di variabili ma valori diversi e includerli in modo condizionale.

IMHO non è pratico e non ragionevole che luoghi ansible tale alta priorità della configurazione in vars di ruoli . La configurazione in vars/main.ymle defaults/main.ymldovrebbe essere bassa e probabilmente la stessa priorità.

Esistono esempi di vita reale di casi in cui desideriamo questo tipo di comportamento?

Ci sono esempi che non vogliamo questo.

Il punto da sottolineare qui è che la configurazione defaults/main.ymlnon può essere dinamica. Configurazione in vars/main.ymlcan. Quindi, ad esempio, puoi includere la configurazione per OS e versione specifici in modo dinamico, come mostrato in geerlingguy.postgresql

Ma poiché la precedenza è così strana e poco pratica in Ansible, il geerlingguy deve introdurre pseudo-variabili come si può vedere in variabili.yml

- name: Define postgresql_packages.
  set_fact:
    postgresql_packages: "{{ __postgresql_packages | list }}"
  when: postgresql_packages is not defined

Questo è un esempio concreto di vita reale che dimostra che la precedenza non è pratica.

Un altro punto da sottolineare qui è che vogliamo che i ruoli siano configurabili. I ruoli possono essere esterni, gestiti da qualcun altro. Come regola generale, non si desidera che la configurazione nei ruoli abbia la massima priorità.

Fondamentalmente, tutto ciò che va in "valori predefiniti di ruolo" (la cartella dei valori predefiniti all'interno del ruolo) è il più malleabile e facilmente sostituibile. Qualsiasi cosa nella directory vars del ruolo sostituisce le versioni precedenti di quella variabile nello spazio dei nomi. L'idea qui da seguire è che più esplicito si ottiene nell'ambito, maggiore è la precedenza con la riga di comando -e extra extra sempre vincenti. Le variabili host e / o di inventario possono prevalere sui valori predefiniti dei ruoli, ma non include esplicite come la directory vars o un'attività include_vars. doc

Variabili e valori predefiniti camminano mano nella mano. ecco un esempio

-name: install package
 yum: name=xyz{{package_version}} state=present

nel tuo file predefinito avresti qualcosa del tipo:

package_version: 123

Ciò che Ansible farà è, prenderà il valore di package_versione lo metterà accanto al nome del pacchetto in modo che legga da qualche parte come:

-name: install package
 yum: name=xyz123 state=present

In questo modo verrà installato xyz123e non xyz123.4o qualunque cosa sia nel grande repository di xyz's.

Alla fine lo farà yum install -y xyz123

Quindi, in sostanza, i valori predefiniti sono i valori presenti, se non si imposta un valore specifico per le variabili, poiché lo spazio non può rimanere vuoto.