Django es un poderoso framework que puede ayudarle a poner en marcha su aplicación o sitio web con Python. Incluye un servidor de desarrollo simplificado para probar su código a nivel local. Sin embargo, para cualquier cosa que esté incluso apenas relacionada con la producción se requiere un servidor web más seguro y potente.
En esta guía, demostraremos la forma de instalar y configurar algunos componentes en Ubuntu 18.04 para que sean compatibles y permitan que funcionen aplicaciones de Django. Configuraremos una base de datos de PostgreSQL en lugar de usar la base de datos predeterminada de SQLite. Configuraremos el servidor de aplicaciones de Gunicorn para que interactúe con nuestras aplicaciones. Luego, configuraremos Nginx para que invierta el proxy de Gunicorn, lo que nos dará acceso a sus funciones de seguridad y rendimiento para nuestras aplicaciones.
Para completar esta guía, debe disponer de una nueva instancia de servidor de Ubuntu 18.04 con un cortafuegos básico y un usuario no root con privilegios sudo
configurados. Puede aprender a configurar esto en nuestra guía de configuración inicial para servidores.
Instalaremos Django en un entorno virtual. Instalar Django en un entorno específico para nuestro proyecto permitirá que sus proyectos y los requisitos de estos se administren por separado.
Una vez que tengamos nuestra base de datos y la aplicación en funcionamiento, instalaremos y configuraremos el servidor de aplicaciones de Gunicorn. Esto servirá como interfaz para nuestra aplicación, al traducir las solicitudes de los clientes de HTTP a llamadas Python que nuestra aplicación puede procesar. Luego, instalaremos Nginx frente a Gunicorn para aprovechar sus mecanismos de administración de conexiones de alto rendimiento y sus características de seguridad fáciles de implementar.
Comencemos.
Para iniciar este proceso, descargaremos e instalaremos todos los elementos necesarios desde los repositorios de Ubuntu. Usaremos el administrador de paquetes de Python pip
para instalar componentes adicionales más tarde.
Necesitaremos actualizar el índice de paquetes apt
local y luego descargaremos e instalaremos los paquetes. Los paquetes que instalemos dependen de la versión de Python que use en su proyecto.
Si usa Django con Python 3, escriba lo siguiente:
- sudo apt update
- sudo apt install python3-pip python3-dev libpq-dev postgresql postgresql-contrib nginx curl
Django 1.11 es la última versión que será compatible con Python 2. Si inicia nuevos proyectos, le recomendamos totalmente elegir Python 3. Si todavía necesita usar Python 2, escriba lo siguiente:
- sudo apt update
- sudo apt install python-pip python-dev libpq-dev postgresql postgresql-contrib nginx curl
Con esto se instalarán pip
, los archivos de desarrollo de Python necesarios para compilar Gunicorn posteriormente, el sistema de base de datos de Postgres, las bibliotecas necesarias para la interacción con él, y el servidor web de Nginx.
Crearemos una base de datos y un usuario de base de datos para nuestra aplicación de Django.
Por defecto, Postgres usa un esquema de autenticación llamado “autenticación por pares” para las conexiones locales. Básicamente, esto significa que si el nombre de usuario del sistema operativo del usuario coincide con un nombre de usuario de Postgres válido, ese usuario puede iniciar sesión sin autenticaciones adicionales.
Durante la instalación de Postgres, se creó un usuario del sistema operativo llamado postgres
para que se corresponda con el usuario administrativo postgres
de PostgreSQL. Necesitamos usar este usuario para realizar tareas administrativas. Podemos usar sudo y pasar el nombre de usuario con la opción -u
.
Inicie una sesión interactiva de Postgres escribiendo lo siguiente:
- sudo -u postgres psql
Recibirá un mensaje de PostgreSQL en el que se pueden configurar los requisitos.
Primero, cree una base de datos para su proyecto:
- CREATE DATABASE myproject;
Nota: Cada instrucción de Postgres debe terminar con un punto y coma. Por ello, si está experimenta problemas debe asegurarse de que su comando tenga esta terminación.
A continuación, cree un usuario de base de datos para nuestro proyecto. Asegúrese de elegir una contraseña segura.
- CREATE USER myprojectuser WITH PASSWORD 'password';
Más adelante, modificaremos algunos de los parámetros de conexión para el usuario que acabamos de crear. Esto acelerará las operaciones de la base de datos para que no sea necesario consultar y fijar los valores correctos cada vez que se establezca una conexión.
Fijaremos el código predeterminado en UTF-8
, lo que se prevé para Django. También fijaremos el esquema predeterminado de aislamiento de transacciones en “read committed”, que bloquea las lecturas de transacciones no comprometidas. Por último, configuraremos la zona horaria. Por defecto, nuestros proyectos de Django se configurarán para usar la opción UTC
. Estas son todas las recomendaciones del propio proyecto de Django:
- ALTER ROLE myprojectuser SET client_encoding TO 'utf8';
- ALTER ROLE myprojectuser SET default_transaction_isolation TO 'read committed';
- ALTER ROLE myprojectuser SET timezone TO 'UTC';
Ahora, podemos brindar a nuestro nuevo usuario acceso para administrar nuestra nueva base de datos:
- GRANT ALL PRIVILEGES ON DATABASE myproject TO myprojectuser;
Cuando termine, cierre la línea de comandos de PostgreSQL escribiendo lo siguiente:
- \q
Postgres quedará, así, configurado para que Django pueda conectarse y administrar la información de su base de datos.
Ahora que tenemos nuestra base de datos, podemos empezar a cumplir con el resto de los requisitos de nuestro proyecto. Instalaremos los componentes de Python requeridos en un entorno virtual para facilitar la administración.
Para hacerlo, primero necesitamos acceso al comando virtualenv
. Podemos instalarlo con pip
.
Si usa Python 3, actualice pip
e instale el paquete escribiendo lo siguiente:
- sudo -H pip3 install --upgrade pip
- sudo -H pip3 install virtualenv
Si usa** Python 2**, actualice pip
e instale el paquete escribiendo lo siguiente:
- sudo -H pip install --upgrade pip
- sudo -H pip install virtualenv
Con virtualenv
instalado, podemos comenzar a dar forma a nuestro proyecto. Cree y un directorio en el que podamos guardar los archivos de nuestro proyecto y posiciónese en él:
- mkdir ~/myprojectdir
- cd ~/myprojectdir
En el directorio del proyecto, cree un entorno virtual de Python escribiendo lo siguiente:
- virtualenv myprojectenv
Con esto, se creará un directorio llamado myprojectenv
en su directorio myprojectdir
. De forma interna, instalará una versión local de Python y una versión local de pip
. Podemos usar esto para instalar y configurar un entorno aislado de Python para nuestro proyecto.``````
Antes de instalar los componentes de Python requeridos para nuestro proyecto, debemos activar el entorno virtual. Puede hacerlo escribiendo lo siguiente:
- source myprojectenv/bin/activate
Su línea de comandos cambiará para indicar que ahora realiza operaciones en un entorno virtual de Python. Tendrá un aspecto parecido a este: (myprojectenv)user@host:~/myprojectdir$
.``
Con su entorno virtual activo, instale Django, Gunicorn y el adaptador psycopg2
de PostgreSQL con la instancia local de pip
:
Nota: Cuando se active el entorno virtual (cuando (myprojectenv)
se encuentre al inicio de su línea de comandos), use pip
en lugar de pip3
, incluso si emplea Python 3. La copia del entorno virtual de la herramienta siempre se llama pip
, independientemente de la versión de Python.
- pip install django gunicorn psycopg2-binary
Con esto, debería contar con todo el software necesario para iniciar un proyecto en Django.
Una vez instalados nuestros componentes de Python, podemos crear los archivos reales del proyecto en Django.
Debido a que ya disponemos de un directorio de proyectos, le indicaremos a Django que instale los archivos en él. Se creará un directorio de segundo nivel con el código real, lo cual es normal, y se dispondrá una secuencia de comandos de administración en este directorio. La clave para esto es que definiremos el directorio de forma explícita en lugar de permitir que Django tome decisiones vinculadas con nuestro directorio actual:
- django-admin.py startproject myproject ~/myprojectdir
En este punto, el directorio de su proyecto (~/myprojectdir
en nuestro caso) debe tener el siguiente contenido:``
~/myprojectdir/manage.py
: secuencia de comandos de administración del proyecto en Django.~/myprojectdir/myproject/
: paquete de proyectos de Django. Este debería contener los archivos __init__.py
, settings.py
, urls.py
y wsgi.py
.~/myprojectdir/myprojectenv/
: directorio del entorno virtual que creamos antes.Lo primero que debemos hacer con los archivos del proyecto recientemente creado es ajustar la configuración. Abra el archivo de configuración en su editor de texto:
- nano ~/myprojectdir/myproject/settings.py
Localice primero la directiva ALLOWED_HOSTS
. Con esto, se define una lista de las direcciones de los servidores o los nombres de dominio que pueden usarse para establecer una conexión con la instancia en Django. Cualquier solicitud entrante con un encabezado de Host que no figure en esta lista generará una excepción. Django necesita que configure esto para evitar una clase de vulnerabilidad de seguridad determinada.
Dentro de los corchetes, enumere las direcciones IP o los nombres de dominio asociados a su servidor de Django. Cada elemento debe listarse entre comillas y las entradas deben ir separadas por una coma. Si desea solicitudes para un dominio completo y cualquier subdominio, anteponga un punto al comienzo de la entrada. En el fragmento inferior, hay algunos ejemplos comentados que se usan para demostrar lo siguiente:
Nota: Asegúrese de incluir localhost
como una de las opciones, ya que autorizaremos conexiones a través de una instancia local de Nginx.
. . .
# The simplest case: just add the domain name(s) and IP addresses of your Django server
# ALLOWED_HOSTS = [ 'example.com', '203.0.113.5']
# To respond to 'example.com' and any subdomains, start the domain with a dot
# ALLOWED_HOSTS = ['.example.com', '203.0.113.5']
ALLOWED_HOSTS = ['your_server_domain_or_IP', 'second_domain_or_IP', . . ., 'localhost']
A continuación, busque la sección que configura el acceso a la base de datos. Se iniciará con DATABASES
. La configuración del archivo es para una base de datos de SQLite. Ya creamos una base de datos de PostgreSQL para nuestro proyecto. Ahora debemos ajustar las configuraciones.
Cambie las configuraciones por la información de su base de datos de PostgreSQL. Indicaremos a Django que use el adaptador psycopg2
que instalamos con pip
. Debemos proporcionar el nombre de la base de datos, el nombre de usuario y la contraseña del usuario, y luego especificar que la base de datos se encuentra en una computadora local. Puede dejar la configuración de PORT
como una secuencia de comandos vacía:
. . .
DATABASES = {
'default': {
'ENGINE': 'django.db.backends.postgresql_psycopg2',
'NAME': 'myproject',
'USER': 'myprojectuser',
'PASSWORD': 'password',
'HOST': 'localhost',
'PORT': '',
}
}
. . .
A continuación, diríjase hasta la parte inferior del archivo y agregue una configuración que indique dónde deben disponerse los archivos estáticos. Esto es necesario para que Nginx pueda manejar las solicitudes de estos elementos. La siguiente línea indica a Django que los disponga en un directorio llamado static
en el directorio de proyectos de base:
. . .
STATIC_URL = '/static/'
STATIC_ROOT = os.path.join(BASE_DIR, 'static/')
Guarde y cierre el archivo cuando termine.
Ahora, podemos migrar el esquema inicial de la base de datos a nuestra base de datos de PostgreSQL usando la secuencia de comandos de administración:
- ~/myprojectdir/manage.py makemigrations
- ~/myprojectdir/manage.py migrate
Cree un usuario administrativo para el proyecto escribiendo lo siguiente:
- ~/myprojectdir/manage.py createsuperuser
Deberá seleccionar el nombre de usuario, proporcionar una dirección de correo electrónico y elegir y confirmar una contraseña.
Podemos recolectar todo el contenido estático en la ubicación del directorio que configuramos escribiendo lo siguiente:
- ~/myprojectdir/manage.py collectstatic
Deberá confirmar la operación. Luego, los archivos estáticos se ubicarán en un directorio llamado static
, dentro del directorio de su proyecto.
Si siguió la guía de configuración inicial para servidores, debería proteger su servidor con un firewall UFW. Para probar el servidor de desarrollo, tendremos que permitir el acceso al puerto que usaremos.
Cree una excepción para el puerto 8000 escribiendo lo siguiente:
- sudo ufw allow 8000
Por último, puede probar su proyecto iniciando el servidor de desarrollo de Django con este comando:
- ~/myprojectdir/manage.py runserver 0.0.0.0:8000
En su buscador web, agregue :8000
al final del nombre del dominio o de la dirección IP de su servidor y visítelos:
http://server_domain_or_IP:8000
Debería ver la página de índice predeterminada de Django:
Si agrega /admin
al final de la URL en la barra de direcciones, se le solicitará el nombre de usuario administrativo y la contraseña que creó con el comando createsuperuser
:
Después de la autenticación, puede acceder a la interfaz administrativa predeterminada de Django:
Cuando finalice la exploración, presione **CTRL-C **en la ventana de la terminal para desactivar el servidor de desarrollo.
Lo último que nos convendrá hacer antes de cerrar nuestro entorno virtual será probar Gunicorn para asegurarnos de que pueda hacer funcionar la aplicación. Podemos hacerlo ingresando a nuestro directorio de proyectos y usando gunicorn
para cargar el módulo WSGI del proyecto:
- cd ~/myprojectdir
- gunicorn --bind 0.0.0.0:8000 myproject.wsgi
Con esto se iniciará Gunicorn en la misma interfaz en la que se encontraba en ejecución el servidor de desarrollo en Django. Puede volver y probar la aplicación de nuevo.
Nota: No se aplicará el estilo a la interfaz de administración, ya que Gunicorn no tiene forma de encontrar el contenido estático de CSS responsable de este.
Pasamos a Gunicorn un módulo especificando la ruta relativa del directorio al archivo wsgi.py
de Django, que es el punto de entrada a nuestra aplicación, usando la sintaxis del módulo de Python. Dentro de este archivo, se define una función llamada application
, que se usa para comunicarse con la aplicación. Para obtener más información sobre la especificación de WSGI, haga clic aquí.
Cuando termine de realizar las pruebas, presione CTRL-C en la ventana de la terminal para detener Gunicorn.
Con esto habremos terminado de configurar nuestra aplicación en Django. Podemos cerrar nuestro entorno virtual escribiendo lo siguiente:
- deactivate
Se eliminará el indicador del entorno virtual en su línea de comandos.
Comprobamos que Gunicorn puede interactuar con nuestra aplicación en Django, pero debemos implementar un mejor método para iniciar y detener el servidor de la aplicación. Para lograr esto, crearemos archivos de servicio y socket systemd.
El socket Gunicorn se creará en el inicio y escuchará las conexiones. Cuando se establezca una conexión, systemd iniciará de forma automática el proceso de Gunicorn para manejarla conexión.
Comience creando y abriendo un archivo de socket de systemd para Gunicorn con privilegios sudo
:
- sudo nano /etc/systemd/system/gunicorn.socket
Dentro de él, crearemos una sección [Unit]
para describir el socket, una sección [Socket]
para definir la ubicación del socket y una sección [Install]
para asegurarnos de que el socket se cree en el momento adecuado:
[Unit]
Description=gunicorn socket
[Socket]
ListenStream=/run/gunicorn.sock
[Install]
WantedBy=sockets.target
Guarde y cierre el archivo cuando termine.
A continuación, cree y abra un archivo de servicio systemd para Gunicorn con privilegios sudo
en su editor de texto. El nombre del archivo de servicio debe coincidir con el de socket, salvo en la extensión:
- sudo nano /etc/systemd/system/gunicorn.service
Empiece por la sección [Unit]
, que se usa para especificar metadatos y dependencias. Aquí introduciremos una descripción de nuestro servicio e indicaremos al sistema init que lo inicie solo tras haber alcanzado el objetivo de red: Debido a que nuestro servicio se basa en el socket del archivo de sockets, necesitamos incluir una directiva Requires
para indicar esta relación:
[Unit]
Description=gunicorn daemon
Requires=gunicorn.socket
After=network.target
A continuación, abriremos la sección [Service]
. Especificaremos el usuario y el grupo con los cuales deseamos que se ejecute el proceso. Otorgaremos la propiedad del proceso a nuestra cuenta de usuario normal, ya que tiene la propiedad de todos los archivos pertinentes. Otorgaremos la propiedad del grupo al grupo www-data
para que Nginx pueda comunicarse fácilmente con Gunicorn.
Luego, mapearemos el directorio de trabajo y especificaremos el comando que se usará para iniciar el servicio. En este caso, tendremos que especificar la ruta completa al ejecutable de Gunicorn, que está instalado en nuestro entorno virtual. Vincularemos el proceso con el socket de Unix que creamos en el directorio /run
para que el proceso pueda comunicarse con Nginx. Registramos todos los datos a la salida estándar para que el proceso journald
pueda recopilar los registros de Gunicorn. También podemos especificar cualquier ajuste opcional de Gunicorn aquí. Por ejemplo, especificamos 3 procesos de trabajadores en este caso:
[Unit]
Description=gunicorn daemon
Requires=gunicorn.socket
After=network.target
[Service]
User=sammy
Group=www-data
WorkingDirectory=/home/sammy/myprojectdir
ExecStart=/home/sammy/myprojectdir/myprojectenv/bin/gunicorn \
--access-logfile - \
--workers 3 \
--bind unix:/run/gunicorn.sock \
myproject.wsgi:application
Por último, agregaremos una sección [Install]
. Esto indicará a systemd a qué deberá vincular este servicio si lo habilitamos para que se cargue en el inicio. Queremos que este servicio se inicie cuando el sistema multiusuario normal esté en funcionamiento:
[Unit]
Description=gunicorn daemon
Requires=gunicorn.socket
After=network.target
[Service]
User=sammy
Group=www-data
WorkingDirectory=/home/sammy/myprojectdir
ExecStart=/home/sammy/myprojectdir/myprojectenv/bin/gunicorn \
--access-logfile - \
--workers 3 \
--bind unix:/run/gunicorn.sock \
myproject.wsgi:application
[Install]
WantedBy=multi-user.target
Con eso, nuestro archivo de servicio de systemd quedará completo. Guárdelo y ciérrelo ahora.
Ahora podemos iniciar y habilitar el socket de Gunicorn. Con esto se creará el archivo de socket en /run/gunicorn.sock
ahora y en el inicio. Cuando se establezca una conexión con ese socket, systemd iniciará gunicorn.service
de forma automática para gestionarla:
- sudo systemctl start gunicorn.socket
- sudo systemctl enable gunicorn.socket
Podemos confirmar que la operación se haya completado con éxito revisando el archivo de sockets.
Compruebe el estado del proceso para saber si pudo iniciar lo siguiente:
- sudo systemctl status gunicorn.socket
A continuación, compruebe la existencia del archivo gunicorn.sock
en el directorio /run
:
- file /run/gunicorn.sock
Output/run/gunicorn.sock: socket
Si el comando systemctl status
indica que se produjo un error o si no encuentra el archivo gunicorn.sock
en el directorio, significa que no se pudo crear de forma correcta el socket de Gunicorn. Verifique los registros del socket de Gunicorn escribiendo lo siguiente:
- sudo journalctl -u gunicorn.socket
Vuelva a revisar su archivo /etc/systemd/system/gunicorn.socket
para solucionar cualquier problema antes de continuar.
En este punto, si solo inició la unidad gunicorn.socket
, gunicorn.service
aún no estará activo, ya que el socket aún no habrá recibido conexiones. Puede comprobarlo escribiendo lo siguiente:
- sudo systemctl status gunicorn
Output● gunicorn.service - gunicorn daemon
Loaded: loaded (/etc/systemd/system/gunicorn.service; disabled; vendor preset: enabled)
Active: inactive (dead)
Para probar el mecanismo de activación de sockets, podemos enviar una conexión al socket a través de curl
escribiendo lo siguiente:
- curl --unix-socket /run/gunicorn.sock localhost
Debería ver el resultado HTML de su aplicación en la terminal. Esto indica que Gunicorn se inició y pudo presentar su aplicación de Django. Puede verificar que el servicio de Gunicorn funcione escribiendo lo siguiente:
- sudo systemctl status gunicorn
Output● gunicorn.service - gunicorn daemon
Loaded: loaded (/etc/systemd/system/gunicorn.service; disabled; vendor preset: enabled)
Active: active (running) since Mon 2018-07-09 20:00:40 UTC; 4s ago
Main PID: 1157 (gunicorn)
Tasks: 4 (limit: 1153)
CGroup: /system.slice/gunicorn.service
├─1157 /home/sammy/myprojectdir/myprojectenv/bin/python3 /home/sammy/myprojectdir/myprojectenv/bin/gunicorn --access-logfile - --workers 3 --bind unix:/run/gunicorn.sock myproject.wsgi:application
├─1178 /home/sammy/myprojectdir/myprojectenv/bin/python3 /home/sammy/myprojectdir/myprojectenv/bin/gunicorn --access-logfile - --workers 3 --bind unix:/run/gunicorn.sock myproject.wsgi:application
├─1180 /home/sammy/myprojectdir/myprojectenv/bin/python3 /home/sammy/myprojectdir/myprojectenv/bin/gunicorn --access-logfile - --workers 3 --bind unix:/run/gunicorn.sock myproject.wsgi:application
└─1181 /home/sammy/myprojectdir/myprojectenv/bin/python3 /home/sammy/myprojectdir/myprojectenv/bin/gunicorn --access-logfile - --workers 3 --bind unix:/run/gunicorn.sock myproject.wsgi:application
Jul 09 20:00:40 django1 systemd[1]: Started gunicorn daemon.
Jul 09 20:00:40 django1 gunicorn[1157]: [2018-07-09 20:00:40 +0000] [1157] [INFO] Starting gunicorn 19.9.0
Jul 09 20:00:40 django1 gunicorn[1157]: [2018-07-09 20:00:40 +0000] [1157] [INFO] Listening at: unix:/run/gunicorn.sock (1157)
Jul 09 20:00:40 django1 gunicorn[1157]: [2018-07-09 20:00:40 +0000] [1157] [INFO] Using worker: sync
Jul 09 20:00:40 django1 gunicorn[1157]: [2018-07-09 20:00:40 +0000] [1178] [INFO] Booting worker with pid: 1178
Jul 09 20:00:40 django1 gunicorn[1157]: [2018-07-09 20:00:40 +0000] [1180] [INFO] Booting worker with pid: 1180
Jul 09 20:00:40 django1 gunicorn[1157]: [2018-07-09 20:00:40 +0000] [1181] [INFO] Booting worker with pid: 1181
Jul 09 20:00:41 django1 gunicorn[1157]: - - [09/Jul/2018:20:00:41 +0000] "GET / HTTP/1.1" 200 16348 "-" "curl/7.58.0"
Si el resultado de curl
o systemctl status
indica que se produjo un problema, verifique los registros para obtener información adicional:
- sudo journalctl -u gunicorn
Verifique su archivo /etc/systemd/systemd/system/gunicorn.service
en busca de problemas. Si realiza cambios en el archivo /etc/systemd/systemd/system/gunicorn.service
, vuelva a cargar el demonio para volver a leer la definición de servicio y reiniciar el proceso de Gunicorn escribiendo lo siguiente:
- sudo systemctl daemon-reload
- sudo systemctl restart gunicorn
Asegúrese de resolver los problemas mencionados previamente antes de continuar.
Ahora que Gunicorn está configurado, debemos configurar Nginx para transferir tráfico al proceso.
Comience creando y abriendo un nuevo bloque de servidor en el directorio sites-available
de Nginx:
- sudo nano /etc/nginx/sites-available/myproject
Dentro de este, abra un nuevo bloque de servidor. Comenzaremos especificando que este bloque debe escuchar en el puerto normal 80 y responder al nombre de dominio o a la dirección IP de nuestro servidor:
server {
listen 80;
server_name server_domain_or_IP;
}
A continuación, indicaremos a Nginx que ignore cualquier problema para encontrar un favicon. También le indicaremos dónde encontrar los activos estáticos que recolectamos en nuestro directorio ~/
myprojectdir/static. Todos estos archivos tienen un prefijo URI de “/static”, para que podamos crear un bloque de ubicación que coincida con estas solicitudes:``
server {
listen 80;
server_name server_domain_or_IP;
location = /favicon.ico { access_log off; log_not_found off; }
location /static/ {
root /home/sammy/myprojectdir;
}
}
Por último, crearemos un bloque location / {}
para que coincida con todas las demás solicitudes. Dentro de esta ubicación, agregaremos el archivo proxy_params
estándar incluido con la instalación de Nginx y luego transferiremos el tráfico directamente al socket de Gunicorn:
server {
listen 80;
server_name server_domain_or_IP;
location = /favicon.ico { access_log off; log_not_found off; }
location /static/ {
root /home/sammy/myprojectdir;
}
location / {
include proxy_params;
proxy_pass http://unix:/run/gunicorn.sock;
}
}
Guarde y cierre el archivo cuando termine. Ahora, podemos habilitar el archivo vinculándolo al directorio sites-enabled
:
- sudo ln -s /etc/nginx/sites-available/myproject /etc/nginx/sites-enabled
Pruebe su configuración de Nginx para descartar errores de sintaxis escribiendo lo siguiente:
- sudo nginx -t
Si no se notifican errores, reinicie Nginx escribiendo lo siguiente:
- sudo systemctl restart nginx
Por último, debemos abrir nuestro firewall al tráfico normal en el puerto 80. Como ya no necesitamos acceso al servidor de desarrollo, podemos eliminar la regla para abrir también el puerto 8000:
- sudo ufw delete allow 8000
- sudo ufw allow 'Nginx Full'
Ahora debería poder acceder al dominio o a la dirección IP de su servidor para ver su aplicación.
Nota: Después de configurar Nginx, el siguiente paso debería ser proteger el tráfico al servidor usando SSL/TLS. Esto es importante porque, si no se aplica, toda la información, incluidas las contraseñas, se envía a través de la red en texto simple.
Si tiene un nombre de dominio, la alternativa más sencilla para obtener un certificado SSL para proteger su tráfico es usar Let’s Encrypt. Siga esta guía para configurar Let’s Encrypt con Nginx en Ubuntu 18.04. Siga el procedimiento usando el bloque de servidor de Nginx que creamos en esta guía.
Si no tiene un nombre de dominio, aún puede proteger su sitio para pruebas y aprendizaje con un certificado SSL autofirmado. Nuevamente, siga el proceso usando el bloque de servidor Nginx que creamos en este tutorial.
Si con este último paso no se muestra su aplicación, deberá resolver problemas en su instalación.
Si Nginx muestra la página predeterminada en lugar de actualizar su aplicación, normalmente significa que deberá ajustar el server_name
dentro del archivo /etc/nginx/sites-available/myproject
para apuntar a la dirección IP o al nombre de dominio de su servidor.
Nginx usa el server_name
para determinar el bloque de servidor que usará para responder a solicitudes. Si ve la página predeterminada de Nginx, significa que Nginx no pudo hacer coincidir la solicitud con un bloque de servidor de forma explícita, por lo cual recurre al bloque por defecto definido en /etc/nginx/sites-available/default
.
El server_name
del bloque de servidor de su proyecto debe ser más específico que el del bloque de servidor predeterminado que se seleccionará.
Un error 502 indica que Nginx no puede autorizar con éxito la solicitud. Con el error 502 se transmite una amplia variedad de problemas de configuración, por lo que se necesita más información para resolver los problemas de forma adecuada.
Los registros de errores de Nginx son el recurso principal para buscar más información. Generalmente, esto le indicará las condiciones que ocasionaron problemas durante el evento de autorización. Siga los registros de errores de Nginx escribiendo lo siguiente:
- sudo tail -F /var/log/nginx/error.log
Ahora, realice otra solicitud en su navegador para generar un nuevo error (intente actualizar la página). Debería ver un nuevo mensaje de error escrito en el registro. Si ve el mensaje, le servirá para reducir el problema.
Es posible que vea algunos de los mensajes que se muestran a continuación:
connect() to unix:/run/gunicorn.sock failed (2: No such file or directory)
Esto indica que Nginx no pudo encontrar el archivo gunicorn.sock
en la ubicación en cuestión. Debería comparar la ubicación de proxy_pass
definida en el archivo /etc/nginx/sites-available/myproject
con la ubicación actual del archivo gunicorn.sock
generado por la unidad de systemd gunicorn.sock
.
Si no puede encontrar un archivo gunicorn.sock
en el directorio /run
, por lo general significa que el archivo de socket de systemd no pudo crearlo. Regrese a la sección de verificación del archivo de socket de Gunicorn para seguir los pasos de resolución de problemas de Gunicorn.
connect() to unix:/run/gunicorn.sock failed (13: Permission denied)
Esto indica que Nginx no pudo conectarse al socket de Gunicorn debido a problemas de permisos. Esto puede ocurrir cuando se sigue el procedimiento con un usuario root en lugar de un usuario sudo
. Aunque systemd puede crear el archivo de socket de Gunicorn, Nginx no puede acceder a él.
Esto puede ocurrir si existen permisos limitados en cualquier punto entre el directorio root (/
) y el archivo gunicorn.sock
. Podemos ver los permisos y valores de propiedad del archivo de socket y cada uno de sus directorios pasando la ruta absoluta a nuestro archivo de socket al comando namei
:
- namei -l /run/gunicorn.sock
Outputf: /run/gunicorn.sock
drwxr-xr-x root root /
drwxr-xr-x root root run
srw-rw-rw- root root gunicorn.sock
En el resultado se muestran los permisos de cada uno de los componentes del directorio. Al mirar los permisos (primera columna), el propietario (segunda columna) y el propietario del grupo (tercera columna), podemos averiguar el tipo de acceso permitido para el archivo de socket.
En el ejemplo anterior, el archivo de sockets y cada directorio que conduce a este tienen permisos mundiales de lectura y ejecución (la columna de permisos para los directorios termina en r-x
en lugar de ---
). El proceso de Nginx debería poder acceder al socket de forma correcta.
Si algunos directorios que conducen al socket no tienen permiso mundial de lectura y ejecución, Nginx no podrá acceder al socket sin otorgar permisos mundiales de lectura y ejecución ni asegurarse de que se otorgue propiedad del grupo a un grupo del que forme parte Nginx.
Se puede ver el el siguiente mensaje de Django al intentar acceder a partes de la aplicación en el navegador web:
OperationalError at /admin/login/
could not connect to server: Connection refused
Is the server running on host "localhost" (127.0.0.1) and accepting
TCP/IP connections on port 5432?
Esto indica que Django no puede conectarse a la base de datos de Postgres. Asegúrese de que la instancia de Postgres esté en ejecución escribiendo lo siguiente:
- sudo systemctl status postgresql
Si esto no sucede, puede iniciarla y activarla para que se cargue automáticamente en el inicio (si aún no está cargada la configuración para ello) escribiendo lo siguiente:
- sudo systemctl start postgresql
- sudo systemctl enable postgresql
Si todavía experimenta problemas, asegúrese de que los ajustes de la base de datos definidos en el archivo ~/myprojectdir/myproject/settings.py
sean correctos.
Para resolver problemas adicionales, los registros pueden servir para reducir las causas raíces. Verifique cada uno de ellos por separado y busque mensajes que indiquen las áreas problemáticas.
Los siguientes registros pueden ser útiles:
sudo journalctl -u nginx
.sudo less /var/log/nginx/access.log
sudo less /var/log/nginx/error.log
.sudo journalctl -u gunicorn
.sudo journalctl -u gunicorn.socket
.Cuando actualice su configuración o aplicación, es probable que necesite reiniciar los procesos para que asimilen sus cambios.
Si actualiza su aplicación de Django, puede reiniciar el proceso de Gunicorn para que incorpore los cambios escribiendo lo siguiente:
- sudo systemctl restart gunicorn
Si cambia los archivos de socket y servicio de Gunicorn, vuelva a cargar el demonio y reinicie el proceso escribiendo lo siguiente:
- sudo systemctl daemon-reload
- sudo systemctl restart gunicorn.socket gunicorn.service
Si cambia la configuración de bloque del servidor de Nginx, pruébela y luego verifique Nginx escribiendo lo siguiente:
- sudo nginx -t && sudo systemctl restart nginx
Estos comandos son útiles para incorporar cambios cuando ajusta su configuración.
En esta guía, creamos un proyecto de Django en su propio entorno virtual. Configuramos Gunicorn para que traduzca las solicitudes de los clientes a fin de que Django pueda manejarlas. Posteriormente, configuramos Nginx para que actúe como proxy inverso a fin de manejar las conexiones de los clientes y presentar el proyecto correcto según la solicitud del cliente.
Django simplifica la creación de proyectos y aplicaciones proporcionando muchas de las piezas comunes, lo que le permite centrarse en los elementos únicos. Al aprovechar la cadena general de herramientas descrita en este artículo, puede ofrecer fácilmente las aplicaciones que cree desde un servidor único.
Thanks for learning with the DigitalOcean Community. Check out our offerings for compute, storage, networking, and managed databases.
This textbox defaults to using Markdown to format your answer.
You can type !ref in this text area to quickly search our full set of tutorials, documentation & marketplace offerings and insert the link!
Sign up for Infrastructure as a Newsletter.
Working on improving health and education, reducing inequality, and spurring economic growth? We'd like to help.
Get paid to write technical tutorials and select a tech-focused charity to receive a matching donation.
Been struggling with the deploy of my django app for almost a month, this tutorial made me very happy thank you!
Muy buen post, muy recomendado y claro. Me ha servido mucho. En caso de querer desplegar varias aplicaciones recomiendo https://www.digitalocean.com/community/questions/how-to-deploy-multiple-django-apps-as-subdomains-using-nginx-and-gunicorn esta basado en este mismo tutorial, gracias
Muchas gracias me ha servido mucho, aunque spy nuevo en el uso de gunicorn y NGINX este tutorial me ha dado información fundamental en el proceso, muchas gracias!!
Thank you very much. People like you always deserve the best.