Logo Azure Web Apps En el anterior artículo expliqué qué es una Plataforma como Servicio (PaaS) en la nube y por qué son interesantes. Presenté la PaaS de Microsoft, llamada Azure Web Apps, así como sus ventajas, sus inconvenientes, sus precios y para quién es adecuada.

Ahora vamos a la parte práctica de cómo montar una aplicación real sobre Azure Web Apps, siguiendo el ejemplo de este blog, que migré sin adaptaciones a este servicio.

Parto de la base de que tienes una cuenta válida de Azure o que al menos ya has ido a su web y te has creado una cuenta de prueba. La cuenta de prueba te da 170€ para gastar en 30 días, por lo que dan mucho de sí y al terminar puedes usar muchos productos gratuitos, entre ellos las Azure Web Apps, aunque eso sí, sin dominio propio y compartiendo infraestructura.

Nota: todas las capturas que verás a continuación están en inglés porque ese es el idioma que uso en todo el software que utilizo (incluso en el móvil). El motivo de usarlo siempre es que toda la documentación en este idioma suele estar mejor que en español (salvo honrosas excepciones) y es más abundante. Por lo tanto cuando surge un problema es mucho más fácil encontrar soluciones en el idioma de Shakespeare que en el de Cervantes, así que para mi no hay otra opción lógica. Además, el software lo prueban infinitamente más en inglés que en otros idiomas por lo que es menos probable que haya problemas también.

1.- Crear la Web App - Datos básicos

Lo primero que debemos hacer una vez hayamos accedido al portal de Azure es crear una nueva Web App. Para ello pulsamos en el botón de "Nuevo" con un más, arriba a la izquierda, y elegimos la sección Web + Mobile y dentro de esta Web App:

Diálogo de selección de nueva Web App

Al pulsar el primer enlace (el de debajo nos lleva a un tutorial) se nos muestra información sobre el producto y al continuar se nos piden una serie de datos básicos que debemos rellenar:

Datos básicos de la Web App

Lo primero es darle un nombre único entre todas las Web Apps que alberga Azure, lo cual salvo que sea algo muy específico puede ser complicado. En el ejemplo de mi blog, como vemos en la figura anterior, no hubo problema y se puede acceder a través de https://jasoft.azurewebsites.net. Esa será la dirección por defecto para el servicio, y a través de la cual accederemos mientras lo estemos configurando inicialmente.

Nota: Luego veremos que con un poco de configuración es posible evitar que se acceda a través de ahí y que se utilice tan solo nuestro dominio principal, lo cual además es importante para SEO (optimización de cara a buscadores).

Lo siguiente es la suscripción de Azure que quieres usar, ya que puedes tener más de una activa al mismo tiempo (como es mi caso que tengo una personal y una de empresa).

Los grupos de recursos es simplemente una manera de agrupar los diferentes servicios que tienes activados en Azure, de modo que luego los puedas gestionar en grupo o, al menos, listar todos juntos. Puedes crear uno nuevo o reutilizar uno existente. En mi caso opté por la segunda opción y reutilicé un grupo de recursos que tengo para mis webs personales y algunas otras cosas similares.

Ahora sí, un paso muy importante: el sistema operativo que quieres usar. Tienes dos opciones: Windows y Linux. Dependiendo de la tecnología que utilices para tu aplicación deberás escoger uno u otro, aunque hay tecnológicas (como PHP, Node.js, Python o .NET Core) que funcionarían sin problema en ambos. Si este es el caso puedes escoger Linux. La ventaja de Linux sobre Windows en Azure Web Apps es que, ahora mismo, permiten además desplegar contenedores Docker, cosa que en Windows todavía no es posible en este servicio. En mi caso, dado que mi blog usa Blog Engine (lamentablemente) y es una aplicación escrita en .NET 4.x (o sea, .NET "clásico"), necesito Windows.

La ubicación y el plan de servicio es el parámetro más importante. Con esto le indicamos dos cosas. En primer lugar qué plan de servicio queremos utilizar. El plan de servicio es el tipo y el tamaño de los recursos que queremos dedicar a la Web, lo cual condiciona qué características podemos usar y por supuesto el precio. Mientras no tengamos configurado el funcionamiento básico de la aplicación, y mientras no le asignemos un dominio propio (o a lo mejor ni siquiera quieres hacerlo) podemos elegir la capa gratuita que hemos visto o bien una de las compartidas, que te dan más potencia pero son muy baratas. Para subir de nivel tenemos tiempo luego y así mientras no dejemos la app configurada ahorramos unos céntimos 😄

Al crear el plan de servicio debemos elegir también la ubicación, es decir, en qué área geográfica del mundo queremos que esté ubicado nuestro plan de servicio. Esto tiene su importancia, sobre todo si no vamos a usar un servicio de CDN para distribuir nuestros contenidos. Cuánto más cerca estemos de nuestros visitantes mejor. En mi caso la mayor parte del tráfico viene de España (y es donde estoy yo también) por lo que ubicarlo en Europa tiene todo el sentido. Dentro de Europa tenemos la zona Norte (con Data Centers en Irlanda y Reino Unido) o la zona Oeste (con DCs en Alemania, Holanda y otros países de la zona). Aquí tienes información sobre todas las ubicaciones. A efectos prácticos es indiferente escoger la zona norte o la oeste de Europa para este servicio, así que como ya tenía otros servicios en la zona oeste, elegí esa.

Lo de Application Insights de momento lo dejaremos desactivado. Se trata de servicios para monitorizar la aplicación.

Le damos a Crear y empieza el despliegue inicial de la Web App. Al cabo de unos segundos habrá terminado y veremos una notificación parecida a esta:

Notificación de servicio creado y desplegado

¡Listo! Ahora hay que instalar tu aplicación

2.- Configuración técnica

Al acceder a la página principal de nuestra Web App veremos que se nos informa de sus datos básicos (nombre, estado, ubicación, dirección de acceso, sistema operativo que en mi caso es Windows Server 2016 pero que realmente no nos importa pues es una de las ventajas de PaaS). También tenemos unas gráficas debajo que ahora están en blanco pero que nos darán información en el futuro sobre cómo está funcionando la aplicación:

Página inicial de la Azure Web App

Lo primero que deberíamos hacer es configurar las tecnologías que necesitaremos utilizar en nuestra aplicación. Para ello, en el menú lateral tenemos el grupo Settings > Application Settings (recuadrado en rojo en la figura anterior).

Al acceder a este apartado podremos configurar los aspectos técnicos de nuestra aplicación:

Ajustes técnicos de la app

Yo lo primero que hago es desactivar las tecnologías que no voy a utilizar: cuantas menos cosas activadas menor es la superficie de ataque y más seguro será el servicio (y más rendimiento arañaremos). Así que dejo .NET 4.7 y desactivo PHP, Java, etc... Además desactivo los Web Sockets ya que no los voy a necesitar, y tampoco le activo la opción de Always On ya que el sitio tiene tráfico suficiente para mantenerla siempre en marcha.

Aquí hay dos parámetros que merecen mención aparte.

El primero de ellos es el tipo de plataforma, si es de 32 o de 64 bits. La tentación siempre es ir y marcar la de 64 bits, a pesar de que por defecto está seleccionada la de 32 bits. Es natural, al fin y al cabo 64bits se asocia con sistemas operativos modernos, mejor manejo de memoria, más rendimiento... Lo cierto es que no suele haber una buena razón para elegir la opción de 64 bits. Por el mero hecho de seleccionarla lo único que conseguiremos es que nuestra aplicación utilice una cantidad mucho mayor de memoria, lo cual en la mayor parte de los casos es innecesario y aumentará nuestros costes a largo plazo si tenemos que escalar. La diferencia de rendimiento no existe, y si no necesitamos acceder a las cantidades enormes de memoria que nos habilitan los 64 bits, merece la pena dejarlo en 32 bits. Con 32 bits puedes direccionar hasta 4GB de memoria, más que suficiente para la mayor parte de las aplicaciones. De hecho la mayor parte de los planes de servicio no te dan tanta memoria en cualquier caso. Entonces, salvo que tengamos un plan grande (y caro) de Azure Web Apps y necesitemos usar toda esa memoria, es mejor no cambiarlo.

El otro parámetro interesante de la pantalla anterior es el tipo de pipeline que queremos usar. Esto es un ajuste que tenemos en IIS para los pools de aplicaciones y puede tomar dos valores:

  • Integrado: las peticiones que llegan pasan por la arquitectura integrada de IIS y .NET, siguiendo una serie de pasos ordenados de manera que se van llamando todos los módulos necesarios para procesar la petición (nativos del sistema y gestionados por .NET). De este modo además es posible utilizar .NET y cualquier módulo creado con esta tecnología para procesar parte de la petición, pudiendo, por ejemplo, añadir autenticación y autorización para recursos que no son de .NET por defecto (como un archivo de imagen o de CSS). Tiene varias ventajas y normalmente es la que deberíamos utilizar salvo que nuestra aplicación no lo soporte.
  • Clásico: en este modo las peticiones van primero a través de IIS y módulos nativos, y luego se pasan a .NET en caso de que sean recursos propios de esta tecnología, para pasar de nuevo a los pasos finales del pipeline de IIS y poder devolver el resultado. Esto implica pasos duplicados y menos eficientes para recursos .NET aunque , por ejemplo, las peticiones a recursos estáticos como imágenes o archivos CSS no son procesadas por .NET y por lo tanto irán un poco más ágiles. Sin embargo no podremos usar .NET para interceptar las peticiones a esos recursos y hacer cosas con las peticiones, como por ejemplo autenticarlas y autorizarlas, o cambiar lo que devuelven.

Personalmente me encanta el control que te permite obtener el modo integrado y es el valor que utilizo. En tu caso deberías ver si la aplicación que vas a instalar te permite usar el modo integrado. Salvo que sea muy antigua no deberías tener problema. Si quieres profundizar un poco más en el tema, en este documento de Microsoft te lo explican un poco más.

Más tarde volveremos sobre esta sección del portal para ver algunos ajustes adicionales, pero de momento con esto es suficiente.

3.- Despliegue de la aplicación

Una vez que has ajustado las tecnologías que quieres utilizar, lo único que resta para las primeras pruebas es desplegar tu aplicación al servicio. En Azure Web Apps existen muchas formas de hacerlo. De hecho hay toda una sección para esto, en el lateral, dentro de la configuración del servicio:

Sección de despliegue de la Web App

La opción interesante en este caso es la que reza Deployment Options (o, en español, Opciones de Despliegue). Desde aquí tenemos la opción de elegir desde dónde queremos desplegar nuestra aplicación, no solo ahora, sino en el futuro a medida que haya cambios y actualizaciones.

Si pulsamos sobre esa opción se nos abre una nueva "hoja" del portal de azure en la que debemos elegir un origen para el despliegue y se nos ofrecen diversas opciones:

Proceso de selección de método de despliegue

Como vemos podemos elegir desplegar desde OneDrive, Dropbox o desde diversos servicios Git. Incluso desde un repositorio Git que tengamos creado en local en nuestro equipo (basta con añadir la web app como remoto para desplegar).

Personalmente encuentro muy útil desplegar desde Dropbox cuando tocamos el sitio muy poco a menudo y lo hacemos editando directamente los archivos en disco. Lo malo de esta opción es que hay que entrar en el portal de Azure y darle a un botón cada vez que quieres desplegar (o automatizarlo, claro, pero para mi pierde la gracia). En cambio, usando un repositorio Git local o remoto es más fácil, puesto que solo hay que hacer un commit a una rama determinada y listo. En cualquier caso la Web app guardará versiones de los últimos despliegues para poder volver atrás con un clic si nos arrepentimos o si hay algún fallo. Se accede desde el mismo menú. Por ejemplo: esta captura es de un sitio web pequeñito que tengo para un "side project" que lo despliego desde Dropbox. Como vemos hay un histórico de despliegues y pulsando sobre cualquiera de los anteriores podemos ver sus datos y nos ofrecerá un botón de "redesplegar", de modo que volveremos al estado anterior en un momento:

Listado de despliegues desde Dropbox

En el caso de un gestor de contenidos o un software de ese estilo en el que, una vez instalado, lo normal es que gestionemos todo desde la propia aplicación, lo más fácil será utilizar el tradicional FTP para desplegar. En el caso del ejemplo con mi blog es lo que haré.

Una tentación grande que existe (y que en mi opinión es un fallo grande de Microsoft), es utilizar la opción que dice Deployment Credentials o Credenciales de despliegue que está en este mismo grupo y que aparentemente te deja establecer una cuenta de FTP para el servicio. Como ya expliqué en este blog hace una temporada eso es un error ya que estaremos cambiando las credenciales para la cuenta de Azure completa, no solo para este sitio web. La forma correcta de hacerlo es usando el botón de Get Publish Profile que tenemos en la portada del sitio, tal y como explico en el enlace anterior. Esto, Microsoft, debería mejorarlo y hacerlo mucho más claro.

Una vez que tengamos las credenciales accedemos por FTP y vemos los contenidos actuales, que constan de una única página por defecto que la que vemos al acceder al sitio desde el navegador, y que debemos borrar para copiar nuestra aplicación:

La página por defecto del sitio

Fíjate en que la aplicación web se almacena bajo una carpeta llamada wwwroot que a su vez es hija de otra carpeta llamada site. Es importante conocer esta ruta, como veremos a continuación. Copia en wwwroot los archivos de tu aplicación.

En el caso de una aplicación .NET como BlogEngine lo normal es que llegue con simplemente copiar los archivos de la aplicación, cosa que hice.

En el caso de este blog hay un detalle especial que hace que tenga que configurar una cuestión adicional y que me viene bien para explicar otra configuración interesante: la creación de directorios y aplicaciones virtuales bajo Azure Web Apps.

Si te fijas, mi blog no se ejecuta en la raíz de la web sino que está ubicado bajo una carpeta llamada Blog, de ahí que todas las rutas llevan /Blog delante. Esto es así por razones históricas ya que en lo más de 20 años que tiene el dominio ha pasado por varios sistemas y ni siquiera fue un blog en sus inicios (porque no existían). El caso es que para que BlogEngine funcione correctamente en esa subcarpeta, la tengo que convertir en una aplicación web. Esto en IIS se hace desde el administrador de sitios, y en Azure Web Apps tenemos que recurrir nuevamente al apartado Application Settings que hemos visto antes. En la parte de abajo de éste tenemos un apartado de Aplicaciones y carpetas virtuales que es en donde debemos configurarlo.

En el caso concreto de mi blog la configuración es la siguiente:

Definir una carpeta virtual

Fíjate en cómo tenemos dos aplicaciones web configuradas. Una es la raíz de la web, que es configurada automáticamente por Azure. La otra es la aplicación de mi blog que está bajo una carpeta que lleva el mismo nombre que la carpeta física, pero que no tendría por qué ser así. En el lado izquierdo debemos definir la ruta relativa desde la raíz de la web en la que queremos configurar la aplicación. En el cuadro de texto de la derecha es la ruta física relativa a la raíz en donde está el código de la aplicación que vamos a configurar.

Importante: en este apartado de configuración tenemos también la posibilidad de establecer ciertos ajustes propios de la aplicación, como cadena de conexión, parámetros propios o manejadores de peticiones. Esto son equivalentes a los que meteríamos en el web.config de nuestra aplicación, pero con una salvedad: no quedan guardados en el web.config de la app, solo son accesibles desde aquí y además tienen prioridad sobre los que hayas establecido en el web.config de la aplicación. Esto es estupendo puesto que te permite gestionar parámetros privados (como contraseñas o configuraciones sensibles) sin que otros desarrolladores que tengan acceso a la misma aplicación puedan verlo.

Bien, con esto ya está la aplicación configurada ya que en mi caso no necesito cambiar ningún ajuste más, puesto que no utiliza bases de datos y todo lo necesario lo tiene en el sistema de archivos. Toca hacer una primera prueba para comprobar que está empezando a funcionar.

Así que vamos a la dirección por defecto que tiene el sitio web con una navegador. La primera petición tarda un poco mientras se levanta el servicio por primera vez.

En mi caso, la cosa no pinta bien:

Error al intentar acceder por primera vez

El motivo ya nos lo dice el propio navegador y no tiene nada que ver con Azure, sino con el funcionamiento de BlogEngine. Existe un ajuste de este sistema de blogs que sirve para indicar si se debe añadir automáticamente la www delante del nombre de dominio en caso de acceder con un dominio que no lo lleve. Cosas de SEO, y mi blog lo tiene activado. Si intentas acceder sin la www se la añadirá y hará una redirección. Este es el motivo de ver esa dirección tan rara en la barra del navegador. Y no funciona porque el dominio www.jasoft.azurewebsites.net no existe. Pero al mismo tiempo me está indicando que la aplicación ha funcionado, ya que le ha metido ese www delante 😊

Para solucionarlo en este caso de BlogEngine edito el archivo settings.xml de la carpeta App_Data y cambio el valor de handlewwwsubdomain a remove desde el add original:

Cambio de parámetro de BlogEngine

Con esto evito que le meta la triple w delante. Para que funcione tengo qeu hacer dos cosas:

  1. Reiniciar el servicio. Lo cual se hace desde la portada con el bot´no "Restar" o "Reiniciar".
  2. Borrar la caché del navegador (o usar otro navegador diferente), ya que BlogEngine hace una redirección permanente y por lo tanto el navegador la tiene cacheada y no vuelve a enviar peticiones a la URL correcta, yendo directamente a la redirigida con la wwww incluso en el modo "privado". En el caso de Chrome llega con eliminar el historial de navegación de la última hora (periodo mínimo que permite) y las imágenes y archivos cacheados:

Borrar la caché en Chrome

Haciendo esto el blog funciona a la perfección y todo está como era de esperar:

El blog ya funcionando

Lo suyo es probarlo bien. Si es una aplicación propia puedes pasarle las pruebas unitarias si las tienes. En cualquier caso conviene navegar por él, autenticarse, y realizar las operaciones más comunes (en mi caso crear un post, editarlo, meter un comentario, etc...).

4.- Cambiar el plan de servicio

Salvo que la Web App la hayas puesto ya dentro de un plan de servicio existente, con más aplicaciones, habrás creado uno gratuito en el segundo paso para poder probar y configurar sin coste.

Ahora que ya tienes la aplicación funcionando es hora de pasarla a un plan decente, de pago, para poder escalarla y, sobre todo, poder asignarle uno o varios dominios propios (podemos meter hasta 500, que es el límite, un poco arbitrario para mi gusto pues limita el tipo de app que puedes meter y compartir).

Para ello debes ir a la sección de ajustes y elegir la opción de Scale Up que ya indica que se refiere al plan de servicio:

Escalando nuestra app

La opción de Scale Out se refiere a crear más instancias de la misma aplicación, mientras que Scale Up, que es la que nos ocupa, se refiere a cambiar las capacidades del hardware subyacente, y por lo tanto la potencia de éste y su capacidad.

OJO: fíjate que esto se refiere siempre al plan de servicio, por lo que el cambio no se aplica tan solo a la aplicación, sino a todas las aplicaciones que tengas albergadas bajo el mismo plan de servicio, que pueden ser muchas. Yo, por ejemplo, tengo todos mis blogs y webs de proyectos secundarios personales metidas dentro del mismo plan de servicio, que las aguanta de sobra a pesar del tráfico.

En mi opinión las capas más interesantes son las dos de la parte superior de la siguiente figura:

Capas de plan de servicio

La gratuita es para jugar o para sitios realmente pequeños. La compartida solo merece la pena para ponerle un nombre de dominio propio. Puede ser suficiente para aplicaciones o sitios web pequeños, y aunque no tiene SSL no es problema si usas un servicio como CloudFlare que ya se encarga de darte SSL sin que tengas que tocar Azure.

En el caso de un proyecto más o menos serio deberías asignar un plan B1 o S1 al menos. Personalmente son los que me parecen más equilibrados. Ambos tienen 1 core y 1.75 GB de RAM. Puede parecer poco si tienes costumbre de administrar una máquina Windows Server, pero ten en cuenta que eso es procesador y memoria asignados en exclusiva a las aplicaciones web que albergues, por lo que dan mucho de sí. Puedes tener varias aplicaciones con un tráfico total elevado sin problema, y llegado el caso puedes escalar, bien usando un plan mayor o, mejor aún, creando nuevas instancias del plan actual sin necesidad de hacer nada: escala de forma transparente para tu aplicación y es una de las grandes ventajas de un servicio PaaS.

Ambos planes te dejan añadir certificados SSL propios y también permiten escalar las aplicaciones añadiendo más instancias (con la opción Scale Out que hemos visto antes). La ventaja del plan S1 es que te permite hacer este escalado de manera automática. Defines unas reglas y escala solo cuando lo necesite, sin que tengas ni que tocarlo. Además el S1 te ofrece también la opción de hacer backups diarios automáticos de todas las aplicaciones y te deja crear "slots" para tener varias versiones de la aplicación funcionando (por ejemplo, un slot de producción que es el que ven los usuarios, otro de pre-producción y otro de pruebas... cosas así, y cambiar entre ellos).

IMPORTANTE: En el caso de las instancias compartidas, las D1, hay que saber que cada sitio web que cuelgues te costará ese precio que te indica (8,16€ or sitio o app web). Sin embargo en los planes reservados normales como el B1 y el S1, el precio indicado es fijo, independientemente del número de sitios o aplicaciones web que cuelgues. Mientras te aguante, puedes meter los que quieras. Por eso, en cuanto tienes 3 o 4 sitios en un plan compartido te merece la pena irte al B1 aunque no tengan mucho tráfico. Eso sí, si escalas añadiendo nuevas instancias, cada instancia se cobra a ese mismo precio. Lo bueno es que si solo necesitas escalar durante unas horas para aguantar un tráfico elevado puntual lo único que se te cobra es ese tiempo, por lo que te puede salir por unos pocos céntimos.

En resumen

Bien, hasta ahora hemos visto qué es PaaS, en qué consiste el PaaS de Azure y sus ventajas e inconvenientes. En esta entrega hemos creado nuestra primera Web App en Azure y la hemos configurado y la hemos puesto en marcha.

En la próxima entrega explicaré cómo poner a andar el servicio con su propio dominio asignado (de hecho con varios), y cómo podemos asignarle un certificado digital para SSL de modo que protejamos las comunicaciones y mejoremos el SEO entre otros beneficios.

¡Espero que te esté resultando útil!

Si te interesa este tema, he publicado un eBook gratuito titulado "Guía Práctica - Azure Web Apps". Puedes descargarlo desde el enlace anterior.

💪🏻 ¿Este post te ha ayudado?, ¿has aprendido algo nuevo?
Pues NO te pido que me invites a un café... Te pido algo más fácil y mucho mejor

Escrito por un humano, no por una IA