marcusianlevine.django-container

ansible-django-container

Dodaje usługę Django działającą na Gunicornie do Twojego projektu Ansible Container. Wykonaj następujące polecenia, aby zainstalować usługę:

# Ustaw katalog roboczy na główny katalog projektu Ansible Container
$ cd myproject

# Zainstaluj usługę
$ ansible-container install marcusianlevine.ansible-django-container

Wymagania

Ansible Container

Istniejący projekt Ansible Container. Aby stworzyć projekt, po prostu uruchom to:

# Utwórz pusty katalog projektu
$ mkdir myproject

# Ustaw katalog roboczy na nowy katalog
$ cd myproject

# Zainicjuj projekt
$ ansible-container init

Domyślnie ta rola tworzy użytkownika w kontenerze o nazwie "django". Podczas wdrażania, proces startowy kontenera powinien być uruchamiany jako ten użytkownik.
W pliku requirements.txt Twojego projektu Django musi być gunicorn.
Oprócz uruchamiania collectstatic i osadzania statycznych plików w tworzonym obrazie Docker, ta rola również wspiera transfer statycznych plików do np. kontenera nginx za pomocą woluminów docker.
- Tę funkcjonalność osiąga się przez skopiowanie plików statycznych do conductor, aby mogły być skopiowane do dowolnego innego kontenera budowanego przez ten sam pipeline ansible-container.

Zmienne roli

Uwaga: aby zachować różnicę między zmiennymi Ansible a zmiennymi środowiskowymi, zmienne w kontekście Ansible będą pisane małymi literami (this_is_ansible), podczas gdy zmienne środowiskowe zawsze będą pisane wielkimi literami (ENVIRONMENT_VARIABLE).

Zmienne roli Ansible

Te zmienne można nadpisywać zarówno w container.yml podczas włączania roli, jak i przez zdefiniowanie zmiennych w pliku i dołączenie go do container.yml pod zmienną roli var_files jako ścieżki względne do /src (ścieżka na conductor Ansible Container, gdzie montowany jest kod źródłowy projektu).

project_name: nazwa folderu projektu Django oraz aplikacji (zakłada standardową strukturę folderów Django)
django_environment: słownik z definicjami zmiennych środowiskowych, które zostaną wstrzyknięte do skryptu postactivate virtualenv (zobacz defaults/main.yml dla przykładu)
requirements_file: jeśli plik wymagań Twojej aplikacji Django nie znajduje się w głównym katalogu repozytorium, można go użyć do określenia względnej ścieżki pliku
core_source_files: domyślnie requirements_file oraz najwyższy katalog w Twoim repozytorium, którego nazwa pasuje do project_name, będą umieszczone w kontenerze. Dodatkowe pliki źródłowe, które muszą być zbudowane w obrazie, mogą być określone tutaj.
django_static_root: określa katalog, w którym Django zbierze pliki statyczne. Powinno to odpowiadać wartości STATIC_ROOT w ustawieniach Django lub być załadowane z os.environ z zmiennej środowiskowej postactivate określonej w django_environment.
django_media_root: ta sama funkcjonalność co django_static_root, ale dla ustawienia Django MEDIA_ROOT.
manage_path: lokalizacja skryptu manage.py projektu, domyślnie odnosi się do najwyższego katalogu odpowiadającego project_name.
django_rpm_deps oraz django_apt_deps: lista nazw pakietów dla apt lub yum, w zależności od docelowej dystrybucji (należy pamiętać, że ten sam pakiet może mieć nieco inną nazwę w innym repozytorium pakietów).
script_templates: podaj listę ścieżek względnych do /src (ścieżka na conductor Ansible Container, gdzie montowany jest Twój projekt) dla dodatkowych plików skryptów Jinja2 (lub zwykłego tekstu), które chciałbyś umieścić w swoim obrazie w /usr/bin/.
- Uwaga: ostateczne rozszerzenie każdej nazwy pliku zostanie obcięte, więc scripts/gunicorn_start.j2 będzie wstawione do obrazu jako /usr/bin/gunicorn_start.
bundle_build_cmd: jeśli musisz zbudować pakiet webpack lub podobny, podaj tutaj polecenie do uruchomienia.
- Uwaga: wszelkie zależności systemowe wymagane do uruchomienia tego polecenia muszą być zainstalowane przed tą rolą.
bundle_build_dir: katalog, z którego ma być uruchomione bundle_build_cmd, domyślnie odnosi się do manage_path.
virtualenv_python_version: wykonawczy plik Pythona z wersją, domyślnie python2.7.
pip_command: polecenie używane do wykonania pip, domyślnie pip, innym przykładem jest pip3.
pip_path: absolutna ścieżka do wykonywalnego pliku pip, domyślnie /usr/bin/{{ pip_command }}.

Zmienne środowiskowe

Poniższe zmienne środowiskowe muszą być zdefiniowane przez Twoje usługi django w container.yml, aby wdrożyć tę rolę.

DJANGO_PORT: numer portu, na którym aplikacja Django powinna być udostępniona.
DJANGO_VENV: absolutna ścieżka do lokalizacji, w której będzie żył Python virtualenv aplikacji Django (domyślnie: /venv).
DJANGO_USER: nazwa użytkownika, który będzie właścicielem wszystkich plików aplikacji i uruchomi proces aplikacji (domyślnie: django).

Uzasadnione wartości domyślne są dostarczane jako zmienne roli Ansible pisane małymi literami dla wszystkich tych wartości, które mogą być wstrzyknięte do etykiety environment w container.yml z cudzysłowami i klamrami YAML (np. DJANGO_VENV: '{{ django_venv }}').

Wstrzykiwanie tajemnic Vault

Obecnie ansible-container nie obsługuje zaszyfrowanych plików i zmiennych Vault bezpośrednio w container.yml, ale możesz osadzić tajemnice w swoich obrazach, używając ansible-playbook uruchamianego z conductor.

W tej roli, zmienna django_environment jest słownikiem zmiennych środowiskowych, które będą umieszczone w skrypcie postactivate, który musi być uruchamiany przed każdym wywołaniem manage.py Django.

WAŻNE: oznacza to, że jakiekolwiek sekrety, które są przechowywane w docelowym obrazie będą widoczne w samym obrazie (chyba że spłaszczone podczas wdrażania), jak również przez inspekcję działającej instancji twojego obrazu.

To jest obecnie najlepsze dostępne rozwiązanie do programowego osadzania tajemnic przy użyciu ansible-container; o ile nie publikujesz swoich zbudowanych obrazów w publicznym rejestrze kontenerów, nie powinno to stanowić dużego problemu.