cchurch.django

Django

Konfigurieren und Aktualisieren eines Django-Projekts. Benötigt Ansible 2.8 oder neuer.

Anforderungen

Wenn become verwendet wird (d.h. django_user ist ungleich ansible_user oder ansible_ssh_user), müssen die erforderlichen Betriebssystem-Pakete für die Unterstützung der become_method (z.B. sudo) vor der Verwendung dieser Rolle installiert werden.

Das Django-Projekt muss vor der Ausführung dieser Rolle auf dem Zielhost verfügbar gemacht werden (z.B. über SCM-Checkout, rsync usw.). Die Rolle cchurch.scm könnte hilfreich sein, um ein Django-Projekt von git/hg/svn auszutauschen.

Die OS- und Python-Paketabhängigkeiten für das Projekt, einschließlich Django selbst, müssen vor der Ausführung dieser Rolle installiert werden. Die Rolle cchurch.virtualenv könnte nützlich sein, um Pakete zu installieren und eine Virtualenv für die Ausführung von Django zu erstellen.

Rollenvariablen

Die folgenden Variablen können definiert werden, um diese Rolle anzupassen:

django_app_path: Verzeichnis, das das Django-Projekt enthält (erforderlich).
django_user: Benutzer, der für die Ausführung von Django-Befehlen verwendet wird (Standard ist ansible_user oder ansible_ssh_user).
django_directories: Liste der Verzeichnisse, die erstellt werden sollen, um das Django-Projekt zu unterstützen (für Protokolldateien, hochgeladene Medien usw.); Standard ist []. Jedes Element in der Liste kann ein einzelner String für den Verzeichnisnamen oder ein Hash mit den Schlüsseln path, owner, group und mode sein.
django_settings_templates: Liste von Vorlagen, die mit benutzerdefinierten Django Einstellungen installiert werden; Standard ist []. Jedes Element in der Liste sollte ein Hash sein, das die Schlüssel src und dest enthält und auch die Parameter owner, group, mode, backup und force angeben kann. Übergeordnete Verzeichnisse werden bei Bedarf erstellt, bevor die Einstellungsdateien installiert werden; die Schlüssel dir_owner, dir_group und dir_mode können festgelegt werden, um Eigentum und Berechtigungsoptionen für die übergeordneten Verzeichnisse anzugeben, die sich von den Einstellungsdateien unterscheiden.
django_settings: Python-Punktpfad zum Django-Einstellungsmodul für die Ausführung von Django-Befehlen (z.B. proj.settings); Standard ist omit.
django_virtualenv: Verzeichnis, das die Virtualenv enthält, die vor der Ausführung von Django-Befehlen aktiviert werden soll; Standard ist omit.
django_pre_commands: Liste zusätzlicher Django-Befehle, die vor den Haupt Befehlen ausgeführt werden sollen; Standard ist [].
django_main_commands: Liste der Django-Befehle, die für normale Projektaktualisierungen ausgeführt werden sollen; Standard ist [{command: "migrate", run_once: true}, "collectstatic"].
django_post_commands: Liste zusätzlicher Django-Befehle, die nach den Haupt Befehlen ausgeführt werden sollen; Standard ist [].
django_run_once_host: Hostname, der für die Ausführung von Django-Befehlen verwendet wird, die run_once angeben; Standard ist "{{ ansible_play_hosts_all[0] }}", um den ersten im Spiel angegebenen Host anzusprechen.

Jedes Element in einer der oben genannten Befehlsliste kann als String mit nur dem Befehlsnamen oder als Hash mit einem command-Schlüssel und allen anderen Optionen, die vom django_manage Modul unterstützt werden, angegeben werden, z.B.:

- check
- command: migrate
  skip: yes
  run_once: yes
  run_once_host: worker
- command: collectstatic
  link: yes
- command: my_custom_command --noinput
  changed_when: '"created" in result.stdout'

Jedes Element kann einen changed_when bedingten Ausdruck angeben, der ausgewertet wird, um zu bestimmen, ob der Befehl Änderungen vorgenommen hat; die result-Variable wird für den Ausdruck verfügbar sein und das Ergebnis dieses bestimmten Aufrufs des django_manage Moduls enthalten.

Jedes Element kann auch die Option run_once angeben, was bewirkt, dass die Aufgabe nur auf einem Host anstatt auf allen Hosts, die im Spiel angezielt werden, ausgeführt wird. Das Element kann auch run_once_host angeben, um den standardmäßig angegebenen Hostnamen über django_run_once_host zu überschreiben.

Die folgende Variable kann für den Play- oder Rollenaufruf definiert werden (funktioniert jedoch nicht, wenn sie als Inventargruppe oder Hostvariable definiert ist):

django_notify_on_updated: Handler-Name, um zu benachrichtigen, wenn Änderungen vorgenommen wurden, während das Django-Projekt aktualisiert wurde. Der Standardwert ist "django updated"; es wird im Allgemeinen empfohlen, dass benutzerdefinierte Handler auf "django updated" hören, anstatt den Benachrichtigungsnamen zu ändern.

Diese Rolle kann Django-Managementbefehle als ein anderer Benutzer, der durch django_user angegeben ist, ausführen und verwendet die become_method, die für den Host/Play/Aufgabe angegeben ist, um zu diesem Benutzer zu wechseln. Möglicherweise müssen Sie allow_world_readable_tmpfiles in Ihrer ansible.cfg definieren (was dennoch eine Warnung statt eines Fehlers erzeugt) oder einen anderen Ansatz verwenden, um zu unterstützen, dass ein nicht privilegierter Benutzer zu einem anderen nicht privilegierten Benutzer wechselt.

Beispiel Playbook

Das folgende Beispiel-Playbook konfiguriert und aktualisiert ein Django-Projekt, das einen benutzerdefinierten Handler benachrichtigt, wenn irgendetwas geändert wurde:

- hosts: all
  vars:
    django_app_path: ~/src
    django_virtualenv: ~/env
    django_settings_templates:
      - src: local_settings.py.j2
        dest: ~/src/myproj/local_settings.py
    django_settings: myproj.settings
    django_pre_commands:
      - command: test
        failfast: yes
      - validate
    django_post_commands:
      - command: loaddata
        fixtures: defaults.json
  roles:
    - role: cchurch.django
  handlers:
    - name: django project updated
      debug:
        msg: "Django-Projekt in {{ django_app_path }} wurde aktualisiert!"
      listen: django updated