Ansible: Mehrere und/oder-Bedingungen in wenn-Klausel

Ich habe Probleme bei dem Versuch, mehrere und/oder-Bedingungen in einer wenn-Anweisung, um zu entscheiden, ob ein task muss ausgeführt werden oder nicht. Im Grunde mache ich ein playbook automatisierten system patchen mit Optionen für security-patches, kernel, nur die patches und geben Sie Pakete in einer var-Datei.

Ich das playbook mit dem folgenden Befehle ein, und definieren Sie die Variablen durch erweiterte Variablen-option (-e)

ansible-playbook site.yml -i inventory --ask-vault -u (username) -e "security=true restart=true" -k -K

Standardmäßig das playbook wird bei jedem update-Paket auf das system, außer kernel, aber ich würde gerne überspringen Sie diese Aktion, wenn ich legen Sie ein paar Variablen. Der code, den ich habe, ist folgende:

- name: Update all packages
  yum:
     name: "*"
     state: latest
     exclude: "kernel*"
  when: security is not defined or kernel is not defined  or specified_packages 
 is not defined and ansible_os_family == "RedHat"

Ive versucht, alle der folgenden Kombinationen:

when: (ansible_os_family == "RedHat") and (security is defined or kernel is defined or specified_packages is defined)

when: (ansible_os_family == "RedHat") and (security == true or kernel == true or specified_packages == true ) <- dieser Fall wirft ein nicht definierter Fehler, weil ich nicht definieren alle Variablen jedes mal, wenn ich das playbook

when: ansible_os_family == "RedHat"
when: security is defined or kernel is defined or specified_packages is defined

Hinweis: ich bin mir bewusst, und habe eine extra variable, wie "überspringen" überspringen Sie diese Aufgabe und Einsatz der wenn-Klausel when: ansible_os_family == "RedHat" and skip is not defined aber lieber nicht, habe meine Benutzer benötigen, um eine zusätzliche variable zu überspringen, diese Standard-Aktion.

Ich bin auch nicht mit Hilfe von tags, wie ich bin, sammelt eine Liste der Pakete, die vor und nach dem upgrade vergleichen und den Bericht in das Ende, so dass ich nicht in der Lage, diese so wie Sie sind lokalen Aktion Befehle. Dies ist der Grund, warum ich mit einer Rolle mit mehreren Aufgaben ein-und ausgeschaltet über erweiterte Variablen. Ich bin offen für jeden Vorschlag, schreibt das playbook in einer effizienteren Art und Weise wie ich bin sozusagen ein noob.

  • Ja, Sie können nicht kombinieren is defined mit anderen Bedingungen auf diese Weise. Es wird nicht funktionieren, wenn eine variable nicht definiert ist.
  • Es gibt also keine Möglichkeit, eine Aufgabe auszuführen, abhängig davon, ob eine Liste von Variablen definiert sind oder nicht, zusammen mit einem Scheck für OS? Es funktioniert für ein, wie diese when: ansible_os_family and security is not defined aber nicht mehrere...
  • Ja, es kann nur ein is defined und, wenn ich mich richtig erinnere sollte es sein am Ende. Das problem ist, dass Ansible intern immer vor eine Ausnahme, wenn eine variable nicht definiert ist. Dann sieht es für defined Zustand und wenn es dort ist, ist es die Ausnahme behandelt, statt zu scheitern. Aber es kann nicht mit mehreren Bedingungen. Müssten Sie überarbeiten Sie den code entweder zu enthalten default filter oder zusätzliche Tatsachen nur für die Zwecke der überprüfung.
InformationsquelleAutor Jay | 2017-06-30
  1. 9

    War es eine so einfache Antwort!

    Folgende Werke:

    when: not (security is defined or kernel is defined or specified_packages is defined) and ansible_os_family == "RedHat"
    InformationsquelleAutor Jay
  2. 3

    Als @techraf angemerkt in den Kommentaren, defined/undefined ist eine böse test...

    Umgestalten wie diese:

    when:
  - ansible_os_family == "RedHat"
  - security|d('') != '' or kernel|d('') != '' or specified_packages|d('') != ''

    Update. Reproduzierbare Beispiel:

    - hosts: localhost
  gather_facts: no
  tasks:
    - debug:
        msg: hello
      when:
        - '"RedHat" == "RedHat"'
        - security|d('') != '' or kernel|d('') != '' or specified_packages|d('') != ''

    Ausführung:

    ansible-playbook -e kernel=true playbook.yml

PLAY [localhost] ***************************************************************

TASK [debug] *******************************************************************
ok: [localhost] => {
    "msg": "hello"
}

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

    Versionen:

    $ pip list | grep -iP 'ansible|jinja'
ansible (2.2.1.0)
Jinja2 (2.8)
    • Leider funktioniert Es nur für ein..Wenn ich geben Sie die ersten Variablen, die es funktioniert gut, aber wenn ich geben Sie die zweite variable, wirft er den Fehler:"the field 'args' has an invalid value, which appears to include a variable that is undefined. The error was: 'kernel' is undefined\n\nThe error appears to have been in
    • Welche Versionen von Ansible und Jinja2 verwenden Sie? Dieser Ausdruck funktioniert gut mit neueren Versionen: es wird die Aufgabe ausgeführt wird, wenn os ist RedHat UND jeder von security - /kernel/specified_packages eingestellt ist.
    • Nicht sicher, wie Sie die Jinja-version wurde aber auf ansible 2.2.0 nur updates zu 2.3.1 zu sehen, ob das funktioniert, aber kein Glück. Die bedingte Prüfung für os UND die erste definierte variable Kombination funktioniert, aber wenn ich eine variable definieren, das nicht in den ersten slot wirft er eine Fehlermeldung über die erste variable nicht definiert wird. e.g wenn ich sage, kernel = true es sagt, die Sicherheit ist nicht definiert
    • Außerdem was will |d do in Jinja..kann nicht scheinen, um es zu finden online?
    • Hinzugefügt reproduzierbare Beispiel. d ist alias für Standard
    • Ah, scheint ein wenig Verwirrung, ich will die Aufgabe zu überspringen, wenn der kernel/security/specified_packages ist auf true festgelegt (definiert). Ich habe versucht, zu machen != zu ==, aber das funktioniert nicht.. ich bin ein noob. Auch meine Versionen sind: ansible (2.3.1.0) Jinja2 (2.7.2)
    • Es sieht aus wie der jinja |d funktioniert nicht wie der Wert ist true, vor und nach aber die Bedingungen noch laufen..TASK [common : debug] ok: [host] => { "msg": "true" } TASK [common : debug] ok: [host] => { "msg": "hello" } TASK [common : debug] ok: [host] => { "msg": "true" }

    InformationsquelleAutor Konstantin Suvorov
Schreibe einen Kommentar