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 aplicação 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 aplicação en un entorno de producción existente. Específicamente, con WordPress ejecutándose en PHP, implementé una aplicação 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 aplicação 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 iniciar proyecto 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 migrar

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 aplicação:

   ALLOWED_HOSTS = [' nombre-de-dominio ']

   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 aplicação (ver Paso 9).

   RAÍZ_ESTÁTICA = '/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 aplicação):

   $ 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.

   # Grupo ascendente para el backend (unidad NGINX que ejecuta la aplicação Python)
   unidad django ascendente {
   zona django_unit 64k;
   servidor 127.0.0.1:8000;
   }
   
   servidor {
   escuchar 8080;
   # Descomente para recopilar métricas si usa NGINX Plus y la API de NGINX Plus
   #zona_de_estado django;
   
   # habilitar el almacenamiento en caché
   caché proxy caché django;
   proxy_cache_valid 200 60m;
   
   # directorio raíz para archivos estáticos
   raíz /var/www/djapp/djapp;
   
   # proxy al backend de la unidad NGINX
   ubicación / {
   contraseña_proxy <a href="http://django_unit;">http://unidad_django;</a>
   
   # El segundo argumento debe coincidir con el nombre de host de producción y el valor de
   # ALLOWED_HOSTS en settings.py
   encabezado_conjunto_proxy Host $host;
   
   # Descomente para habilitar las comprobaciones de estado activas si usa NGINX Plus
   #chequeo_de_salud;
   }
   
   # Ubicación de los archivos estáticos recopilados de Django y servidos por
   # NGINX Plus; puede estar vacío (como aquí), porque hereda el valor de la
   # Directiva 'root' de su bloque padre
   ubicación /estática {
   }
   }

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 aplicação.

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/unidad

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

   $ sudo nano django.config

   Agregue el siguiente JSON, que representa nuestra aplicação Python.

   {
   "tipo": "python",
   "procesos": 5,
         "módulo": "djapp.wsgi",
         "ruta": "/var/www/djapp"
   }

4. Ejecute este comando curl para cargar el JSON contenido en django.config como un nuevo objeto de aplicação 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/ aplicações/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 aplicação 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, aplicações es el padre de los objetos de aplicação y djapp es el nombre del nuevo objeto de aplicação .

5. Define el objeto de escucha para la aplicação. 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 aplicação djapp escucha en el puerto 8000.

   $ sudo curl -X PUT --data-binary '{"aplicação":"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 aplicação Python, djapp , resaltada en naranja:

   $ sudo curl --unix-socket /run/control.unit.sock http://localhost/config/ { "oyentes": { "127.0.0.1:8090": { "aplicação": "script_index_php" }, "127.0.0.1:8091": { "aplicação": "direct_php" }, "*:8000": { "aplicação": "djapp" } }, "aplicações": { "script_index_php": { "tipo": "php", "procesos": { "máximo": 20, "repuesto": 5 }, "usuario": "www-data", "grupo": "www-data", "raíz": "/var/www/wordpress", "script": "index.php" }, "direct_php": { "tipo": "php", "procesos": { "máximo": 5, "repuesto": 0 }, "usuario": "www-data", "grupo": "www-data", "raíz": "/var/www/wordpress", "índice": "index.php" }, "djapp": { "tipo": "python", "procesos": 5, "módulo": "djapp.wsgi", "ruta": "/var/www/djapp" } } }

resumen

En esta publicación comenzamos con NGINX Unit ejecutando aplicações PHP para WordPress en producción y agregamos una aplicação Python. En la demostración, uso el panel NGINX Plus para mostrar que no hay interrupciones en las aplicações existentes cuando se agrega una nueva aplicação , 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 aplicações en ejecución y garantiza cero tiempos de inactividad en nuevas implementaciones y una transición fluida entre versiones de aplicação .

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