Cómo escalar y proteger una aplicación de Django con Docker, Nginx y Let's Encrypt

Introducción

En los entornos basados en la nube, hay diversas maneras de escalar y proteger aplicaciones de Django. Al escalar horizontalmente y ejecutar varias copias de su aplicación, puede crear un sistema más tolerante a fallos y de alta disponibilidad, a la vez que aumenta su rendimiento para que se puedan procesar solicitudes de forma simultánea. Una manera de escalar horizontalmente una aplicación de Django es proporcionar servidores de aplicaciones adicionales que ejecuten su aplicación de Django y su servidor HTTP WSGI (como Gunicorn o uWSGI). Para dirigir y distribuir las solicitudes entrantes a través de este conjunto de servidores de aplicaciones, puede usar un equilibrador de carga y un proxy inverso como Nginx. Nginx también puede almacenar en caché contenido estático y detener las conexiones de Seguridad de la capa de transporte (TLS), que se utilizan para proporcionar conexiones HTTPS y seguras a su aplicación.

Ejecutar su aplicación de Django y el proxy Nginx dentro de contenedores de Docker garantiza que estos componentes se comporten de la misma manera independientemente del entorno en el que se implementen. Además, los contenedores proporcionan muchas características que facilitan la creación de paquetes y la configuración de su aplicación.

En este tutorial, escalará horizontalmente una aplicación Polls de Django y Gunicorn en un contenedor proporcionando dos servidores de aplicaciones que ejecutarán una copia de un contenedor de una aplicación de Django y Gunicorn.

También habilitará HTTPS al proporcionar y configurar un tercer servidor proxy que ejecutará un contenedor de un proxy inverso Nginx y otro de un cliente Certbot. Certbot proporcionará certificados TLS para Nginx de la entidad de certificación Let’s Encrypt. Esto garantizará que su sitio reciba una calificación de seguridad alta de SSL Labs. Este servidor proxy recibirá todas las solicitudes externas de su aplicación y se ubicará frente a los dos servidores de aplicaciones de Django que preceden en la cadena. Por último, reforzará este sistema distribuido al restringir el acceso externo solo al servidor proxy.

Requisitos previos

Para seguir este tutorial, necesitará lo siguiente:

• Tres servidores con Ubuntu 18.04:

  • Dos se utilizarán como servidores de aplicaciones y se utilizarán para ejecutar su aplicación de Django y Gunicorn.
  • Uno se usará como servidor proxy y se utilizará para ejecutar Nginx y Certbot.
  • Todos los usuarios deben tener un usuario no root con privilegios sudo y firewall activo. Para obtener información sobre cómo configurarlos, consulte esta guía de configuración inicial para servidores.

• Docker instalado en los tres servidores. Para obtener orientación sobre la instalación de Docker, siga los pasos 1 y 2 de Cómo instalar y usar Docker en Ubuntu 18.04.

• Un nombre de dominio registrado. En este tutorial, utilizaremos your_domain en todo momento. Puede obtener un ejemplar gratis en Freenom o utilizar el registrador de dominios que desee.

• Un registro DNS A con your_domain.com orientado a la dirección IP pública de su servidor proxy. Puede seguir esta introducción al DNS de DigitalOcean para obtener información sobre cómo agregarlo a una cuenta de DigitalOcean, si usa una:

• Un depósito de almacenamiento de objetos S3, como un Space de DigitalOcean, para almacenar los archivos estáticos de su proyecto de Django y un conjunto de claves de acceso para ese espacio. Para obtener información sobre cómo crear Spaces, consulte la documentación de Cómo crear Spaces. Para obtener información sobre cómo crear claves de acceso para Spaces, consulte Compartir el acceso a Spaces con claves de acceso. Con cambios menores, puede usar cualquier servicio de almacenamiento de objetos que admita el complemento django-storages

• Una instancia de un servidor de PostgreSQL, una base de datos y un usuario para su aplicación de Django. Con cambios menores, puede usar cualquier base de datos que admita Django.

  • La base de datos de PostgreSQL se debería llamar polls (o tener cualquier otro nombre fácil de recordar para ingresar en sus archivos de configuración a continuación). En este tutorial, el usuario de la base de datos se denominará sammy. Para obtener información sobre cómo crearlos, siga el Paso 1 de Cómo crear una aplicación de Django y Gunicorn con Docker. Puede realizar estos pasos desde cualquiera de los tres servidores.
  • En este tutorial, se utiliza un clúster de PostgreSQL administrado de DigitalOcean. Para obtener información sobre cómo crear un clúster, consulte la documentación de Bases de datos administradas de DigitalOcean.
  • También puede instalar y ejecutar su propia instancia de PostgreSQL. Para obtener información sobre la instalación y administración de PostgreSQL en un servidor de Ubuntu, consulte Cómo instalar y utilizar PostgreSQL en Ubuntu 18.04.

Paso 1: Configurar el primer servidor de aplicaciones de Django

Para comenzar, vamos a clonar el repositorio de aplicaciones de Django en el primer servidor de aplicaciones. A continuación, configuraremos y compilaremos la imagen de Docker de la aplicación y probaremos la aplicación ejecutando el contenedor de Django.

Comience iniciando sesión en el primero de los dos servidores de aplicaciones de Django. Utilice git para clonar la rama polls-docker del repositorio de GitHub de la aplicación Polls del tutorial de Django. Este repositorio contiene código para la aplicación Polls de muestra de la documentación de Django. La rama polls-docker contiene una versión con Docker de la aplicación Polls. Para obtener información sobre cómo se modificó la aplicación Polls para que funcione de forma eficaz en un entorno con contenedor, consulte Cómo crear una aplicación de Django y Gunicorn con Docker.

git clone --single-branch --branch polls-docker https://github.com/do-community/django-polls.git

Diríjase al directorio django-polls:

cd django-polls

Este directorio contiene el código de Python de la aplicación de Django, un Dockerfile que Docker utilizará para crear la imagen del contenedor, y un archivo env que contiene una lista de las variables de entorno que se van a pasar al entorno en ejecución del contenedor. Inspeccione el Dockerfile con cat:

cat Dockerfile

Output
FROM python:3.7.4-alpine3.10

ADD django-polls/requirements.txt /app/requirements.txt

RUN set -ex \
    && apk add --no-cache --virtual .build-deps postgresql-dev build-base \
    && python -m venv /env \
    && /env/bin/pip install --upgrade pip \
    && /env/bin/pip install --no-cache-dir -r /app/requirements.txt \
    && runDeps="$(scanelf --needed --nobanner --recursive /env \
        | awk '{ gsub(/,/, "\nso:", $2); print "so:" $2 }' \
        | sort -u \
        | xargs -r apk info --installed \
        | sort -u)" \
    && apk add --virtual rundeps $runDeps \
    && apk del .build-deps

ADD django-polls /app
WORKDIR /app

ENV VIRTUAL_ENV /env
ENV PATH /env/bin:$PATH

EXPOSE 8000

CMD ["gunicorn", "--bind", ":8000", "--workers", "3", "mysite.wsgi"]

Este Dockerfile utiliza la imagen de Docker oficial de Python 3.7.4 como base e instala los requisitos del paquete de Python de Django y Gunicorn, tal como se define en el archivo django-polls/requirements.txt. A continuación, elimina algunos archivos de compilación innecesarios, copia el código de la aplicación en la imagen y establece el PATH de ejecución. Por último, declara que el puerto 8000 se utilizará para aceptar conexiones de contenedores entrantes y ejecuta gunicorn con 3 trabajadores, escuchando en el puerto 8000.

Para obtener más información sobre cada uno de los pasos de este Dockerfile, consulte el Paso 6 de Cómo crear una aplicación de Django y Gunicorn con Docker.

Ahora, compile la imagen con docker build:

docker build -t polls .

Nombramos la imagen polls con el indicador -t y pasamos el directorio actual como contexto de compilación, el conjunto de archivos a los que se debe hacer referencia al construir la imagen.

Una vez que Docker haya compilado y etiquetado la imagen, enumere las imágenes disponibles utilizando docker images:

docker images

Debería ver la imagen polls enumerada:

Output
REPOSITORY          TAG                 IMAGE ID            CREATED             SIZE
polls               latest              80ec4f33aae1        2 weeks ago         197MB
python              3.7.4-alpine3.10    f309434dea3a        8 months ago        98.7MB

Antes de ejecutar el contenedor de Django, debemos configurar su entorno de ejecución utilizando el archivo env presente en el directorio actual. Este archivo se pasará al comando docker run que se utiliza para ejecutar el contenedor y Docker insertará las variables de entorno configuradas en el entorno en ejecución del contenedor.

Abra el archivo env con nano o su editor favorito:

nano env

Configuraremos el archivo de esta manera y deberá agregar algunos valores adicionales como se indica a continuación.

DJANGO_SECRET_KEY=
DEBUG=True
DJANGO_ALLOWED_HOSTS=
DATABASE_ENGINE=postgresql_psycopg2
DATABASE_NAME=polls
DATABASE_USERNAME=
DATABASE_PASSWORD=
DATABASE_HOST=
DATABASE_PORT=
STATIC_ACCESS_KEY_ID=
STATIC_SECRET_KEY=
STATIC_BUCKET_NAME=
STATIC_ENDPOINT_URL=
DJANGO_LOGLEVEL=info

Complete los valores que faltan para las siguientes claves:

• DJANGO_SECRET_KEY: establézcala en un valor único e impredecible, como se detalla en la documentación de Django. Se proporciona un método para generar esta clave en la sección Ajustar la configuración de la aplicación del tutorial Aplicaciones escalables de Django.
• DJANGO_ALLOWED_HOSTS: esta variable asegura la aplicación y evita ataques a través del encabezado de host HTTP. Para propósitos de prueba, establézcala en *, un comodín que coincidirá con todos los hosts. En producción, debe establecerlo en your_domain.com. Para obtener más información sobre esta configuración de Django, consulte la sección Configuración principal en la documentación de Django.
• DATABASE_USERNAME: establézcalo en el usuario de la base de datos de PostgreSQL creado en los pasos de requisitos previos.
• DATABASE_NAME: establézcalo en polls o el nombre de la base de datos de PostgreSQL creado en los pasos de requisitos previos.
• DATABASE_PASSWORD: establézcala en la contraseña de la base de datos de PostgreSQL creada en los pasos de requisitos previos.
• DATABASE_HOST: establézcalo en el nombre de host de su base de datos.
• DATABASE_PORT: Set establézcalo en el puerto de su base de datos.
• STATIC_ACCESS_KEY_ID: establézcala en la clave de acceso de su cubo S3 o su Space.
• STATIC_SECRET_KEY: establézcala en el secreto de la clave de acceso de su cubo S3 o su Space.
• STATIC_BUCKET_NAME: establézcalo en el nombre de su cubo S3 o su Space.
• STATIC_ENDPOINT_URL: establézcala en la URL de extremo correspondiente de su cubo S3 o su Space, por ejemplo, https://space-name.nyc3.digitaloceanspaces.com, si su Space está ubicado en la región nyc3.

Una vez que haya finalizado la edición, guarde y cierre el archivo.

Ahora, utilizaremos docker run para anular el CMD establecido en Dockerfile y crear el esquema de la base de datos utilizando los comandos manage.py makemigrations y manage.py migrate:

docker run --env-file env polls sh -c "python manage.py makemigrations && python manage.py migrate"

Ejecutamos la imagen del contenedor polls:latest, pasamos el archivo de variables de entorno que acabamos de modificar y anulamos el comando de Dockerfile con sh -c "python manage.py makemigrations && python manage.py migrate", lo que creará el esquema de la base de datos definido mediante el código de la aplicación. Si lo ejecuta por primera vez, debería ver lo siguiente:

Output
No changes detected
Operations to perform:
  Apply all migrations: admin, auth, contenttypes, polls, sessions
Running migrations:
  Applying contenttypes.0001_initial... OK
  Applying auth.0001_initial... OK
  Applying admin.0001_initial... OK
  Applying admin.0002_logentry_remove_auto_add... OK
  Applying admin.0003_logentry_add_action_flag_choices... OK
  Applying contenttypes.0002_remove_content_type_name... OK
  Applying auth.0002_alter_permission_name_max_length... OK
  Applying auth.0003_alter_user_email_max_length... OK
  Applying auth.0004_alter_user_username_opts... OK
  Applying auth.0005_alter_user_last_login_null... OK
  Applying auth.0006_require_contenttypes_0002... OK
  Applying auth.0007_alter_validators_add_error_messages... OK
  Applying auth.0008_alter_user_username_max_length... OK
  Applying auth.0009_alter_user_last_name_max_length... OK
  Applying auth.0010_alter_group_name_max_length... OK
  Applying auth.0011_update_proxy_permissions... OK
  Applying polls.0001_initial... OK
  Applying sessions.0001_initial... OK

Esto indica que el esquema de la base de datos se ha creado correctamente.

Si no está ejecutando migrate por primera vez, Django realizará un no-op a menos que el esquema de la base de datos haya cambiado.

A continuación, ejecutaremos otra instancia del contenedor de la aplicación y utilizaremos una shell interactiva en su interior para crear un usuario administrativo para el proyecto de Django.

docker run -i -t --env-file env polls sh

Esto le proporcionará una línea de comandos de shell dentro del contenedor en ejecución que puede usar para crear el usuario de Django:

python manage.py createsuperuser

Ingrese un nombre de usuario, una dirección de correo electrónico y una contraseña para su usuario y, una vez que haya creado el usuario, presione CTRL+D para salir del contenedor y cerrarlo.

Por último, generaremos los archivos estáticos de la aplicación y los subiremos al Space de DigitalOcean utilizando collectstatic. Tenga en cuenta que esta operación puede tardar un poco en completarse.

docker run --env-file env polls sh -c "python manage.py collectstatic --noinput"

Una vez que estos archivos se hayan generado y cargado, obtendrá el siguiente resultado.

Output
121 static files copied.

Ahora, podemos ejecutar la aplicación:

docker run --env-file env -p 80:8000 polls

Output
[2019-10-17 21:23:36 +0000] [1] [INFO] Starting gunicorn 19.9.0
[2019-10-17 21:23:36 +0000] [1] [INFO] Listening at: http://0.0.0.0:8000 (1)
[2019-10-17 21:23:36 +0000] [1] [INFO] Using worker: sync
[2019-10-17 21:23:36 +0000] [7] [INFO] Booting worker with pid: 7
[2019-10-17 21:23:36 +0000] [8] [INFO] Booting worker with pid: 8
[2019-10-17 21:23:36 +0000] [9] [INFO] Booting worker with pid: 9

Aquí, ejecutamos el comando predeterminado definido en el Dockerfile, gunicorn --bind :8000 --workers 3 mysite.wsgi:application y exponemos el puerto del contenedor 8000 para que el puerto 80 del servidor de Ubuntu se asigne al puerto 8000 del contenedor polls.

Ahora, debería poder navegar a la aplicación polls desde su navegador web al escribir http://APP_SERVER_1_IP en la barra de direcciones URL. Dado que no hay una ruta definida para la ruta / , es probable que reciba un error de 404 Page Not Found (Página no encontrada), lo que es de esperar.

Diríjase a http://APP_SERVER_1_IP/polls para ver la interfaz de la aplicación Polls:

Para ver la interfaz administrativa, visite http://APP_SERVER_1_IP/admin. Debería ver la ventana de autenticación de administración de la aplicación Polls:

Ingrese el nombre de usuario administrativo y la contraseña que creó con el comando createsuperuser.

Después de la autenticación, podrá acceder a la interfaz administrativa de la aplicación Polls:

Tenga en cuenta que los que los recursos estáticos de las aplicaciones admin y polls se entregan directamente desde el almacenamiento de objetos. Para confirmar esto, consulte Prueba de la entrega de archivos estáticos de Spaces.

Cuando haya terminado de explorar, presione CTRL+C en la ventana de terminal que está ejecutando el contenedor de Docker para cerrar el contenedor.

Ahora que ha confirmado que el contenedor de la aplicación se ejecuta de la manera prevista, puede ejecutarlo en modo separado, lo que lo ejecutará en segundo plano y le permitirá salir de su sesión SSH:

docker run -d --rm --name polls --env-file env -p 80:8000 polls

El indicador -d le indica a Docker que ejecute el contenedor en modo separado y el indicador -rm limpia el sistema de archivos del contenedor una vez que se sale de él. Denominamos polls al contenedor.

Desconéctese del primer servidor de aplicaciones de Django y diríjase a http://APP_SERVER_1_IP/polls para confirmar que el contenedor se está ejecutando de la manera prevista.

Ahora que su primer servidor de aplicaciones de Django está en ejecución, puede configurar el segundo.

Paso 2: Configurar el segundo servidor de aplicaciones de Django

Como muchos de los comandos que se utilizan para configurar este servidor serán los mismos que los que utilizamos en el paso anterior, se presentarán aquí de forma abreviada. Revise el Paso 1 para obtener más información sobre los comandos que se utilizan en este paso.

Comience por iniciar sesión en el segundo servidor de aplicaciones de Django.

Clone la rama polls-docker del repositorio de GitHub django-polls:

git clone --single-branch --branch polls-docker https://github.com/do-community/django-polls.git

Diríjase al directorio django-polls:

cd django-polls

Compile la imagen con docker build:

docker build -t polls .

Abra el archivo env con nano o su editor favorito:

nano env

DJANGO_SECRET_KEY=
DEBUG=True
DJANGO_ALLOWED_HOSTS=
DATABASE_ENGINE=postgresql_psycopg2
DATABASE_NAME=polls
DATABASE_USERNAME=
DATABASE_PASSWORD=
DATABASE_HOST=
DATABASE_PORT=
STATIC_ACCESS_KEY_ID=
STATIC_SECRET_KEY=
STATIC_BUCKET_NAME=
STATIC_ENDPOINT_URL=
DJANGO_LOGLEVEL=info

Complete los valores que faltan como se indica en el Paso 1. Cuando haya terminado de editar, guarde y cierre el archivo.

Por último, ejecute el contenedor de la aplicación en modo separado:

docker run -d --rm --name polls --env-file env -p 80:8000 polls

Diríjase a http://APP_SERVER_2_IP/polls para confirmar que el contenedor se está ejecutando de la manera prevista. Puede iniciar sesión de forma segura en el segundo servidor de aplicaciones sin cerrar el contenedor en ejecución.

Con los dos contenedores de aplicaciones de Django en ejecución, puede configurar el contenedor del proxy inverso Nginx.

Paso 3: Configurar el contenedor de Docker de Nginx

Nginx es un servidor web versátil que ofrece varias características, como proxy inverso, equilibrio de carga y almacenamiento en caché. En este tutorial, hemos descargado los recursos estáticos de Django al almacenamiento de objetos, por lo que no utilizaremos las capacidades de almacenamiento en caché de Nginx. Sin embargo, utilizaremos Nginx como proxy inverso para nuestros dos servidores de aplicaciones de Django de backend y distribuiremos las solicitudes entrantes entre ellos. Además, Nginx realizará la terminación de TLS y el redireccionamiento utilizando un certificado TLS proporcionado por Certbot. Esto significa que obligará a los clientes a usar HTTPS, redireccionando las solicitudes HTTP entrantes al puerto 443. Luego, descifrará las solicitudes HTTPS y las redirigirá, a través del proxy, a los servidores de Django que preceden en la cadena.

En este tutorial, hemos tomado la decisión de desacoplar los contenedores de Nginx de los servidores de backend. Dependiendo de su caso de uso, puede optar por ejecutar el contenedor de Nginx en cualquiera de los dos servidores de aplicaciones de Django, redirigiendo las solicitudes, a través del proxy, de forma local. Otra posible arquitectura sería ejecutar dos contenedores de Nginx, uno en cada servidor de backend, con un equilibrador de carga en la nube al frente. Cada arquitectura presenta diferentes ventajas de seguridad y desempeño; debe realizar una prueba de carga de su sistema para descubrir los posibles cuellos de botella. La arquitectura flexible que se describe en este tutorial le permite escalar tanto la capa de la aplicación de Django de backend como la capa del proxy de Nginx. Cuando el contenedor único de Nginx se convierta en un cuello de botella, puede escalar varios proxy de Nginx y agregar un equilibrador de carga en la nube o uno L4 rápido, como HAProxy.

Con los dos servidores de aplicaciones de Django en ejecución, podemos comenzar a configurar el servidor proxy de Nginx. Inicie sesión en su servidor proxy y cree un directorio llamado conf:

mkdir conf

Cree un archivo de configuración denominado nginx.conf con nano o su editor favorito:

nano conf/nginx.conf

Pegue la siguiente configuración de Nginx:

upstream django {
	server APP_SERVER_1_IP;
	server APP_SERVER_2_IP;
}

server {
	listen 80 default_server;
	return 444;
}

server {
	listen 80;
	listen [::]:80;
	server_name your_domain.com;
	return 301 https://$server_name$request_uri;
}

server {
	listen 443 ssl http2;
	listen [::]:443 ssl http2;
	server_name your_domain.com;

	# SSL
	ssl_certificate /etc/letsencrypt/live/your_domain.com/fullchain.pem;
	ssl_certificate_key /etc/letsencrypt/live/your_domain.com/privkey.pem;

	ssl_session_cache shared:le_nginx_SSL:10m;
	ssl_session_timeout 1440m;
	ssl_session_tickets off;

	ssl_protocols TLSv1.2 TLSv1.3;
	ssl_prefer_server_ciphers off;

	ssl_ciphers "ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384";

	client_max_body_size 4G;
	keepalive_timeout 5;

        location / {
          proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
          proxy_set_header X-Forwarded-Proto $scheme;
          proxy_set_header Host $http_host;
          proxy_redirect off;
          proxy_pass http://django;
        }

	location ^~ /.well-known/acme-challenge/ {
		root /var/www/html;
	}

}

Los bloques upstream, server y location configuran Nginx para que redirija las solicitudes HTTP a HTTPS y equilibre su carga entre los dos servidores de aplicaciones de Django configurados en los pasos 1 y 2. Para obtener más información sobre la estructura de los archivos de configuración de Nginx, consulte el artículo Información sobre la estructura de los archivos y los contextos de configuración de Nginx. El artículo Información sobre algoritmos de selección de bloques de servidores y ubicación de Nginx también puede resultarle útil.

Esta configuración se realizó a partir de archivos de configuración de muestra proporcionados por Gunicorn, Cerbot y Nginx y representa una configuración mínima de Nginx para poner en marcha esta arquitectura. Los ajustes de esta configuración de Nginx están fuera del alcance de este artículo, pero puede usar una herramienta como NGINXConfig para generar archivos de configuración de Nginx seguros y de buen rendimiento para su arquitectura.

El bloque upstream define el grupo de servidores que se utiliza para redirigir las solicitudes mediante el proxy utilizando la directiva proxy_pass:

upstream django {
	server APP_SERVER_1_IP;
	server APP_SERVER_2_IP;
}
. . .

En este bloque, lo denominamos django e incluimos las direcciones IP de los dos servidores de aplicaciones de Django. Si los servidores de aplicaciones se ejecutan en DigitalOcean y tienen habilitadas redes VPC, debe usar sus direcciones IP privadas aquí. Para obtener información sobre cómo habilitar las redes VPC en DigitalOcean, consulte Cómo habilitar redes VPC en Droplets existentes.

El primer bloque server captura las solicitudes que no coinciden con su dominio y termina la conexión. Por ejemplo, este bloque manejaría una solicitud HTTP directa a la dirección IP de su servidor:

. . .
server {
	listen 80 default_server;
	return 444;
}
. . .

El siguiente bloque server redirige las solicitudes HTTP a su dominio a HTTPS utilizando un redireccionamiento HTTP 301. Luego, el bloque server final se encarga de manejar estas solicitudes:

. . .
server {
    listen 80;
    listen [::]:80;
    server_name your_domain.com;
    return 301 https://$server_name$request_uri;
}
. . .

Estas dos directivas definen las rutas al certificado TLS y la clave secreta. Se proporcionarán utilizando Certbot y se instalarán en el contenedor de Nginx en el siguiente paso.

. . .
ssl_certificate /etc/letsencrypt/live/your_domain.com/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/your_domain.com/privkey.pem;
. . .

Estos parámetros son los valores predeterminados de seguridad SSL recomendados por Certbot. Para obtener más información sobre ellos, consulte el Módulo ngx_http_ssl_module en la documentación de Nginx. La guía Seguridad/TLS del lado del servidor de Mozilla es otro recurso útil que puede usar para ajustar su configuración de SSL.

. . .
	ssl_session_cache shared:le_nginx_SSL:10m;
	ssl_session_timeout 1440m;
	ssl_session_tickets off;

	ssl_protocols TLSv1.2 TLSv1.3;
	ssl_prefer_server_ciphers off;

	ssl_ciphers "ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384";
. . .

Estas dos directivas de la configuración de muestra de Nginx de Gunicorn establecen el tamaño máximo permitido del cuerpo de la solicitud del cliente y asignan el tiempo de espera para las conexiones persistentes con el cliente. Nginx cerrará las conexiones con el cliente una vez transcurridos los segundos de keepalive_timeout.

. . .
client_max_body_size 4G;
keepalive_timeout 5;
. . .

El primer bloque location le indica a Nginx que redirija, a través del proxy, las solicitudes a los servidores upstream django mediante HTTP. También preserva los encabezados HTTP del cliente que capturan la dirección IP de origen, el protocolo utilizado para la conexión y el host de destino:

. . .
location / {
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_set_header X-Forwarded-Proto $scheme;
    proxy_set_header Host $http_host;
    proxy_redirect off;
    proxy_pass http://django;
}
. . .

Para obtener más información sobre estas directivas, consulte Implementación de Gunicorn y Module ngx_http_proxy_module en la documentación de Nginx.

El bloque location final captura las solicitudes a la ruta /well-known/acme-challenge/ que utiliza Certbot en los desafíos de HTTP-01 para verificar su dominio con Let’s Encrypt y suministrar o renovar los certificados TLS.  Para obtener más información sobre el desafío HTTP-01 que utiliza Certbot, consulte Tipos de desafíos en la documentación de Let’s Encrypt.

. . .
location ^~ /.well-known/acme-challenge/ {
		root /var/www/html;
}

Una vez que haya finalizado la edición, guarde y cierre el archivo.

Ahora, puede usar este archivo de configuración para ejecutar un contenedor de Docker de Nginx. En este tutorial, utilizaremos la imagen nginx:1.19.0, versión 1.19.0, de la imagen de Docker oficial que mantiene Nginx.

Cuando ejecutemos el contenedor por primera vez, Nginx arrojará un error y fallará, dado que aún no hemos proporcionado los certificados definidos en el archivo de configuración. De todos modos, ejecutaremos el comando para descargar la imagen de Nginx de forma local y probar que todo lo demás funcione correctamente:

docker run --rm --name nginx -p 80:80 -p 443:443 \
    -v ~/conf/nginx.conf:/etc/nginx/conf.d/nginx.conf:ro \
    -v /var/www/html:/var/www/html \
    nginx:1.19.0

Aquí, denominamos nginx al contenedor y asignamos los puertos del host 80 y 443 a los puertos de los contenedores respectivos. El indicador -v ubica el archivo config en el contenedor de Nginx en /etc/nginx/conf.d/nginx.conf, que la imagen de Nginx está preconfigurada para cargar. Se coloca en modo ro o de “solo lectura”, por lo que el contenedor no puede modificar el archivo. El directorio web root /var/www/html también se instala en el contenedor. Por último, nginx:1.19.0 le indica a Docker que extraiga y ejecute la imagen nginx:1.19.0 de Dockerhub.

Docker extraerá y ejecutará la imagen y, luego, Nginx arrojará un error cuando no encuentre el certificado TLS configurado y la clave secreta. Los suministraremos en el siguiente paso utilizando un cliente de Cerbot con Docker y la entidad de certificación Let’s Encrypt.

Paso 4: Configurar la renovación de certificados de Let’s Encrypt y Certbot

Certbot es un cliente Let’s Encrypt desarrollado por Electronic Frontier Foundation. Proporciona certificados TLS gratuitos de la entidad de certificación Let’s Encrypt que permiten a los navegadores verificar la identidad de sus servidores web. Como tenemos Docker instalado en nuestro servidor proxy de Nginx, utilizaremos la imagen de Docker de Certbot para suministrar y renovar los certificados TLS.

Comience por asegurarse de tener un registro DNS A asignado a la dirección IP pública del servidor proxy. A continuación, en su servidor proxy, proporcione una versión provisional de los certificados utilizando la imagen de Docker certbot:

docker run -it --rm -p 80:80 --name certbot \
         -v "/etc/letsencrypt:/etc/letsencrypt" \
         -v "/var/lib/letsencrypt:/var/lib/letsencrypt" \
         certbot/certbot certonly --standalone --staging -d your_domain.com

Este comando ejecuta la imagen de Docker certbot en modo interactivo y reenvía el puerto 80 del host al puerto 80 del contenedor. Crea y monta dos directorios de host en el contenedor: /etc/letsencrypt/ y /var/lib/letsencrypt/. certbot se ejecuta en modo standalone, sin Nginx, y utilizará los servidores staging de Let’s Encrypt para realizar la validación del dominio.

Cuando se le solicite, ingrese su dirección de correo electrónico y acepte las Condiciones del servicio. Si la validación del dominio es correcta, debería ver el siguiente resultado:

Output
Obtaining a new certificate
Performing the following challenges:
http-01 challenge for stubb.dev
Waiting for verification...
Cleaning up challenges

IMPORTANT NOTES:
 - Congratulations! Your certificate and chain have been saved at:
   /etc/letsencrypt/live/your_domain.com/fullchain.pem
   Your key file has been saved at:
   /etc/letsencrypt/live/your_domain.com/privkey.pem
   Your cert will expire on 2020-09-15. To obtain a new or tweaked
   version of this certificate in the future, simply run certbot
   again. To non-interactively renew *all* of your certificates, run
   "certbot renew"
 - Your account credentials have been saved in your Certbot
   configuration directory at /etc/letsencrypt. You should make a
   secure backup of this folder now. This configuration directory will
   also contain certificates and private keys obtained by Certbot so
   making regular backups of this folder is ideal.

Puede inspeccionar el certificado utilizando cat:

sudo cat /etc/letsencrypt/live/your_domain.com/fullchain.pem

Con el certificado TLS suministrado, podemos probar la configuración de Nginx que establecimos en el paso anterior:

docker run --rm --name nginx -p 80:80 -p 443:443 \
    -v ~/conf/nginx.conf:/etc/nginx/conf.d/nginx.conf:ro \
    -v /etc/letsencrypt:/etc/letsencrypt \
    -v /var/lib/letsencrypt:/var/lib/letsencrypt \
    -v /var/www/html:/var/www/html \
    nginx:1.19.0

Este es el mismo comando que ejecutamos en el Paso 3, con la adición de los dos directorios de Let’s Encrypt que acabamos de crear.

Una vez que Nginx esté en ejecución, diríjase a http://your_domain.com. Puede recibir una advertencia en su navegador indicando que la entidad de certificación no es válida. Esto es de esperar dado que suministramos certificados provisionales, no certificados de producción de Let’s Encrypt. Compruebe la barra de direcciones URL de su navegador para confirmar que su solicitud HTTP se haya redireccionado a HTTPS.

Presione CTRL+C en su terminal para salir de Nginx y volver a ejecutar el cliente certbot, omitiendo el indicador --staging:

docker run -it --rm -p 80:80 --name certbot \
         -v "/etc/letsencrypt:/etc/letsencrypt" \
         -v "/var/lib/letsencrypt:/var/lib/letsencrypt" \
         certbot/certbot certonly --standalone -d your_domain.com

Cuando se le solicite mantener el certificado existente o renovarlo y sustituirlo, presione 2 para renovarlo y, luego, presione ENTER para confirmar su elección.

Con el certificado TLS de producción suministrado, vuelva a ejecutar el servidor Nginx:

docker run --rm --name nginx -p 80:80 -p 443:443 \
    -v ~/conf/nginx.conf:/etc/nginx/conf.d/nginx.conf:ro \
    -v /etc/letsencrypt:/etc/letsencrypt \
    -v /var/lib/letsencrypt:/var/lib/letsencrypt \
    -v /var/www/html:/var/www/html \
    nginx:1.19.0

En su navegador, diríjase a http://your_domain.com. En la barra de direcciones URL, confirme que la solicitud HTTP se haya redireccionado a HTTPS. Dado que la aplicación Polls no tiene una ruta predeterminada configurada, debería ver un error de Django de **Página no encontrada **. Diríjase a https://your_domain.com/polls para ver la interfaz estándar de la aplicación Polls:

En este punto, ha suministrado un certificado TLS de producción utilizando el cliente de Docker Certbot y está redirigiendo las solicitudes externas a través del proxy inverso y equilibrando la carga entre los dos servidores de aplicaciones de Django.

Los certificados de Let’s Encrypt caducan cada 90 días. Para asegurarse de que su certificado permanezca válido, debe renovarlo regularmente antes de su vencimiento programado. Con Nginx en ejecución, debe usar el cliente de Certbot en modo webroot en vez de standalone. Esto significa que Certbot realizará la validación creando un archivo en el directorio /var/www/html/.well-known/acme-challenge/ y la regla location definida en la configuración de Nginx realizada en el Paso 3 capturará las solicitudes de validación de Let’s Encrypt a esta ruta. A continuación, Certbot rotará los certificados, y usted podrá volver a cargar Nginx para que utilice este certificado recién suministrado.

Hay varias formas de automatizar este procedimiento, pero la renovación automática de certificados TLS está fuera del alcance de este tutorial. Para obtener un proceso similar usando la utilidad de programación cron, consulte el paso 6 de Cómo proteger una aplicación de Node.js en un contenedor con Nginx, Let’s Encrypt y Docker Compose.

En su terminal, presione CTRL+C para cerrar el contenedor de Nginx. Vuelva a ejecutarlo en modo separado al agregar el indicador -d:

docker run --rm --name nginx -d -p 80:80 -p 443:443 \
	-v ~/conf/nginx.conf:/etc/nginx/conf.d/nginx.conf:ro \
	-v /etc/letsencrypt:/etc/letsencrypt \
	-v /var/lib/letsencrypt:/var/lib/letsencrypt \
  -v /var/www/html:/var/www/html \
	nginx:1.19.0

Con Nginx ejecutándose en segundo plano, utilice el siguiente comando para realizar una ejecución de prueba del procedimiento de renovación de certificados:

docker run -it --rm --name certbot \
	-v "/etc/letsencrypt:/etc/letsencrypt" \
  -v "/var/lib/letsencrypt:/var/lib/letsencrypt" \
  -v "/var/www/html:/var/www/html" \
  certbot/certbot renew --webroot -w /var/www/html --dry-run

Utilizamos el complemento --webroot, especificamos la ruta web root y utilizamos el indicador --dry-run para verificar que todo funciona correctamente sin realizar la renovación de certificados real.

Si la simulación de la renovación se realiza correctamente, debería ver el siguiente resultado:

Output
Cert not due for renewal, but simulating renewal for dry run
Plugins selected: Authenticator webroot, Installer None
Renewing an existing certificate
Performing the following challenges:
http-01 challenge for your_domain.com
Using the webroot path /var/www/html for all unmatched domains.
Waiting for verification...
Cleaning up challenges

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
new certificate deployed without reload, fullchain is
/etc/letsencrypt/live/your_domain.com/fullchain.pem
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
** DRY RUN: simulating 'certbot renew' close to cert expiry
**          (The test certificates below have not been saved.)

Congratulations, all renewals succeeded. The following certs have been renewed:
  /etc/letsencrypt/live/your_domain.com/fullchain.pem (success)
** DRY RUN: simulating 'certbot renew' close to cert expiry
**          (The test certificates above have not been saved.)
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

En un entorno de producción, después de renovar los certificados, debe volver a cargar Nginx para que los cambios surtan efecto. Para volver a cargar Nginx, ejecute el siguiente comando:

docker kill -s HUP nginx

Este comando enviará una señal HUP Unix al proceso de Nginx que se está ejecutando en el contenedor de Docker nginx. Al recibir esta señal, Nginx volverá a cargar su configuración y sus certificados renovados.

Con HTTPS habilitado y todos los componentes de esta arquitectura en ejecución, el paso final es bloquear la configuración al evitar el acceso externo a los dos servidores de aplicaciones backend; todas las solicitudes HTTP deben pasar por el proxy de Nginx.

Paso 5: Prevención de acceso externo a servidores de aplicaciones de Django

En la arquitectura que se describe en este tutorial, la terminación de SSL se produce en el proxy de Nginx. Esto significa que Nginx descifra la conexión SSL y los paquetes se redirigen, a través del proxy, a los servidores de aplicaciones de Django no cifrados. Para muchos casos de uso, este nivel de seguridad es suficiente. Para las aplicaciones que incluyen datos financieros o de salud, es conveniente implementar cifrado de extremo a extremo. Puede hacerlo al reenviar paquetes cifrados a través del equilibrador de carga y descifrarlos en los servidores de aplicaciones o volver a cifrarlos en el proxy y descifrarlos nuevamente en los servidores de aplicaciones de Django. Estas técnicas están fuera del alcance de este artículo, pero puede consultar el documento Cifrado de extremo a extremo para obtener más información.

El proxy de Nginx actúa como una puerta de enlace entre el tráfico externo y la red interna. En teoría, ningún cliente externo debería tener acceso directo a los servidores de aplicaciones internos y todas las solicitudes deberían pasar a través del servidor de Nginx. La nota del Paso 1 describe brevemente un problema abierto con Docker en el que Docker omite la configuración de firewall ufw de manera predeterminada y abre los puertos de forma externa, lo que puede ser peligroso. Para solucionar este problema de seguridad, se recomienda usar firewalls para la nube al trabajar con servidores con Docker. Para obtener más información sobre la creación de firewalls para la nube con DigitalOcean, consulte Cómo crear firewalls. También puede manipular iptables directamente en lugar de usar ufw. Para obtener más información sobre el uso de iptables con Docker, consulte Docker e iptables.

En este paso, modificaremos la configuración de UFW para bloquear el acceso externo a los puertos del host que abre Docker. Al ejecutar Django en los servidores de aplicaciones, pasamos el indicador -p 80:8000 a docker, que reenvía el puerto 80 del host al puerto 8000 del contenedor. Esto también abrió el puerto 80 a clientes externos, lo que puede verificar al dirigirse a http://your_app_server_1_IP. Para evitar el acceso directo, modificaremos la configuración de UFW utilizando el método que se describe en el repositorio de GitHub ufw-docker.

Comience por iniciar sesión en el primer servidor de aplicaciones de Django. A continuación, abra el archivo /etc/ufw/after.rules con privilegios de superusuario, utilizando nano o su editor favorito:

sudo nano /etc/ufw/after.rules

Cuando se le solicite, ingrese su contraseña y, luego, presione ENTER para confirmar.

Debería ver las siguientes reglas ufw:

#
# rules.input-after
#
# Rules that should be run after the ufw command line added rules. Custom
# rules should be added to one of these chains:
#   ufw-after-input
#   ufw-after-output
#   ufw-after-forward
#

# Don't delete these required lines, otherwise there will be errors
*filter
:ufw-after-input - [0:0]
:ufw-after-output - [0:0]
:ufw-after-forward - [0:0]
# End required lines

# don't log noisy services by default
-A ufw-after-input -p udp --dport 137 -j ufw-skip-to-policy-input
-A ufw-after-input -p udp --dport 138 -j ufw-skip-to-policy-input
-A ufw-after-input -p tcp --dport 139 -j ufw-skip-to-policy-input
-A ufw-after-input -p tcp --dport 445 -j ufw-skip-to-policy-input
-A ufw-after-input -p udp --dport 67 -j ufw-skip-to-policy-input
-A ufw-after-input -p udp --dport 68 -j ufw-skip-to-policy-input

# don't log noisy broadcast
-A ufw-after-input -m addrtype --dst-type BROADCAST -j ufw-skip-to-policy-input

# don't delete the 'COMMIT' line or these rules won't be processed
COMMIT

Pegue el siguiente bloque de reglas de configuración de UFW en la parte inferior:

. . .

# BEGIN UFW AND DOCKER
*filter
:ufw-user-forward - [0:0]
:DOCKER-USER - [0:0]
-A DOCKER-USER -j RETURN -s 10.0.0.0/8
-A DOCKER-USER -j RETURN -s 172.16.0.0/12
-A DOCKER-USER -j RETURN -s 192.168.0.0/16

-A DOCKER-USER -p udp -m udp --sport 53 --dport 1024:65535 -j RETURN

-A DOCKER-USER -j ufw-user-forward

-A DOCKER-USER -j DROP -p tcp -m tcp --tcp-flags FIN,SYN,RST,ACK SYN -d 192.168.0.0/16
-A DOCKER-USER -j DROP -p tcp -m tcp --tcp-flags FIN,SYN,RST,ACK SYN -d 10.0.0.0/8
-A DOCKER-USER -j DROP -p tcp -m tcp --tcp-flags FIN,SYN,RST,ACK SYN -d 172.16.0.0/12
-A DOCKER-USER -j DROP -p udp -m udp --dport 0:32767 -d 192.168.0.0/16
-A DOCKER-USER -j DROP -p udp -m udp --dport 0:32767 -d 10.0.0.0/8
-A DOCKER-USER -j DROP -p udp -m udp --dport 0:32767 -d 172.16.0.0/12

-A DOCKER-USER -j RETURN
COMMIT
# END UFW AND DOCKER

Estas reglas restringen el acceso público a los puertos que abre Docker y permiten el acceso a los intervalos de IP privadas 10.0.0.0/8, 172.16.0.0/12 y 192.168.0.0/16. Si usa VPC con DigitalOcean, entonces, las Droplets de su red VPC tendrán acceso al puerto abierto a través de la interfaz de red privada, pero los clientes externos no lo tendrán. Para obtener más información sobre las VPC, consulte la documentación oficial de las VPC. Para obtener más información sobre las reglas implementadas en este fragmento de código, consulte ¿Cómo funciona? en el archivo README de ufw-docker.

Si no está utilizando VPC con DigitalOcean y ha introducido las direcciones IP públicas de los servidores de aplicaciones en el bloque upstream de su configuración de Nginx, deberá modificar explícitamente el firewall UFW para que permita tráfico del servidor de Nginx a través del puerto 80 de los servidores de aplicaciones de Django. Para obtener información sobre la creación de reglas allow con el firewall de UFW, consulte Aspectos básicos de UFW: reglas y comandos comunes de firewall.

Una vez que haya finalizado la edición, guarde y cierre el archivo.

Reinicie ufw para que tome la nueva configuración:

sudo systemctl restart ufw

Diríjase a http://APP_SERVER_1_IP en su navegador web para confirmar que ya no pueda acceder al servidor de aplicaciones a través del puerto 80.

Repita este proceso en el segundo servidor de aplicaciones de Django.

Cierre sesión en el primer servidor de aplicaciones o abra otra ventana de terminal, e inicie sesión en el segundo servidor de aplicaciones de Django. A continuación, abra el archivo /etc/ufw/after.rules con privilegios de superusuario, utilizando nano o su editor favorito:

sudo nano /etc/ufw/after.rules

Cuando se le solicite, ingrese su contraseña y, luego, presione ENTER para confirmar.

Pegue el siguiente bloque de reglas de configuración de UFW en la parte inferior:

. . .

# BEGIN UFW AND DOCKER
*filter
:ufw-user-forward - [0:0]
:DOCKER-USER - [0:0]
-A DOCKER-USER -j RETURN -s 10.0.0.0/8
-A DOCKER-USER -j RETURN -s 172.16.0.0/12
-A DOCKER-USER -j RETURN -s 192.168.0.0/16

-A DOCKER-USER -p udp -m udp --sport 53 --dport 1024:65535 -j RETURN

-A DOCKER-USER -j ufw-user-forward

-A DOCKER-USER -j DROP -p tcp -m tcp --tcp-flags FIN,SYN,RST,ACK SYN -d 192.168.0.0/16
-A DOCKER-USER -j DROP -p tcp -m tcp --tcp-flags FIN,SYN,RST,ACK SYN -d 10.0.0.0/8
-A DOCKER-USER -j DROP -p tcp -m tcp --tcp-flags FIN,SYN,RST,ACK SYN -d 172.16.0.0/12
-A DOCKER-USER -j DROP -p udp -m udp --dport 0:32767 -d 192.168.0.0/16
-A DOCKER-USER -j DROP -p udp -m udp --dport 0:32767 -d 10.0.0.0/8
-A DOCKER-USER -j DROP -p udp -m udp --dport 0:32767 -d 172.16.0.0/12

-A DOCKER-USER -j RETURN
COMMIT
# END UFW AND DOCKER

Una vez que haya finalizado la edición, guarde y cierre el archivo.

Reinicie ufw para que tome la nueva configuración:

sudo systemctl restart ufw

Diríjase a http://APP_SERVER_2_IP en su navegador web para confirmar que ya no pueda acceder al servidor de aplicaciones a través del puerto 80.

Por último, diríjase a https://your_domain_here/polls para confirmar que el proxy de Nginx siga teniendo acceso a los servidores de Django que preceden en la cadena. Debería ver la interfaz predeterminada de la aplicación de Polls.

Conclusión

En este tutorial, configuró una aplicación Polls de Django escalable utilizando contenedores de Docker. A medida que su tráfico y la carga en el sistema aumenten, puede escalar cada capa de forma separada: la capa de redireccionamiento mediante proxy de Nginx, la capa de aplicaciones de backend de Django y la capa de la base de datos de PostgreSQL.

Crear un sistema distribuido suele implicar tener que tomar varias decisiones de diseño, y encontrará varias arquitecturas disponibles para satisfacer su caso de uso. La arquitectura que se describe en este tutorial se presenta como un plan flexible para diseñar aplicaciones escalables con Django y Docker.

Probablemente desee controlar el comportamiento de sus contenedores cuando detecten errores o ejecutar contenedores de forma automática al iniciar su sistema. Para hacerlo, puede usar un administrador de procesos como Systemd o implementar directivas de reinicio. Para obtener más información al respecto, consulte Iniciar contenedores de forma automática en la documentación de Docker.

Al trabajar a gran escala con varios hosts ejecutando la misma imagen de Docker, puede resultar más eficaz automatizar los pasos utilizando una herramienta de administración de configuración como Ansible o Chef. Para obtener más información sobre la administración de configuración, consulte Introducción a la administración de configuración y Configuración de la automatización con Ansible: Un kit del taller de DigitalOcean.

En lugar de compilar la misma imagen en cada host, también puede simplificar la implementación utilizando un registro de imágenes como Docker Hub, que compila, almacena y distribuye imágenes de Docker en varios servidores. Además de un registro de imágenes, una canalización de integración e implementación continua puede ayudarlo a compilar, probar e implementar imágenes en sus servidores de aplicaciones. Para obtener más información sobre CI/CD, consulte Introducción a las prácticas recomendadas de CI/CD.