Django

Configura y actualiza un proyecto de Django. Requiere Ansible 2.8 o superior.

Requisitos

Cuando se usa become (es decir, django_user no es igual a ansible_user o ansible_ssh_user), es necesario tener instalados los paquetes del sistema operativo necesarios para soportar become_method (por ejemplo, sudo) antes de usar este rol.

El proyecto de Django debe estar disponible en el host objetivo antes de ejecutar este rol (a través de SCM checkout, rsync, etc.). El rol cchurch.scm puede ser útil para recuperar un proyecto de Django desde git/hg/svn.

Las dependencias de paquetes del sistema operativo y de Python para el proyecto, incluyendo Django, deben estar instaladas antes de ejecutar este rol. El rol cchurch.virtualenv puede ser útil para instalar paquetes y crear un entorno virtual para ejecutar Django.

Variables del Rol

Las siguientes variables se pueden definir para personalizar este rol:

• django_app_path: Ruta del directorio que contiene el proyecto de Django (requerido).
• django_user: El usuario que se utilizará para ejecutar comandos de Django (por defecto es ansible_user o ansible_ssh_user).
• django_directories: Lista de directorios que se crearán para soportar el proyecto de Django (para archivos de registro, medios subidos, etc.); por defecto está []. Cada elemento de la lista puede ser una cadena simple que especifique el nombre del directorio o un hash que contenga las claves path, owner, group y mode.
• django_settings_templates: Lista de plantillas para instalar con configuraciones personalizadas de Django, por defecto está []. Cada elemento de la lista debe ser un hash que contenga las claves src y dest, y también puede especificar parámetros como owner, group, mode, backup y force. Se crearán los directorios principales si es necesario antes de instalar los archivos de configuración; las claves dir_owner, dir_group y dir_mode pueden establecerse para especificar las opciones de propiedad y permisos para los directorios principales que difieren de los archivos de configuración.
• django_settings: Ruta a la configuración de Django para ejecutar comandos de Django (por ejemplo, proj.settings); por defecto está omit.
• django_virtualenv: Ruta del directorio que contiene el entorno virtual que debe activarse antes de ejecutar comandos de Django; por defecto está omit.
• django_pre_commands: Lista de comandos adicionales de Django a ejecutar antes de los comandos principales; por defecto está [].
• django_main_commands: Lista de comandos de Django a ejecutar para actualizaciones normales del proyecto; por defecto está [{command: "migrate", run_once: true}, "collectstatic"].
• django_post_commands: Lista de comandos adicionales de Django a ejecutar después de los comandos principales; por defecto está [].
• django_run_once_host: Nombre del host que se usará para ejecutar comandos de Django que especifiquen run_once; por defecto es "{{ ansible_play_hosts_all[0] }}" para apuntar al primer host especificado en la obra.

Cada elemento en la lista de comandos anteriores puede ser especificado como una cadena con solo el nombre del comando o como un hash con una clave command y cualquier otra opción soportada por el módulo django_manage, por ejemplo:

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

Cada elemento puede especificar una expresión condicional changed_when que se evaluará para determinar si el comando realizó algún cambio; la variable result estará disponible para la expresión y contendrá el resultado de esa invocación particular del módulo django_manage.

Cada elemento también puede especificar la opción run_once, que hace que la tarea solo se ejecute en un host en lugar de en todos los hosts dirigidos por la obra. El elemento también puede especificar run_once_host para sobrescribir el nombre de host predeterminado especificado a través de django_run_once_host.

La siguiente variable puede ser definida para la invocación de la obra o del rol (pero no funcionará si se define como una variable de grupo o de host del inventario):

• django_notify_on_updated: Nombre del controlador a notificar cuando se realicen cambios mientras se actualiza el proyecto de Django. El predeterminado es "django updated"; se recomienda que los controladores personalizados escuchen "django updated" en lugar de cambiar el nombre de la notificación.

Este rol puede ejecutar comandos de gestión de Django como otro usuario, especificado por django_user, y utilizará el become_method especificado para el host/obra/tarea para cambiar a este usuario. Es posible que necesites definir allow_world_readable_tmpfiles en tu ansible.cfg (lo que generará una advertencia en lugar de un error) o usar otro enfoque para soportar que un usuario sin privilegios se convierta en otro usuario sin privilegios.

Ejemplo de Playbook

El siguiente ejemplo de playbook configura y actualiza un proyecto de Django, notificando a un controlador personalizado cuando se realiza algún cambio:

- 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: proyecto de Django actualizado
      debug:
        msg: "¡El proyecto de Django en {{ django_app_path }} ha sido actualizado!"
      listen: django updated

Licencia

BSD

Información del Autor

Chris Church (cchurch)