Ansible: Up and Running, 3. Auflage

Kapitel 10. Komplexe Spielbücher

Diese Arbeit wurde mithilfe von KI übersetzt. Wir freuen uns über dein Feedback und deine Kommentare: [e-mail]

Im vorangegangenen Kapitel haben wir ein voll funktionsfähiges Ansible-Playbook für die Bereitstellung des Mezzanine CMS besprochen. Dieses Beispiel verwendet einige gängige Ansible-Funktionen, deckt aber nicht alle ab. In diesem Kapitel geht es um diese anderen Funktionen, was es zu einer Art Wundertüte macht.

Umgang mit schlecht benutzten Befehlen

Erinnere dich daran, dass wir in Kapitel 7 vermieden haben, den in Beispiel 10-1 gezeigten Befehl createdb manage.py aufzurufen, weil der Aufruf nicht idempotent war.

Beispiel 10-1. Aufruf von django manage.py createdb

- name: Initialize the database
  django_manage:
    command: createdb --noinput --nodata
    app_path: "{{ proj_path }}"
    virtualenv: "{{ venv_path }}"

Wir umgingen dieses Problem, indem wir mehrere django manage.py Befehle aufriefen, die idempotent waren und das Äquivalent zu createdb taten. Aber was wäre, wenn wir kein Modul hätten, das äquivalente Befehle aufrufen könnte? Die Antwort ist, die Klauseln changed_when und failed_when zu verwenden, um die Art und Weise zu ändern, wie Ansible erkennt, dass eine Aufgabe ihren Zustand geändert hat oder fehlgeschlagen ist.

Wir wollen sicherstellen, dass du die Ausgabe dieses Befehls beim ersten und zweiten Mal verstehst.

Wie in Kapitel 5 beschrieben, fügst du zum Erfassen der Ausgabe eines fehlgeschlagenen Tasks eine ...