CAPÍTULO 9 · El mismo proyecto llega a Azure
Estar encendido no demuestra estar disponible
El proceso puede arrancar y responder una página, pero todavía no sabemos si sus dependencias están listas o si una operación de negocio funciona. Una confirmación superficial podría hacer que demos por buena una entrega que falla al consultar los datos. El equipo necesita señales con un significado concreto.
Definimos comprobaciones de salud y disponibilidad, y observamos el arranque junto con el comportamiento esperado. Cada señal responde una pregunta distinta. No queremos una comprobación tan débil que siempre indique éxito ni una que exponga información privada para explicar un fallo.
Con esas señales podemos evaluar la versión recién publicada y reconocer cuándo requiere intervención. La entrega empieza a tener un final verificable, pero el proyecto seguirá cambiando. Debemos convertir este primer recorrido en un ciclo que podamos repetir, incluyendo la posibilidad de recuperar una versión conocida cuando algo no resulte bien.
Leer esta parte dentro del relato completo →DEL RELATO A LA PRÁCTICA
Vamos a desarrollar esta decisión con su mapa, explicación, código y ejercicio.
MIRA · CONECTA · COMPRENDE
Publicar y comprobar el servicio
Las flechas resumen el recorrido conceptual. Los controles y dependencias se detallan debajo.
Selecciona una pieza para destacar su responsabilidad.
Leer la explicación del mapa
- Artefacto. Versionado y reproducible
- Destino. Configuración y secretos
- Salud. Verifica servicio y dependencias
- Observación. Detecta fallos y consumo
01 / EL PROBLEMA
¿Para qué sirve?
Que runserver arranque no significa que el servicio esté listo para producción. Debes gestionar estáticos, migraciones, TLS y dependencias.
02 / COMPRENDER
El concepto, explicado
Liveness indica que el proceso responde. Readiness verifica dependencias necesarias para atender; SELECT 1 solo comprueba conectividad básica.
El pool de conexiones es por proceso. Su techo crece como max_size × procesos × instancias. Mide espera, latencia y errores antes de ampliar capacidad.
03 / CONSTRUIR
Implementación paso a paso
- Configura secretos y hosts.
- Ejecuta migraciones y estáticos.
- Arranca WSGI o ASGI según protocolos.
- Verifica salud y observa latencia y errores.
04 / APLICAR
Ejemplo en SensorHub
# Ejecutar con settings de producción y variables configuradas.
python manage.py check --deploy
python manage.py migrate
python manage.py collectstatic --noinput
# HTTP WSGI:
gunicorn config.wsgi:application --bind 0.0.0.0:8000
# HTTP + WebSocket: un servidor ASGI con Channels configurado.
# daphne -b 0.0.0.0 -p 8000 config.asgi:applicationCómo leer el ejemplo
- GitHub almacena el código, pero GitHub Pages no ejecuta un backend Django.
- Para WebSockets necesitas configurar ASGI, rutas y channel layer, no cambiar solo el comando.
- El disco local puede ser efímero: planifica persistencia de base de datos y archivos.
Error habitual
Un endpoint ready que devuelve 200 no demuestra que existan todas las tablas o que SMTP funcione. Define qué dependencias debe comprobar.
05 / PRACTICAR
Tu turno
Calcula el techo de un pool de 12 conexiones, 4 procesos y 2 instancias.
Ver solución orientativa
12 × 4 × 2 = 96 conexiones posibles de la aplicación, además de otros clientes y operaciones de administración.
06 / VERIFICAR
Cómo sabes que funciona
- Despliegue funciona con DEBUG=False.
- Errores y latencia pueden correlacionarse con operaciones concretas.
CONTINUAR LA EXPERIENCIA
El siguiente paso del recorrido:
Ciclo de entrega: verificar, promover y recuperar →Continuar en modo relato