marcusianlevine.django-container

conteneur-ansible-django

Ajoute un service Django alimenté par Gunicorn à votre projet Ansible Container. Exécutez les commandes suivantes pour installer le service :

# Définir le répertoire de travail à la racine de votre projet Ansible Container
$ cd monprojet

# Installer le service
$ ansible-container install marcusianlevine.ansible-django-container

Exigences

Ansible Container

Un projet Ansible Container existant. Pour créer un projet, exécutez simplement la commande suivante :

# Créer un répertoire de projet vide
$ mkdir monprojet

# Définir le répertoire de travail au nouveau répertoire
$ cd monprojet

# Initialiser le projet
$ ansible-container init

Par défaut, ce rôle crée un utilisateur dans le conteneur nommé "django". Lors du déploiement, le processus d'entrée du conteneur doit être exécuté en tant que cet utilisateur.
Le fichier requirements.txt de votre projet django doit contenir gunicorn.
En plus d'exécuter collectstatic et d'incorporer vos fichiers statiques dans l'image Docker résultante, ce rôle prend également en charge le transfert de vos fichiers statiques vers, par exemple, un conteneur nginx via des volumes docker.
- Ce comportement est obtenu en copiant les fichiers statiques vers le conducteur, afin qu'ils puissent ensuite être copiés vers tout autre conteneur construit par le même pipeline ansible-container.

Variables de rôle

Remarque : pour aider à garder la distinction entre les variables Ansible et les variables d'environnement, les variables dans le contexte Ansible seront en minuscules (this_is_ansible), tandis que les variables d'environnement seront toujours en majuscules (ENVIRONMENT_VARIABLE).

Variables de rôle Ansible

Ces variables peuvent être remplacées soit dans container.yml lors de l'inclusion du rôle, soit en spécifiant vos variables dans un fichier et en les incluant dans container.yml sous la variable de rôle var_files en tant que chemins relatifs à /src (le chemin sur le conducteur ansible-container où le code source de votre projet est monté).

project_name: nom de votre dossier de projet Django et de l'application du projet (suppose une structure de dossier django standard)
django_environment: dictionnaire des définitions de variables d'environnement qui seront injectées dans le script postactivate de virtualenv (voir defaults/main.yml pour un exemple)
requirements_file: si le fichier requis de votre application django ne se trouve pas à la racine de votre dépôt, cela peut être utilisé pour spécifier le chemin relatif
core_source_files: par défaut, requirements_file et le répertoire de premier niveau dans votre dépôt dont le nom correspond à project_name seront intégrés dans le conteneur. Des fichiers sources supplémentaires qui doivent être intégrés dans l'image peuvent être spécifiés ici.
django_static_root: spécifie le répertoire où Django collectera les fichiers statiques. Cela doit correspondre à la valeur de STATIC_ROOT dans vos paramètres Django, ou être chargé avec os.environ à partir d'une variable d'environnement postactivate spécifiée dans django_environment.
django_media_root: même fonction que django_static_root mais pour le paramètre MEDIA_ROOT de Django.
manage_path: emplacement du script manage.py du projet, par défaut au répertoire de premier niveau correspondant à project_name.
django_rpm_deps et django_apt_deps: liste des noms de packages pour soit apt ou yum, selon votre distribution cible (notez que le même package peut avoir un nom légèrement différent dans l'autre dépôt de packages).
script_templates: fournissez une liste de chemins relatifs à /src (le chemin sur le conducteur ansible-container où votre projet est monté) pour des fichiers de script supplémentaires Jinja2 (ou texte brut) que vous souhaitez intégrer dans votre image à /usr/bin/
- Remarque : l'extension finale de chaque nom de fichier sera tronquée, donc scripts/gunicorn_start.j2 serait modélisé dans l'image comme /usr/bin/gunicorn_start.
bundle_build_cmd: si vous devez construire un bundle webpack ou similaire, fournissez la commande à exécuter ici.
- Remarque : toutes les dépendances système requises pour que cette commande de construction fonctionne doivent être installées avant ce rôle.
bundle_build_dir: répertoire à partir duquel exécuter bundle_build_cmd, par défaut à manage_path.
virtualenv_python_version: exécutable Python avec version, par défaut python2.7.
pip_command: commande utilisée pour exécuter pip, par défaut pip, un autre exemple est pip3.
pip_path: chemin absolu vers l'exécutable pip, par défaut /usr/bin/{{ pip_command }}.

Variables d'environnement

Les variables d'environnement suivantes doivent être définies par votre service django dans container.yml pour déployer ce rôle.

DJANGO_PORT: numéro de port sur lequel l'application django doit être servie.
DJANGO_VENV: chemin absolu vers l'emplacement où vivra l'environnement virtuel Python de l'application django (par défaut : /venv).
DJANGO_USER: nom de l'utilisateur qui possédera tous les fichiers de l'application et exécutera le processus de l'application (par défaut : django).

Des valeurs par défaut raisonnables sont fournies sous forme de variables de rôle Ansible en minuscules pour toutes ces valeurs, qui peuvent être injectées dans le tag environment de votre container.yml avec des guillemets et des accolades YAML (par exemple, DJANGO_VENV: '{{ django_venv }}')

Injection de secrets Vault

Actuellement, ansible-container ne prend pas en charge directement les fichiers et variables chiffrés Vault dans container.yml, mais vous pouvez intégrer des secrets dans vos images en utilisant ansible-playbook exécuté depuis le conducteur.

Dans ce rôle, la variable django_environment est un dictionnaire de variables d'environnement qui seront placées dans un script postactivate qui doit être exécuté avant chaque appel de manage.py de Django.

IMPORTANT : cela signifie que tous les secrets qui sont persistés dans l'image cible seront visibles dans l'image elle-même (sauf s'ils sont aplatis lors du déploiement), ainsi que par inspection sur une instance en cours d'exécution de votre image.

C'est la meilleure solution actuellement disponible pour intégrer des secrets de manière programmatique en utilisant ansible-container ; tant que vous ne publiez pas vos images construites dans un registre de conteneurs public, cela ne devrait pas poser de problème.