cchurch.django

Django

Konfiguruj i aktualizuj projekt Django. Wymaga Ansible 2.8 lub nowszego.

Wymagania

Gdy używane jest become (tj. django_user nie jest równy ansible_user ani ansible_ssh_user), niezbędne pakiety systemowe wspierające become_method (np. sudo) muszą być zainstalowane przed użyciem tej roli.

Projekt Django musi być dostępny na docelowym hoście przed uruchomieniem tej roli (poprzez SCM, rsync itd.). Rola cchurch.scm może być przydatna do sklonowania projektu Django z git/hg/svn.

Wszystkie zależności systemowe i pakiety Pythona, w tym sam Django, muszą być zainstalowane przed uruchomieniem tej roli. Rola cchurch.virtualenv może być przydatna do instalacji pakietów i utworzenia wirtualnego środowiska do uruchamiania Django.

Zmienne roli

Poniższe zmienne mogą być zdefiniowane, aby dostosować tę rolę:

  • django_app_path: Katalog zawierający projekt Django (wymagane).
  • django_user: Użytkownik, który będzie wykonywał polecenia Django (domyślnie to ansible_user lub ansible_ssh_user).
  • django_directories: Lista katalogów do utworzenia dla projektu Django (np. na pliki dziennika, przesyłane media itd.); domyślnie []. Każdy element listy może być pojedynczym ciągiem znaków określającym nazwę katalogu lub hashem zawierającym klucze path, owner, group i mode.
  • django_settings_templates: Lista szablonów do zainstalowania z niestandardowymi ustawieniami Django; domyślnie []. Każdy element listy powinien być hashem zawierającym klucze src i dest, a także może określać parametry owner, group, mode, backup i force. Katalogi nadrzędne zostaną utworzone w razie potrzeby przed zainstalowaniem plików ustawień; klucze dir_owner, dir_group i dir_mode mogą być ustawione, aby określić właściciela i opcje uprawnień dla katalogów nadrzędnych, które różnią się od plików ustawień.
  • django_settings: Pythonowy stropowany ścieżka do modułu ustawień Django dla uruchamiania poleceń Django (np. proj.settings); domyślnie omit.
  • django_virtualenv: Katalog zawierający wirtualne środowisko, które ma być aktywowane przed uruchomieniem poleceń Django; domyślnie omit.
  • django_pre_commands: Lista dodatkowych poleceń Django do uruchomienia przed głównymi poleceniami; domyślnie [].
  • django_main_commands: Lista poleceń Django do wykonania w celu normalnych aktualizacji projektu; domyślnie [{command: "migrate", run_once: true}, "collectstatic"].
  • django_post_commands: Lista dodatkowych poleceń Django do uruchomienia po głównych poleceniach; domyślnie [].
  • django_run_once_host: Nazwa hosta do użycia przy uruchamianiu poleceń Django, które określają run_once; domyślnie "{{ ansible_play_hosts_all[0] }}", co celuje w pierwszy host określony w zadaniu.

Każdy element na liście poleceń powyżej może być określony jako ciąg znaków z nazwą polecenia lub jako hash z kluczem command i dowolnymi innymi opcjami wspieranymi przez moduł django_manage, np.:

- 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'

Każdy element może określać warunek changed_when, który będzie oceniany, aby ustalić, czy polecenie wprowadziło jakiekolwiek zmiany; zmienna result będzie dostępna dla tego wyrażenia i zawierać wynik szczególnego wywołania modułu django_manage.

Każdy element może również określać opcję run_once, która powoduje, że zadanie jest wykonywane tylko na jednym hoście, zamiast na wszystkich hostach docelowych zadania. Element może również określać run_once_host, aby nadpisać domyślną nazwę hosta określoną przez django_run_once_host.

Następująca zmienna może być zdefiniowana dla wykonywania zadania lub wywołania roli (ale nie zadziała, jeśli zdefiniowana jako zmienna grupy lub hosta):

  • django_notify_on_updated: Nazwa handlera, który ma być powiadamiany, gdy jakiekolwiek zmiany zostały wprowadzone podczas aktualizacji projektu Django. Domyślnie jest to "django updated"; zaleca się, aby niestandardowe handlery nasłuchiwały na "django updated", zamiast zmieniać nazwę powiadomienia.

Ta rola może wykonywać polecenia zarządzania Django jako inny użytkownik, określony przez django_user, i będzie korzystać z become_method określonego dla hosta/zadania. Może być konieczne zdefiniowanie allow_world_readable_tmpfiles w ansible.cfg (co nadal wygeneruje ostrzeżenie zamiast błędu) lub użycie innego podejścia, aby umożliwić jednemu nieuprzywilejowanemu użytkownikowi wykorzystanie innego nieuprzywilejowanego użytkownika.

Przykładowy Plik Zadania

Poniższy przykładowy plik zadania konfiguracji i aktualizacji projektu Django, powiadamiając niestandardowy handler, gdy coś zostało zmienione:

- 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: "Projekt Django w {{ django_app_path }} został zaktualizowany!"
      listen: django updated

Licencja

BSD

Informacje o autorze

Chris Church (cchurch)

O projekcie

Configure and update a Django project.

Zainstaluj
ansible-galaxy install cchurch.django
Licencja
other
Pobrania
3.3k
Właściciel
Python/Django/Ansible, will code for sweet tea and beer.