CAPÍTULO 9 · El mismo proyecto llega a Azure
El proyecto necesita una casa fuera del computador
Hasta aquí conocemos el código y las condiciones que necesita para trabajar. Publicarlo no consiste únicamente en trasladar una carpeta: tenemos que proporcionar un lugar donde se ejecute, una configuración y recursos acordes con lo que ofreceremos. App Service entra en la historia como el alojamiento elegido para la aplicación web.
Distinguimos el grupo de recursos, la aplicación y el plan que aporta capacidad. Seleccionamos la pila de Python compatible con nuestras dependencias y reconocemos el hostname inicial. GitHub continúa siendo el lugar donde controlamos versiones, pero el procedimiento del equipo no conecta automáticamente ese repositorio con el despliegue. La entrega se preparará como un ZIP decidido y revisado por nosotros.
Antes de enviarlo necesitamos completar su entorno. Si SensorHub usa PostgreSQL, la base no aparece por el hecho de crear la aplicación web. Debemos elegir su propio servicio, dimensionarlo y comprobar que puede sostener la carga que esperamos recibir.
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
La casa y su terreno
Las flechas muestran responsabilidades relacionadas; no representan un orden obligatorio de ejecución.
Selecciona una pieza para destacar su responsabilidad.
Leer la explicación del mapa
- App Service. Ejecuta la aplicación web
- Plan. Define capacidad compartida
- Grupo. Organiza recursos
- Entra. Registra identidad aparte
01 / EL PROBLEMA
¿Para qué sirve?
La aplicación web y su plan aparecen juntos en el portal, pero cambiar uno tiene efectos diferentes de cambiar el otro.
02 / COMPRENDER
El concepto, explicado
El grupo de recursos agrupa elementos para administrarlos. App Service representa la aplicación desplegada y su configuración. El plan define la capacidad y las opciones de alojamiento; varias apps pueden compartirlo.
En la vista Introducción identifica nombre de la app, dominio, sistema operativo, runtime y enlace al plan. Esta práctica usa App Service Linux con publicación de código Python. No confundas el plan con el registro de aplicación en Entra.
La captura de referencia muestra F1: sirve como ejemplo de dónde leer el SKU, no como recomendación universal para producción. Consulta capacidades vigentes, región y necesidad de slots o continuidad antes de escogerlo.
Gunicorn no exige un plan B2 por definición. Dimensiona procesos según memoria, carga y pruebas. La elección WSGI/ASGI es independiente de la identidad MSAL/Easy Auth.
El flujo del autor usa VS Code y GitHub para controlar versiones; la publicación se decide manualmente y se realiza con un ZIP. Vincular el repositorio al Deployment Center no es un requisito de este recorrido.
F1 ofrece una cuota de 60 minutos de CPU por día; no equivale a una hora continua de reloj con el sitio abierto. Sus límites hacen que una compilación o una aplicación pesada pueda no caber. Escalar temporalmente puede ayudar si el diagnóstico confirma falta de recursos, pero no corrige dependencias incompatibles y el runtime debe caber al volver a F1.
Para el primer despliegue usamos el dominio azurewebsites.net. Los dominios personalizados quedan como ampliación posterior: F1 no los admite. Para este recorrido Linux, revisa Basic o superior y las condiciones de TLS. Tampoco supongas que Basic incluye slots de staging.
03 / CONSTRUIR
Implementación paso a paso
- Crear o elegir la suscripción y un grupo de recursos para SensorHub y su entorno.
- Crear una aplicación web: publicación de código, sistema Linux y pila Python. Elegir una versión compatible con Django y las dependencias; contrastar 3.12 o 3.13 con las opciones que ofrezca el portal. Python 3.2 no es la versión que se pretende usar.
- Elegir región y plan según memoria, CPU, disponibilidad y presupuesto. Separar el costo de App Service del de PostgreSQL y observabilidad.
- Anotar el hostname azurewebsites.net y decidir si se requiere PostgreSQL Flexible Server. Crear y validar la conexión en la lección siguiente.
- Configurar variables, comando de arranque y autenticación antes de subir el paquete. Mantener desconectada la integración de despliegue con GitHub en este recorrido manual.
- Subir deploy.zip por una operación de despliegue admitida y verificar logs, salud, estáticos y acceso a datos.
04 / APLICAR
Ejemplo en SensorHub
# PowerShell con Azure CLI; consultas de inventario
$rg = "rg-sensorhub-dev"
$app = "app-sensorhub-dev"
az webapp show -g $rg -n $app --query "{app:name,host:defaultHostName,plan:serverFarmId,state:state}" -o table
az webapp config show -g $rg -n $app --query "{runtime:linuxFxVersion,startup:appCommandLine}" -o table
az appservice plan list -g $rg --query "[].{plan:name,tier:sku.tier,size:sku.name}" -o table
# Versiones ofrecidas actualmente; PowerShell:
az webapp list-runtimes --os linux -o tsv | Select-String PYTHON
# Escoge una versión soportada y probada con tu requirements.txt.Cómo leer el ejemplo
- Las consultas muestran la separación app/plan sin modificar recursos.
- La versión de Python se selecciona en el stack; una variable arbitraria PYTHON_VERSION no sustituye esa configuración.
Error habitual
Escalar un plan compartido puede afectar capacidad o costo de otras apps. Revisa el inventario antes de hacerlo.
05 / PRACTICAR
Tu turno
Explica dónde cambiarías el comando de arranque y dónde revisarías el SKU.
Ver solución orientativa
El arranque pertenece a la configuración de la app. El SKU pertenece al plan al que apunta serverFarmId.
06 / VERIFICAR
Cómo sabes que funciona
- Puedes identificar app, plan y registro Entra por separado.
- La versión local y la del stack son compatibles.
Para profundizar
Documentación oficial para comprobar configuración, permisos y condiciones vigentes. Revisión del tema: 2026-10-12.
CONTINUAR LA EXPERIENCIA
El siguiente paso del recorrido:
PostgreSQL Flexible Server: capacidad y costo inicial →Continuar en modo relato