Conferencia NGINX 2018: Configuración de NGINX Unit para aplicações de producción: Servicio a un proyecto Django

NGINX Unit es un servidor de aplicación totalmente dinámico que puede servir para múltiples idiomas, así como para múltiples versiones de cada idioma. Es dinámico en el sentido de que utiliza la API JSON RESTful para realizar cambios en su configuración en la memoria, sin interrumpir el servicio ni recargar la configuración.

En mi presentación en NGINX Conf 2018 en octubre, mostré cómo configurar una nueva aplicación en un entorno de producción existente. Específicamente, con WordPress ejecutándose en PHP, implementé una aplicación Python que utiliza el marco Django. También mostré cómo se puede cargar la configuración tanto desde un archivo como según lo especificado con un argumento en una llamada API.

Este blog incluye todos los comandos y el código de configuración que utilicé en la demostración, para que le resulte más fácil adaptarse a su propia implementación.

Requisitos previos

Para la demostración en NGINX Conf, instalé el siguiente software:

• Ubuntu 16.04
• NGINX Plus, pero puedes usar NGINX de código abierto excepto como se indica
• Unidad NGINX con todos los módulos de idioma instalados
• Python 3
• Django (no configurado: de eso tratan la demostración y este blog)
• privilegio de root , o acceso equivalente a través de sudo (que usamos cuando es necesario)

También tenía PHP y WordPress instalados como aplicación existente.

Creando el proyecto Django

1. Cambia al directorio donde estamos creando nuestro proyecto Django:

   $ cd /var/www/

2. Utilice el comando django-admin startproject para inicializar el nuevo proyecto. Lo llamaremos djapp .

   $ sudo django-admin startproject djapp

3. Cambiar al directorio del proyecto:

   $ cd djapp

4. Utilice el script manage.py para migrar la base de datos del proyecto, lo cual es necesario para un proyecto recién creado. Django usa SQLite por defecto, y acepto el valor predeterminado en la demostración, pero puedes usar cualquier base de datos que satisfaga las necesidades de tu proyecto.

   El script manage.py se instala mediante el comando django-admin que ejecutamos en el Paso 2; realiza los mismos comandos y acepta los mismos argumentos que django-admin , pero deriva y utiliza automáticamente algunas configuraciones específicas del proyecto, lo cual es útil. Para obtener más detalles, consulte la documentación de Django .

   $ sudo python3 manage.py migrate

5. Aunque no es estrictamente necesario para un proyecto de muestra como este, recomendamos que cree una identidad de superusuario de Django:

   $ sudo python3 manage.py createsuperuser

6. Cambie al subdirectorio que contiene el archivo settings.py , que fue creado por el comando django-admin startproject en el Paso 2.

   $ cd /var/www/djapp/djapp

7. Usando su editor de texto preferido, abra settings.py . Aquí estamos usando nano :

   $ sudo nano settings.py

   Busque la línea ALLOWED_HOSTS y agregue el nombre de dominio, el nombre de host o la dirección IP de la aplicación:

   ALLOWED_HOSTS = ['domain-name']

   Agregue también la siguiente línea al final del archivo, para nombrar el directorio que almacena todo el contenido estático servido por la aplicación (ver Paso 9).

   STATIC_ROOT = '/var/www/djapp/djapp/static'

8. Regrese al directorio principal del proyecto (donde reside manage.py ).

   $ cd ..

9. Ejecute el comando manage.py collectstatic para recopilar todos los archivos estáticos ubicados en el proyecto Django y colocarlos en la ubicación STATIC_ROOT definida en el Paso 7.

   $ sudo python3 manage.py collectstatic

Configuración de NGINX

De forma predeterminada, Django mismo sirve el contenido estático para un proyecto, pero NGINX Open Source y NGINX Plus ofrecen un rendimiento superior. Aquí configuramos NGINX Plus, pero puedes usar NGINX Open Source excepto por una característica que se indica a continuación.

1. Cambie el directorio a /etc/nginx/conf.d , la ubicación convencional para los archivos de configuración HTTP específicos de la función (o en nuestro caso, específicos de la aplicación):

   $ cd /etc/nginx/conf.d

2. Crea un archivo llamado django.conf (nuevamente, estamos usando nano ):

   $ sudo nano django.conf

   Inserte la siguiente configuración, que habilita el almacenamiento en caché.

   La configuración también incluye dos características que son exclusivas de NGINX Plus. Descomente las directivas relevantes si está utilizando NGINX Plus y desea aprovechar las funciones:

   • Recopilación de métricas extendidas, habilitada para este servidor virtual mediante la directiva status_zone . Supongo que la API NGINX Plus está habilitada en otra parte de la configuración.
   • Controles de salud activos , habilitados por la directiva health_check .

   Una cosa a tener en cuenta es que en la demostración en NGINX Conf especifiqué la dirección IP de mi máquina local como el segundo argumento de la directiva proxy_set_header . En un entorno de producción, tiene más sentido utilizar la variable $host como se muestra a continuación.

   # Upstream group for the backend (NGINX Unit running the Python application)
   upstream django_unit {
       zone django_unit 64k;
       server 127.0.0.1:8000;
   }
    
   server {
       listen 8080;
       # Uncomment to collect metrics if using NGINX Plus and the NGINX Plus API
       #status_zone django;
         	
       # enable caching
       proxy_cache django_cache;
       proxy_cache_valid 200 60m;
    
       # root directory for static files
       root /var/www/djapp/djapp;
    
       # proxy to the NGINX Unit backend
       location / {
           proxy_pass http://django_unit;
   
           # Second argument must match your production hostname and the value of 
           # ALLOWED_HOSTS in settings.py
           proxy_set_header Host $host; 
    
           # Uncomment to enable active health checks if using NGINX Plus
           #health_check;
       }
   
       # Location for the static files collected from Django and served by 
       # NGINX Plus; can be empty (as here), because it inherits the value of the 
       # 'root' directive from its parent block
       location /static {
       }
   }

3. Compruebe la configuración para comprobar la validez sintáctica:

   $ sudo nginx –t

4. Después de corregir cualquier error, vuelva a cargar la configuración:

   $ sudo nginx -s reload

Configuración de la unidad NGINX

Para finalizar, necesitamos configurar NGINX Unit para atender las solicitudes a la aplicación.

1. Ejecute este comando curl para mostrar la configuración actual de la unidad NGINX, que es para WordPress que se ejecuta en PHP. No muestro la salida aquí, pero la configuración de WordPress aparece en el Paso 6 a continuación, junto con la configuración de la aplicación Python, que estamos a punto de agregar.

   Tenga en cuenta que uso sudo para el comando curl , lo que posiblemente no sea necesario para la mayoría de los comandos curl . Aquí es necesario porque para acceder al socket UNIX necesitamos el permiso de lectura y escritura que tiene root .

   $ sudo curl --unix-socket /run/control.unit.sock http://localhost/config/

2. Cambie al directorio de los archivos de configuración de la unidad NGINX.

   Tenga en cuenta que estos archivos son opcionales y solo una forma conveniente de cargar colecciones de configuración sin escribir todos los datos como argumento para una llamada a la API de NGINX Unit. Debido a que el contenido de los archivos se carga a través de la API (como todos los datos de configuración), NGINX Unit no conoce las ubicaciones de los archivos y no puede leerlos automáticamente al iniciarse (a diferencia de NGINX Open Source y NGINX Plus). En su lugar, NGINX Unit guarda su estado de ejecución en un directorio separado.

   $ cd /etc/unit

3. Crea un archivo llamado django.config (nuevamente, usamos nano ):

   $ sudo nano django.config

   Agregue el siguiente JSON, que representa nuestra aplicación Python.

   {
         "type": "python",
         "processes": 5,
         "module": "djapp.wsgi",
         "path": "/var/www/djapp"
   }

4. Ejecute este comando curl para cargar el JSON contenido en django.config como un nuevo objeto de aplicación que será administrado por NGINX Unit, llamado djapp :

   $ sudo curl -X PUT --data-binary @/etc/unit/django.config --unix-socket /run/control.unit.sock http://localhost/config/applications/djapp

   En este comando:

   • El método HTTP PUT crea un nuevo objeto de configuración de unidad NGINX en la ubicación indicada por el argumento final (la URL). Vea la última viñeta a continuación.
   • El argumento --data-binary le dice a curl que cargue el contenido de django.config exactamente como se proporciona, preservando las nuevas líneas y los retornos de carro, y sin realizar ningún tipo de procesamiento.
   • El argumento --unix-socket define dónde está escuchando la API de unidad NGINX. (Usamos el comando sudo porque usamos el propietario predeterminado del socket, root ).
   • El argumento final ubica y nombra el nuevo objeto de aplicación para completar con los datos de configuración en formato JSON en django.config : config es el objeto de configuración de la unidad NGINX de nivel superior, aplicaciones es el padre de los objetos de aplicación y djapp es el nombre del nuevo objeto de aplicación .

5. Define el objeto de escucha para la aplicación. En lugar de cargar un archivo de datos de configuración como en el Paso 4, definimos los datos directamente en la línea de comando curl , especificando que la aplicación djapp escucha en el puerto 8000.

   $ sudo curl -X PUT --data-binary '{"application":"djapp"}' --unix-socket /run/control.unit.sock 'http://localhost/config/listeners/*:8000'

6. Repita el comando curl del Paso 1 para mostrar la configuración de la unidad NGINX, que ahora incluye nuestra aplicación Python, djapp , resaltada en naranja:

   $ sudo curl --unix-socket /run/control.unit.sock http://localhost/config/{
         "listeners": {
               "127.0.0.1:8090": {
                     "application": "script_index_php"
               },
    
               "127.0.0.1:8091": {
                     "application": "direct_php"
               },
    
               "*:8000": {
              	      "application": "djapp"
               }
         },
    
         "applications": {
               "script_index_php": {
                     "type": "php",
                     "processes": {
                           "max": 20,
                           "spare": 5
                      },
    
                     "user": "www-data",
                     "group": "www-data",
                     "root": "/var/www/wordpress",
                     "script": "index.php"
               },
    
               "direct_php": {
                     "type": "php",
                     "processes": {
                           "max": 5,
                           "spare": 0
                     },
    
                     "user": "www-data",
                     "group": "www-data",
                     "root": "/var/www/wordpress",
                     "index": "index.php"
                     },
    
               "djapp": {
                     "type": "python",
                     "processes": 5,
                     "module": "djapp.wsgi",
                     "path": "/var/www/djapp"
               }
         }
   }

resumen

En esta publicación comenzamos con NGINX Unit ejecutando aplicaciones PHP para WordPress en producción y agregamos una aplicación Python. En la demostración, uso el panel NGINX Plus para mostrar que no hay interrupciones en las aplicaciones existentes cuando se agrega una nueva aplicación , pero se puede usar cualquier herramienta de monitoreo del sistema, como el comando ps , para ese propósito. La naturaleza dinámica de la configuración de la unidad NGINX ahorra recursos para sus aplicaciones en ejecución y garantiza cero tiempos de inactividad en nuevas implementaciones y una transición fluida entre versiones de aplicación .

Para obtener más información, visite unit.nginx.org .