Schlagwort-Archiv: conditionals

Beispiele für Ansibles ‚var is defined‘

In diesem Beitrag gebe ich einige Beispiele mit Erklärungen zu Ansible Conditionals, welche mir in der Dokumentation fehlen. Dieser Artikel dient mir zur Erinnerung und mag Einsteigern helfen, ein besseres Verständnis der Bedingung is defined zu gewinnen.

Wird in einem Task eine Variable verwendet, welche nicht definiert ist, bricht Ansible die Verarbeitung eines Playbooks mit einem Fehler ab. Der folgende Code-Block zeigt ein einfaches Playbook mit anschließender Ausgabe des Playbooklaufs, um dies zu verdeutlichen. Der Task beinhaltet dabei bereits eine Bedingung. Er soll nur dann ausgeführt werden, wenn die Variable my_var den Wert Hello world! enthält.

]$ cat test_conditionals.yml 
---
- name: Play around with conditionals
  hosts: localhost
  gather_facts: false

  tasks:
    - name: >-
        When all conditionals are met, print the variable value using
        ansible.builtin.debug
      when:
        - my_var == "Hello world!"
      ansible.builtin.debug:
        var: my_var

]$ ansible-playbook -i hosts test_conditionals.yml 

PLAY [Play around with conditionals] *******************************************

TASK [When all conditionals are met, print the variable value using ansible.builtin.debug] ***
fatal: [localhost]: FAILED! => {"msg": "The conditional check 'my_var == \"Hello world!\"' failed. The error was: error while evaluating conditional (my_var == \"Hello world!\"): 'my_var' is undefined. 'my_var' is undefined\n\nThe error appears to be in '/home/tronde/ansible/test_conditionals.yml': line 7, column 7, but may\nbe elsewhere in the file depending on the exact syntax problem.\n\nThe offending line appears to be:\n\n  tasks:\n    - name: >-\n      ^ here\n"}

PLAY RECAP *********************************************************************
localhost                  : ok=0    changed=0    unreachable=0    failed=1    skipped=0    rescued=0    ignored=0

Der Text 'my_var' is undefined in obiger Fehlerausgabe benennt den Grund des Scheiterns.

Nun gibt es Fälle, in denen Tasks, welche undefinierte Variablen enthalten, nicht zum Abbruch des gesamten Playbooks führen sollen. Stattdessen soll der betroffene Task einfach übersprungen werden. Dies erreicht man mit der Bedingung `is defined`. Der nächste Code-Block liefert wieder ein Beispiel dazu.

]$ cat test_conditionals.yml
---
- name: Play around with conditionals
  hosts: localhost
  gather_facts: false

  tasks:
    - name: >-
        When all conditionals are met, print the variable value using
        ansible.builtin.debug
      when:
        - my_var is defined
        - my_var == "Hello world!"
      ansible.builtin.debug:
        var: my_var

]$ ansible-playbook -i hosts test_conditionals.yml

PLAY [Play around with conditionals] *******************************************

TASK [When all conditionals are met, print the variable value using ansible.builtin.debug] ***
skipping: [localhost]

PLAY RECAP *********************************************************************
localhost                  : ok=0    changed=0    unreachable=0    failed=0    skipped=1    rescued=0    ignored=0

Der Task mit der undefinierten Variable wurde übersprungen (skipped) und das Playbook erfolgreich beendet.

Im nächsten Beispiel habe ich die Variable my_var im Playbook definiert und den passenden Wert zugewiesen.

]$ cat test_conditionals.yml
---
- name: Play around with conditionals
  hosts: localhost
  gather_facts: false
  vars:
    my_var: Hello world!

  tasks:
    - name: >-
        When all conditionals are met, print the variable value using
        ansible.builtin.debug
      when:
        - my_var is defined
        - my_var == "Hello world!"
      ansible.builtin.debug:
        var: my_var

]$ ansible-playbook -i hosts test_conditionals.yml

PLAY [Play around with conditionals] *******************************************

TASK [When all conditionals are met, print the variable value using ansible.builtin.debug] ***
ok: [localhost] => {
    "my_var": "Hello world!"
}

PLAY RECAP *********************************************************************
localhost                  : ok=1    changed=0    unreachable=0    failed=0    skipped=0    rescued=0    ignored=0

Das war auch schon alles für heute. Ihr seht, es ist keine Hexerei. Mir hilft es, die Bedeutung von is defined zu erinnern, wenn ich es einmal aufgeschrieben habe.

Zum Ende gibt es noch einen Code-Block, der zeigt, dass dies auch mit Dictionaries funktioniert:

]$ cat test_conditionals.yml
---
- name: Play around with conditionals
  hosts: localhost
  gather_facts: false
  vars:
    my_dict:
      my_var: Hello world!

  tasks:
    - name: >-
        When all conditionals are met, print the variable value using
        ansible.builtin.debug
      when:
        - my_dict.my_var is defined
        - my_dict.my_var == "Hello world!"
      ansible.builtin.debug:
        var: my_dict.my_var

]$ ansible-playbook -i hosts test_conditionals.yml

PLAY [Play around with conditionals] *******************************************

TASK [When all conditionals are met, print the variable value using ansible.builtin.debug] ***
ok: [localhost] => {
    "my_dict.my_var": "Hello world!"
}

PLAY RECAP *********************************************************************
localhost                  : ok=1    changed=0    unreachable=0    failed=0    skipped=0    rescued=0    ignored=0

In der Kategorie Ansible findet ihr weitere Artikel rund um Ansible. Viel Spaß beim Stöbern.

Ansible: Playbook nur auf Nodes laufen lassen, die gewissen Kriterien genügen

Manchmal möchte man ein Playbook bzw. Plays nur auf Hosts laufen lassen, welche gewissen Kriterien entsprechen. In diesem Beitrag möchte ich zwei Beispiele geben, wie sich dies umsetzen lässt.

Playbook nur auf Hosts mit Red Hat Betriebssystem ausführen

Das Modul group_by [1] wird genutzt, um während des Laufs eines Playbooks dynamisch Gruppen von Hosts zu erstellen, auf welche man später weitere Plays anwendet.

---
- hosts: all

  tasks:
    - name: Group by OS

      group_by: key=os_{{ ansible_distribution }}
      changed_when: False

- hosts: os_RedHat
  roles:
    - common

Zu Beginn eines Playbook-Laufs wird das Modul setup [2] ausgeführt, um Variablen mit nützlichen Informationen über die Nodes zu belegen. Die Variable ansible_distribution enthält dabei ein Schlüsselwort für eine bestimmte Distribution.

In obigen Beispiel wird dabei die Gruppe os_RedHat erstellt. Im Folgenden werden dann alle Nodes dieser Gruppe der Rolle common zugeordnet.

Dieses Verfahren lässt sich natürlich auch für weitere Variablen anwenden. Möchte man sehen, welche Variablen belegt werden und genutzt werden können, kann sich die Rückgabe von setup in der Standardausgabe ansehen, wenn man das Modul manuell auf einigen Nodes ausführt.

Plays nur auf bestimmten Nodes ausführen

Ein weiteres Beispiel habe ich auf ITrig [4] gefunden:

---
- name: install open-vm-tools
  hosts: vmwareclients
  gather_facts: True
  become: true
  become_user: root
  tasks:
- name: debian install open-vm-tools
  apt: name=open-vm-tools state=present
  when: ansible_os_family == "Debian" and ansible_virtualization_type == "VMware"

- name: centos install open-vm-tools
  yum: name=open-vm-tools state=present
  when: ansible_os_family == "RedHat" or ansible_distribution == 'CentOS' and ansible_virtualization_type == "VMware"

Hier werden Ansible Conditionals [3] verwendet, um zu bestimmen, auf welchen Nodes ein Play ausgeführt wird. Auch hier werden wieder Variablen ausgewertet, welche durch das Modul setup [2] belegt wurden.

In obigen Beispiel wird dies genutzt, um die open-vm-tools mit einem Playbook sowohl auf Debian und RedHat/CentOS Systemen zu installieren.

Quellen

  1. group_by – Create Ansible groups based on facts {en}
  2. setup – Gathers facts about remote hosts {en}
  3. Conditionals {en}
  4. Ansible Playbooks auf Servern mit SSH Key Authentifizierung verwenden {de}