Django

Configurer et mettre à jour un projet Django. Nécessite Ansible 2.8 ou version ultérieure.

Exigences

Lorsque become est utilisé (c'est-à-dire que django_user n'est pas égal à ansible_user ou ansible_ssh_user), les paquets nécessaires du système d'exploitation pour soutenir become_method (par exemple sudo) doivent être installés avant d'utiliser ce rôle.

Le projet Django doit être disponible sur l'hôte cible avant d'exécuter ce rôle (via SCM checkout, rsync, etc.). Le rôle cchurch.scm peut être utile pour récupérer un projet Django depuis git/hg/svn.

Les dépendances de paquets du système d'exploitation et de Python pour le projet, y compris Django lui-même, doivent être installées avant d'exécuter ce rôle. Le rôle cchurch.virtualenv peut être utile pour installer les paquets et créer un environnement virtuel pour exécuter Django.

Variables du rôle

Les variables suivantes peuvent être définies pour personnaliser ce rôle :

• django_app_path: Répertoire contenant le projet Django (obligatoire).
• django_user: Utilisateur sous lequel exécuter les commandes Django (par défaut, c'est ansible_user ou ansible_ssh_user).
• django_directories: Liste des répertoires à créer pour le projet Django (pour les fichiers journaux, les médias téléchargés, etc.) ; par défaut, c'est []. Chaque élément de la liste peut être une chaîne unique spécifiant le nom du répertoire ou un hachage contenant les clés path, owner, group et mode.
• django_settings_templates: Liste de modèles à installer avec des paramètres Django personnalisés, par défaut []. Chaque élément de la liste devrait être un hachage contenant les clés src et dest, et peut également spécifier owner, group, mode, backup et force. Les répertoires parents seront créés si nécessaire avant l'installation des fichiers de paramètres ; les clés dir_owner, dir_group et dir_mode peuvent être définies pour spécifier les options de propriété et de permission pour les répertoires parents qui diffèrent des fichiers de paramètres.
• django_settings: Chemin Python pointé vers le module de paramètres Django pour exécuter les commandes Django (par exemple, proj.settings) ; par défaut, c'est omit.
• django_virtualenv: Répertoire contenant l'environnement virtuel à activer avant d'exécuter les commandes Django ; par défaut, c'est omit.
• django_pre_commands: Liste des commandes Django supplémentaires à exécuter avant les commandes principales ; par défaut, c'est [].
• django_main_commands: Liste des commandes Django à exécuter pour les mises à jour normales du projet ; par défaut, c'est [{command: "migrate", run_once: true}, "collectstatic"].
• django_post_commands: Liste des commandes Django supplémentaires à exécuter après les commandes principales ; par défaut, c'est [].
• django_run_once_host: Nom d'hôte à utiliser pour exécuter les commandes Django spécifiant run_once ; par défaut, c'est "{{ ansible_play_hosts_all[0] }}" pour cibler le premier hôte spécifié dans le play.

Chaque élément de la liste des commandes ci-dessus peut être spécifié comme une chaîne avec seulement le nom de la commande ou comme un hachage avec une clé command et toutes les autres options prises en charge par le module django_manage, par exemple :

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

Chaque élément peut spécifier une expression conditionnelle changed_when qui sera évaluée pour déterminer si la commande a effectué des modifications ; la variable result sera mise à disposition pour l'expression et contiendra le résultat de cette invocation particulière du module django_manage.

Chaque élément peut également spécifier l'option run_once, qui fait en sorte que la tâche ne s'exécute que sur un seul hôte au lieu de tous les hôtes ciblés par le play. L'élément peut également spécifier run_once_host pour remplacer le nom d'hôte par défaut spécifié via django_run_once_host.

La variable suivante peut être définie pour le jeu ou l'invocation du rôle (mais ne fonctionnera pas si définie comme une variable de groupe ou d'hôte dans l'inventaire) :

• django_notify_on_updated: Nom du gestionnaire à notifier lorsque des modifications ont été apportées lors de la mise à jour du projet Django. La valeur par défaut est "django updated" ; il est généralement recommandé que les gestionnaires personnalisés écoutent "django updated" au lieu de changer le nom de notification.

Ce rôle peut exécuter des commandes de gestion Django en tant qu'autre utilisateur, spécifié par django_user, et utilisera le become_method spécifié pour l'hôte/play/tâche afin de passer à cet utilisateur. Vous devrez peut-être définir allow_world_readable_tmpfiles dans votre ansible.cfg (ce qui générera toujours un avertissement au lieu d'une erreur) ou utiliser une autre approche pour permettre à un utilisateur non privilégié de devenir un autre utilisateur non privilégié.

Exemple de Playbook

Le playbook d'exemple suivant configure et met à jour un projet Django, notifiant un gestionnaire personnalisé lorsque des modifications ont été apportées :

- 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: projet Django mis à jour
      debug:
        msg: "Le projet Django dans {{ django_app_path }} a été mis à jour !"
      listen: django updated

Licence

BSD

Informations sur l'auteur

Chris Church (cchurch)