Esquema de Staging para Web Sites en Windows Azure

Una de las principales características de las soluciones de Windows Azure desplegadas en Cloud Services es la posibilidad de realizar el despliegue en instancias de Stage previas a producción.

Cuando implementamos soluciones en Windows Azure utilizando Web Sites debemos realizar los despliegues directamente sobre el ambiente de producción. Esto puede obligarnos a estar fuera de línea (producción) en determinados periodos a raíz de realizar el cambio. Esta funcionalidad también es importante si queremos realizar pruebas sobre el ambiente productivo, antes de que nuestros usuarios puedan acceder debemos utilizar otro Web Site.

Una de las últimas actualizaciones realizadas sobre Windows Azure agrega la funcionalidad de Stage sobre Web Sites. Para poder utilizarla debemos ir al dashboard del Web Site que deseemos y encontraremos la opción para habilitarlo en la parte derecha debajo del gráfico de métricas.

Antes de habilitar el esquema de stage el web site debe estar en modo “Standard”.

image

Una vez que el Web Site se encuentre en modo “Standard” podemos habilitar el Stage para publicación.

image

Una vez que ya esté habilitado podemos visualizarlo en el panel donde se encuentran listados los web sites. El ambiente de stage se despliega con la misma solución que se encuentra en producción.

image

Si ingresamos al ambiente de stage veremos la siguiente información.

image

Cabe aclarar que este ambiente no puede ser escalado en forma independiente al ambiente de producción.

image

A diferencia del ambiente de stage en un cloud service la dirección del ambiente de stage de un web site tiene el mismo nombre pero se agrega la palabra “staging”. EJ: maxdebolimvp-staging.azurewebsites.net 

Para realizar el despliegue directamente desde el Visual Studio al ambiente de stage debemos seleccionar el nombre de nuestro web site que dice (Staging).

image

Una vez seleccionado el perfil verificamos la siguiente información y publicamos.

image

Una vez publicado podemos acceder al sitio en la dirección del staging.

image

Si ingresamos nuevamente al portal en el ambiente del stage podremos realizar el SWAP entre los dos ambientes.

image

Con este mecanismo podemos realizar publicaciones en el ambiente de stage para realizar pruebas y posteriormente hacer el SWAP sin generar la baja de nuestro sitio web debido a publicación de cambios.

Windows Azure WEBJOBS para Web Sites

Una de las nuevas funcionalidades que vamos a encontrar en los Web Sites es la posibilidad de agregar un job que ejecute alguna tarea necesaria. Muchas veces nos encontramos con que una solución puede ser soportada por un Web Site, pero a raíz de alguna tarea que debe ser realizada en segundo plano y sobre todo que no depende de un request, debemos implementar un Worker Role.

Los Web Jobs nos permiten ejecutar acciones que se encuentren en segundo plano como: procesar items de una cola, ejecutar algún stored procedure como podría ser requerido para eliminar sesiones caducas de SQL o cualquier otro tipo de tarea. Mediante esta funcionalidad podemos disponer de la ejecución en segundo plano que se encuentre en los siguientes formas: EXE, CMD, BAT, SH, PHP, PY, JS.

Para comenzar a utilizar esta funcionalidad debemos ir a la solapa WEBJOBS dentro de un Web Site y crear un nuevo job.

Para este ejemplo implementaremos un site muy simple que muestre información de una tabla de base de datos SQL Database.

Nuestro site tendrá una sola página que muestra directamente los datos:

image

Está página consulta una tabla en SQL que tiene el siguiente formato:

image 

Una vez que tengamos la base de datos creada y el sitio listo procedemos a publicarlo.

Por supuesto al principio la tabla no tendrá datos, con lo cual la página saldrá vacía. Para insertar datos en la tabla utilizaremos un Web Job, para lo cual crearemos una aplicación de consola que obtenga algunos datos de la instancia y los inserte en la tabla.

image

Como se puede observar no es necesario que la aplicación haga referencia a ninguna librería en particular.

Una vez creada la aplicación de consola debemos generar un archivo .ZIP con todo lo necesario para su ejecución.

Para crear el Web Job debemos acceder al portal de Windows Azure y acceder al Web Site. Dentro de la solapa WEBJOBS seleccionamos NEW.imageEn el formulario de creación del Web Job le asignaremos un nombre, subiremos el archivo .ZIP que creamos en el paso anterior y seleccionamos una de las tres modalidades de programación de ejecución para el Job:

  • Ejecución continua.
  • Ejecución programada.
  • Bajo demanda.

Para este ejemplo vamos a seleccionar Bajo Demanda. Una vez que ya hemos creado el Web Job, podemos acceder a la opción de WEBJOBS y ejecutarlo manualmente.

image

Una vez ejecutado podemos visualizar la información que registró el Job dentro de la base de datos ingresando a nuestro site.

image

Una de las pruebas interesantes para realizar es escalar el sitio web y ejecutar nuevamente el Job. El objetivo de realizar esta operación es comprobar el funcionamiento de los Jobs y poder identificar si mantendrá uno para todo el sitio web o bien utilizará uno por cada instancia.

image

Una vez aumentada la cantidad de instancias del web site a 2 ejecutamos nuevamente el Web Job. Cuando la ejecución del job finalice volvemos a ingresar a nuestro site de pruebas para verificar los datos.

Como se puede observar, aún teniendo dos instancias, el job solamente será ejecutado una vez.

image

En este ejemplo hemos utilizado la opción de ejecutar el job bajo demanda para poder realizar nuestra prueba con distintas instancias e identificar como era su comportamiento. Por supuesto, la gran mayoría de los casos de negocio requiere de ejecución continua o bien programada cada cierto tiempo.

En el siguiente link podrán encontrar información sobre como utilizar el SDK de Web Jobs

Como realizar un debug remoto de un Web Site en Windows Azure

Muchas veces nos encontramos con la necesidad de ejecutar el código de nuestra solución paso a paso para poder encontrar algún error. En términos generales, dicha ejecución, la realizamos en nuestro ambiente local por razones obvias; pero existen casos en donde el error solo se produce en el ambiente de producción y mucho más si tenemos en cuenta que para el caso de Windows Azure estamos emulando el ambiente localmente.

Con el SDK 2.2 de Windows Azure tenemos la posibilidad de insertar breakpoints en nuestro código y adjuntarnos al proceso que se ejecuta en el ambiente de Windows Azure.

Para realizar esto utilizando el Visual Studio 2013 debemos realizar los siguientes pasos:

  • En el explorador de servidores seleccionamos la opción “conectarse a Windows Azure”

Explorador de servidores

  • Abrimos la solución que queremos depurar en Visual Studio y realizamos un despliegue de la siguiente manera:

image

configuración

  • Posteriormente agregamos el breackpoint en el lugar del código que queramos

image

  • Por último debemos adjuntar el proceso. En el explorador de servidores expandamos los Web Sites que tenemos configurados y hacemos clic derecho sobre el Web Site a depurar. En el menú seleccionamos “Adjuntar Depurador”

image

Una vez seleccionado “Adjuntar depurador” se abrirá un explorador con la dirección del Web Site y el Visual Studio estará adjuntado al proceso de Windows Azure de la solución.

Todas las acciones que sean ejecutadas dentro del sitio y tengan un breackpoint podrán ser depuradas dentro del Visual Studio.

Nuevas caracteríticas de escalabilidad para Windows Azure Web Sites

Dentro de los anuncios realizados el día de hoy ponen a disposición la posibilidad de escalar web sites en forma independiente:

image

Una vez seleccionado el o los sitios que queremos escalar podemos especificar las condiciones de escalabilidad:

Aquí podremos configurar la cantidad de instancias mínimas y máximas que queremos para nuestro sitio, y el porcentaje de CPU que dispara el evento de escalar.

image

Niveles de servicios para Mobile Services y Web Sites en Windows Azure

 

A partir de hoy, Mobile Services ya se encuentra disponible en tres niveles: Gratuito, estándar y Premium.  Se miden por la cantidad de llamadas a la API y son respaldados por SLA estándar mensual de 99,9%. Puedes encontrar todos los detalles de los precios en el siguiente link. Todos los niveles de servicios móviles serán gratis hasta el 01 de agosto 2013 para dar a los clientes la oportunidad de seleccionar el método apropiado para su aplicación. Base de datos y almacenamiento de SQL seguirán siendo facturados por separado durante este período.

image

 

También anunciaron la disponibilidad Web Sites en las tres modalidades: Gratuito, Compartido y Estándar (Anteriormente Reservado). El nivel estándar está respaldado por SAL de 99,9% mensual. Hasta el 1 de Agosto hay un descuento del 33% para los web sites en uso compartido. Pueden revisar los precios en el siguiente link.

image

Características disponibles en cada nivel para Web Sites:

image

Adicionalmente anuncian las siguientes funcionalidades ya disponibles para web sites:

  • Soporte para SSL.
  • Escalabilidad independiente por sitio.
  • Memory dumps para debugging.
  • Soporte para procesos en 64 bits.

Para ver más detalle sobre los anuncios pueden ir a este link.