De test a producción en dos clicks con Azure Web Apps

Web Apps es el nuevo nombre para Web Sites, que se engloban dentro del nuevo Azure App Service. Este servicio nos permite crear, desplegar y mantener de forma muy fácil y rápida nuestras aplicaciones web y APIs usando .Net, Node, Python, PHP y Java.

Una característica muy interesante de las Web Apps son los slots de despliegue. Es parecida al modelo production/staging de los Cloud Services, pero mucho más potente, pues podremos tener 5 (4 + 1) slots diferentes en la versión Standard y hasta 20 en la versión Premium. Además de esto, cada slot se puede asociar con una cuenta de repositorio de código, de forma que podamos hacer el despliegue continuo hacia el slot que nos interese en cada momento sin afectar al slot de producción.

Para demostrar su potencia, vamos a crear una aplicación Web con dos slots. Además del de producción, crearemos uno de  uno de test para poder ir cambiando de uno a otro y realizar el cambio de test a producción sin que nadie lo note.

Creación de una Web App

En el portal preview de Azure vamos a crear una Web App dentro del Standard Tier, que es el que permite tener slots de despliegue. Las versiones Free, Shared y Basic no tienen posibilidad de crear slots:

Nota: Es especialmente interesante crear un grupo de recursos (Resource Group) para nuestro sitio web, pues así podremos gestionar todos los recursos utilizados a la vez, ver qué coste tiene todo el conjunto y borrar todos los recursos de una sola vez.

Creación y trabajo sobre el entorno de Test

Mantendremos la Web app que acabamos de crear como la versión de producción. Antes de desplegar nuestro sitio web, debemos pensar que es el sitio de producción, así que no deberíamos hacerlo directamente sin probar la aplicación antes.  Para evitar desplegar aquí directamente, vamos a crear un slot de test donde probar la aplicación. Una vez hayamos probado que la web funciona bien ya haremos el intercambio entre Test y Producción.

En el “blade” de la Web App, vamos hasta la parte inferior donde se encuentra la zona de despliegue. Allí podremos abrir la sección de slots y crear uno nuevo:

Una vez creado, ya podremos configurar un sistema de control de código para el despliegue continuo sobre este nuevo slot que acabamos de crear. En este ejercicio, para hacerlo fácil, seleccionaremos un repositorio Git local:

A partir de este momento ya podemos utilizar Git desde nuestro equipo para hacer un “git clone” del mismo y empezar a trabajar. Editamos una página index.html con un body y un texto y la subimos a la Web app con el comando “git push”, fijaos cómo el comando push hace que la herramienta Kudu realice el despliegue automatizado de nuestros cambios hacia la carpeta wwwroot del sitio:

Ahora podemos comprobar que el contenido del sitio en producción (izquierda), que todavía no hemos tocado, y el de test son diferentes, en la web de producción todavía vemos la pantalla de bienvenida inicial que nos indica que hemos creado una Web app correctamente, mientras que en la web de test ya tenemos nuestro pequeño “hello world”:

Y ahora la magia: paso de test a producción en dos clicks

Desde el “blade” de cada slot tenemos un botón de “Swap” que nos permite intercambiar dos slots. Desde el slot de test haremos el cambio al de producción, será un cambio bastante rápido, pues se realiza con un simple cambio de DNS y nuestra Web app no dejará de funcionar en ningún momento:

Una vez el portal nos avisa de que ha acabado correctamente, podemos comprobar en el navegador cómo se ha realizado el intercambio, comprobaréis que en lugar de realizar una copia, ha intercambiado los dos sitios web. Esto se realiza mediante la redirección del tráfico de forma que no haya ningún espacio de tiempo donde nuestra web no esté proporcionando servicio:

Y ahora, ¿Qué pasará si realizamos una modificación y hacemos un push con Git? El sistema lo hará al nuevo slot de pruebas, se encargará de refrescar los cambios correctamente y el sitio de producción no se verá afectado. Por ejemplo, cambiamos nuestro Hello World! y le añadimos una etiqueta H1 para convertirlo en un título, ese cambio sólo aparecerá en el slot de test:

La página de producción (izquierda) no se ve afectada, seguimos trabajando con la de test de forma completamente transparente:

Variables de configuración por slot

Si habéis llegado hasta aquí, probablemente os estéis preguntando qué pasa con las variables de configuración. Por ahora no las hemos necesitado porque el ejemplo es muy sencillo, pero en una aplicación real tendremos conexiones a bases de datos, cuentas de almacenamiento y muchas otras variables que normalmente leemos de un web.config.

Para demostrar cómo lo podemos gestionar en el portal, creamos una página .cshtml con un código como el siguiente:

Y utilizamos alguna variable de configuración como la siguiente dentro del archivo web.config:

El objetivo es que la variable de configuración tenga un valor adecuado en la versión de producción. Si utilizamos la funcionalidad de intercambio (“switch”) sin más esto no será posible, pues, como hemos visto antes, el cambio se realiza haciendo una redirección interna y el web.config que tengamos definido en el slot de test es el que pasará a estar en producción. Esto significa que el encargado del despliegue tendría que volver a desplegar al entorno de test un nuevo web.config justo antes de hacer el intercambio.

Para evitar la gran cantidad de errores que esto podría producir, el portal de nos permite definir qué valores de la configuración de la aplicación queremos sobrescribir. Esta funcionalidad ya la teníamos antes, pero ahora podemos definir cuales de ellos deben mantenerse en el slot, para que al hacer el intercambio esos valores queden siempre en el slot de producción. En caso contrario, esos valores también migrarán con el despliegue al hacer el intercambio.

Definiendo de esta forma los valores de configuración y cadenas de conexión, nos aseguraremos que en el slot de producción tengamos siempre los valores correctos, sin importar qué valores haya puesto el desarrollador dentro del archivo de configuración.

Valores de configuración en otros lenguajes

Como esta técnica se utiliza en .Net con los valores del web.config ¿Qué pasa si lo queremos utilizar con otros lenguajes y frameworks como PHP, Python, Node o Java?

Para facilitarnos el uso de estas variables desde otros lenguajes fuera de .Net, el sistema nos coloca dentro de variables del entorno los valores que hemos definido en App settings. Así las podemos leer desde cualquier lenguaje que pueda leer variables del sistema operativo. Por ejemplo en PHP utilizaremos la función getenv:

<!DOCTYPE html>
<html xmlns="https://www.w3.org/1999/xhtml">
<head>
    <title></title>
</head>
<body>
El valor de testValue es:
<?php
echo getenv('testValue');
?>
</body>
</html>

En NodeJS tenemos el objeto process.env para leer los valores de la configuración:

Y en Java leeremos esos valores con System.getenv:

<%= System.getenv("testValue") %>

Nota: En ASP.Net nos bastaba definir las variables en el slot de producción, en el de test no nos hacía falta porque leíamos directamente el web.config. En los otros lenguajes será necesario crear las variables en cada slot porque si no, estas variables no existirán en ese contexto.

¿Y con 0 clicks y 0 downtime?

Cuando desplegamos una aplicación web podemos generar algo de retraso mientras se sube el nuevo contenido y pasa el tiempo de calentamiento de la aplicación. Para evitar eso, en los escenarios donde no tengamos que probar antes la aplicación que estamos desplegando, en Azure Web App podemos configurar la opción de “Auto Swap”. De esta forma, en el momento en que la aplicación ya esté completamente desplegada y preparada tras el push de Git, App Service intercambiará automáticamente con el slot de producción. Así los usuarios no experimentarán ningún retraso debido al tiempo de arranque de la aplicación, pues la aplicación ya estará en marchas.

Conclusiones

Azure Web Apps nos proporciona herramientas para el mantenimiento de múltiples slots de despliegue en aplicaciones web. Esta característica nos facilitará el ciclo de desarrollo, test, despliegue y mantenimiento de nuestra aplicación en el Cloud:

• Hasta 5 o 20 slots diferentes: podemos crear slots de desarrollo, de test, de precalentamiento además del de producción de forma muy sencilla
• Múltiples escenarios: testeo, precalentamiento, posibilitar el rollback sencillo
• Alta disponibilidad y 0 downtime: el intercambio entre slots no pierde peticiones durante el mismo, es una simple redirección de tráfico y además hace desaparecer el “downtime”, pues el intercambio se hace cuando la aplicación ya está funcionando
• Valores de configuración por slot: para evitar que los valores de depuración o testeo presentes en el web.config no lleguen a producción
• Múltiples lenguajes: tanto si usas .Net, PHP, Node, Python o Java, puedes utilizar esta característica sin problemas

Juan Manuel Servera (@jmservera)

Technical Evangelist