Come può un playbook register in una variabile il risultato di un altro playbook ?In che modo Ansible "registra" in una variabile il risultato di includere un playbook?
Ad esempio, sarebbe il seguente registro il risultato dell'esecuzione di tasks/foo.yml in result_of_foo?
tasks:
- include: tasks/foo.yml
- register: result_of_foo
In quale altro modo Ansible registra il risultato di una sequenza di attività?
La risposta breve è che questo non può essere fatto.
L'istruzione register viene utilizzata per memorizzare l'output di una singola attività in una variabile. Il contenuto esatto della variabile registrata può variare ampiamente a seconda del tipo di attività (ad esempio, l'attività shell includerà lo stderr stdout in uscita dal comando eseguito nella variabile registrata, mentre l'attività stat fornirà i dettagli del file che è passato al compito).
Se si dispone di un file di inclusione con un numero arbitrario di attività all'interno di esso, Ansible non avrebbe modo di sapere cosa memorizzare nella variabile nell'esempio.
Ogni singola attività all'interno del file include può registrare variabili ed è possibile fare riferimento a tali variabili altrove, quindi non c'è davvero bisogno nemmeno di fare qualcosa del genere.
Sono riuscito a farlo passando un nome di variabile come variabile da utilizzare nell'attività. Ho incluso il mio main.yaml e incluso i file cgw.yaml di seguito.
main.yaml:
- name: Create App A CGW
include: cgw.yaml
vars:
bgp_asn: "{{ asn_spoke }}"
ip_address: "{{ eip_app_a.public_ip }}"
name: cgw-app-a
region: "{{ aws_region }}"
aws_access_key: "{{ ec2_access_key }}"
aws_secret_key: "{{ ec2_secret_key }}"
register: cgw_app_a
cgw.yaml:
- name: "{{ name }}"
ec2_customer_gateway:
bgp_asn: "{{ bgp_asn }}"
ip_address: "{{ ip_address }}"
name: "{{ name }}"
region: "{{ region }}"
aws_access_key: "{{ aws_access_key }}"
aws_secret_key: "{{ aws_secret_key }}"
register: "{{ register }}"
È necessario se si trattano un playbook come una scatola opaca (cioè una funzione) con un semplice, ben definita interfaccia. Perché un libro di esercizi non dovrebbe avere variabili con scope e valori di ritorno? –
La cartella di ascolto di Ansible soffre di alcuni dei problemi che ho osservato in altri linguaggi di dominio specifici (DSL) come Ant, un linguaggio di compilazione per Java. Tali linguaggi sono per lo più dichiarativi, ma hanno anche un comportamento funzionale o imperativo incompleto. Il libro degli amici ha riempito in modo incrementale le lacune imperative, ma come dimostra questo caso, ha ancora buchi da riempire. Un approccio alternativo consiste nel basare la progettazione di una DSL su un linguaggio di programmazione esistente, ma seguire una sintassi più stretta o fornire solo funzioni specifiche. (YAML e XML non sono * linguaggi di programmazione.) –
Non è ancora possibile, anche se esiste una sola attività in un playbook? Potresti registrare il risultato di quell'attività e poi fare riferimento al gioco originale? – user3270760