## Resumen
En resumen: se trata de servir el django usando WSGI mediante un servidor Gunicorn corrido a través de supervisor (un gestor de tareas). El Nginx usará un proxy reverso para servir a su vez dicho contenido.
## NGinx
Primero crearemos un archivo de configuración, de manera similar a cómo haríamos en Apache. Si hemos instalado nginx usando apt o similares la estructura será la misma a la de un apache y habrá que crear el archivo en sites-available y enlazarlo desde sites-enabled. Si no (porque estemos en un servidor centOS por ejemplo), esta estructura no existirá y tendremos dos opciones. Hacer lo mismo sustituyendo a sites-enabled por conf.d; o añadir una línea de importación a nginx.conf y crear a mano dicha estructura; o, por último, añadir directamente a conf.d el archivo en cuestión.
### La configuración
https://docs.nginx.com/nginx/admin-guide/web-server/reverse-proxy/
Este sería un ejemplo de archivo a añadir
```nginx
server {
listen 80; # ipv4
listen [::]:80; # ipv6
server_name example.org;
charset utf-8;
location = /favicon.ico { # para evitar 404 en el favicon
access_log off;
log_not_found off;
}
location /media {
alias /var/www/example.org/public_html/assets/media;
}
location /static {
alias /var/www/example.org/public_html/assets/static;
}
location / {
proxy_pass http://unix:/var/www/example.org/public_html/example.sock;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;
}
}
```
Es muy similar a la configuración de un virtualhost de apache (aquí "block de nginx"). Es bastante autoexplicativo. La parte importante va en la configuración del proxy reverso:
```nginx
proxy_pass http://unix:/var/www/example.org/public_html/example.sock;
```
Lo que hacemos es conectar todas las peticiones mediante un proxy reverso a un socket unix especificado mediante `unix:<ruta-al-socket>`. La creación de este socket correrá a cargo de Gunicorn.
### Gunicorn
Gunicorn (Green Unicorn) es un servidor HTTP WSGI capaz de servir aplicaciones escritas en Python. Primero deberemos instalarlo. Lo haremos en el entorno virtual del django:
```bash
. env/bin/activate
pip install gunicorn
```
Para servir directamente el django entraríamos en la carpeta raíz y haríamos un:
```bash
../env/bin/gunicorn --bind 127.0.0.1:8000 example.wsgi:application
```
Vemos que:
- Corremos el gunicorn instalado en el entorno virtual (importante: para usar el entorno virtual y no el python y los paquetes instalados globalmente)
- Hacemos un bind (a un puerto o a un socket)
- Especificamos el archivo principal wsgi (en este caso example.wsgi, considerando un proyecto de nombre 'example' --> usa _dot notation_, el archivo realmente se llama wsgi.py y estaría en la carpeta 'example').
Esto sería análogo a correr el django usando manage.py.
### Supervisor
http://supervisord.org/
Es un demonio que funciona como _sistema de control de procesos_. Es el sistema que usaremos para controlar gunicorn. Para instalarlo haremos simplemente un:
```bash
pip install supervisor
```
La configuración es muy sencilla y se hace a través de una directiva 'program' que define un comando que se ejecuta cada vez que corra el proceso 'supervisor'. Este directiva se puede incluir directamente en el archivo /etc/supervisord.conf o bien dentro de un archivo .conf en /etc/supervisord.d/:
```bash
[program:example]
command=/var/www/example.org/env/bin/gunicorn --bind unix:/var/www/example.org/example.sock example.wsgi:application
directory=/var/www/example.org/public_html
username=root
autostart=true
autorestart=true
stdout_logfile=/var/www/example.org/mapa.log
stderr_logfile=/var/www/example.org/mapa.err.log
```
Especificamos el directorio donde el proceso correrá, el comando (el gunicorn instalado en el entorno virtual del django), así como el usuario que lo correrá (tiene que tener permisos de lectura/escritura), los logs (las carpetas que los contengan han de existir si no queremos que falle el proceso), así como el comportamiento cuando supervisor arranca o cae (lanzarse automáticamente o no).
Por último activamos el servicio para que corra cuando el sistema arranque o reinicie:
```bash
sudo systemctl enable supervisord
```