DNM+ Online
dotnetmania 2.0
Windows Azure Compute
Este artículo hace una demostración práctica de cómo comenzar a desarrollar para Windows Azure, creando una aplicación básica para esta plataforma y desplegándola en la nube.

Uno de los servicios que ofrece la plataforma Windows Azure nos da la posibilidad de desplegar nuestros desarrollos en la nube, aportándoles la escalabilidad y flexibilidad que necesitan, así como la abstracción necesaria para que los desarrolladores puedan centrarse en sus aplicaciones y dejar que Microsoft se encargue de la infraestructura. En este artículo veremos cómo empezar a trabajar con este servicio.

¿Qué necesito para comenzar?

Como es natural, nuestras herramientas principales de trabajo serán Visual Studio 2010 (o Visual Web Developer 2010) y el SDK de Windows Azure. Podemos instalar todo lo necesario para comenzar a desarrollar utilizando VS 2010 (el SDK de Azure y las herramientas que se añaden al entorno de desarrollo) a través del siguiente enlace, seleccionando All-In-One-Installation – (Updated April 2011): http://www.microsoft.com/windowsazure/sdk. Una vez finalizada la instalación, tendremos a nuestra disposición una nueva plantilla de proyecto del tipo "Windows Azure Project" en la sección "Cloud" de VS 2010.

Mi primera aplicación

Utilizando el tipo de proyecto habilitado en el punto anterior, vamos a crear una aplicación de ejemplo para conocer el ciclo de vida de un proyecto cloud en Windows Azure. Para ello, abrimos Visual Studio 2010 con privilegios de administración, hacemos clic en "New Project" y nos ubicamos en la sección "Cloud" para poder seleccionar "Windows Azure Project". Llamamos al nuevo proyecto HelloCloud, y pulsamos "OK" para continuar.

En este momento, un nuevo cuadro de diálogo (figura 1) nos mostrará los posibles roles que podemos añadir a la solución.

Figura 1.

Podemos definir un rol como una aplicación totalmente funcional dentro de nuestro servicio para la nube. A día de hoy, existen 3 roles diferentes:

  • Web Role. Se trata de todas aquellas aplicaciones desarrolladas para un entorno web y que van a ser alojadas en un servidor IIS. Aceptan peticiones HTTP y HTTPS, y pueden ser tanto sitios web como servicios. Pueden haber sido desarrolladas utilizando tanto tecnologías .NET como cualquier otro lenguaje/librería existente en el mercado (PHP, Ruby, Java, etcétera).
  • Worker Role. Aplicaciones que van a ser ejecutadas en segundo plano y que inician sus tareas a través de esperas o colas de mensajes. Podríamos decir que son similares a los servicios Windows o bien procesos batch. No poseen interfaz de usuario.
  • VM Role. Si bien este tipo aún está en fase beta, Microsoft nos va a permitir subir nuestras propias máquinas virtuales a la nube para poder utilizarlas como base para desplegar nuestros desarrollos. Estas máquinas deberán ser provistas con Windows Server 2008 R2, además de la funcionalidad adicional que queramos instalar.

Como máximo, podemos tener hasta 5 roles por solución/servicio. En la actualidad, VS 2010 nos ofrece distintas plantillas orientadas a distintos lenguajes. Para C# y Visual Basic .NET tenemos las siguientes:

  • ASP.NET Web Role. Plantilla utilizada para las aplicaciones ASP.NET Web Forms.
  • ASP.NET MVC 2 Web Role. Mediante esta plantilla podremos utilizar ASP.NET MVC 2 para crear nuestras aplicaciones web para la nube. Si bien a día de hoy está disponible ASP.NET MVC 3, la creación de estas plantillas es anterior a la última versión del framework (lo cual no implica que la versión 3 no pueda ser desplegada en la nube :-).
  • WCF Service Web Role. A través de esta plantilla, podremos crear servicios web basados en Windows Communication Foundation y alojados en IIS.
  • Worker Role. Plantillas pensadas para la creación de procesos en segundo plano.
  • CGI Web Role. Para aquellas aplicaciones que necesiten Fast CGI para su funcionamiento (como por ejemplo, PHP).
  • Silverlight Business Application. Desde la última actualización de Windows Azure, podemos disfrutar de esta plantilla, que nos permitirá la creación de aplicaciones Silverlight de una manera más cómoda.

Para F#, de todas estas plantillas solamente está disponible la de Worker Role.

En nuestro ejemplo, vamos a utilizar ASP.NET Web Role y Worker Role. Para ello, seleccionamos las plantillas correspondientes del lado izquierdo y pulsamos sobre la flecha ">" para añadir las mismas al lado derecho de la ventana.

Al igual que en cualquier otro proyecto, podemos modificar el nombre de los roles que acabamos de agregar. Para ello bastará con posicionarnos en cada uno de ellos y pulsar sobre el lápiz que aparecerá en el lado derecho de los roles seleccionados. Para esta demo, llamaremos al primero myWebRole y al segundo myWorkerRole; utilizaremos C# como lenguaje de programación.

Pulsamos en el botón "OK" para aceptar los cambios, y de esta manera Visual Studio comenzará la creación de nuestra solución cloud con los proyectos seleccionados, obteniéndose un aspecto similar al que muestra la figura 2.

Figura 2.

Como puede verse en la figura 2, además de los proyectos que hemos seleccionado como roles de nuestro servicio tenemos un tercero, llamado HelloCloud. Este proyecto nos va a ayudar a definir todo aquello relacionado con la plataforma Windows Azure, y siempre contendrá los siguientes elementos:

  • Carpeta Roles. Agrupa la configuración de todos aquellos proyectos dentro de nuestra solución que sean considerados como roles del servicio. Estos proyectos serán añadidos en el paquete final que subiremos a la nube y supon­drán una máquina virtual por cada rol, como mínimo.
  • ServiceConfiguration.cscfg. En los proyectos cloud vamos a tener un archivo de configuración adicional (además del web.config y/o app.config), en el que podremos asignar valores a todas aquellas variables susceptibles de cambios, como pueden ser cadenas de conexión, certificados, usuarios y contraseñas, etc., sin tener que parar el servicio. Este archivo se puede modificar directamente a través de una sintaxis XML o bien a través de una interfaz visual.
  • ServiceDefinition.csdef. Este archivo tiene como objetivo definir al servicio. Podemos decir de él que es el contrato de nuestra aplicación, donde vamos a especificar qué es lo que va a contener, cómo se va a acceder a él y con qué valores va a trabajar. Al igual que en el caso anterior, podemos utilizar una interfaz visual para su edición.

En cuanto al proyecto myWebRole, vamos a encontrar una plantilla para aplicaciones ASP.NET Web Forms con algunas diferencias:

  1. En primer lugar, vamos a tener asociadas a nuestro proyecto un conjunto de librerías relacionadas con Windows Azure. Estas librerías nos van a aportar toda la funcionalidad necesaria para interactuar con la plataforma. Por ejemplo, las clases en el espacio de nombres Microsoft.WindowsAzure.Diagnostics nos facilitarán el trabajo con todas aquellas tareas de diagnóstico y trazas necesarias para poder auditar nuestras aplicaciones, Microsoft.WindowsAzure.ServiceRuntime contiene numerosas clases que nos facilitarán información sobre el entorno de ejecución, Microsoft.WindowsAzure.StorageClient será útil para trabajar con otro de los servicios de la plataforma llamado Windows Azure Storage, etc.

  2. Además, en el archivo de configuración se declara un listener para el sistema de traza de Windows Azure Diagnostics.

  3. Por último, en un archivo de código nombrado WebRole.cs se define una clase WebRole que hereda de RoleEntryPoint. En esta clase vamos a definir el punto de entrada de la aplicación, que es de gran utilidad para establecer y definir acciones necesarias antes de que el rol comience a dar servicio a nuestros usuarios.

Para añadir algo de código en la aplicación web, abrimos el archivo Default.aspx y modificamos el contenido como se muestra en el listado 1.

<%@ Page Title="Home Page" Language="C#" MasterPageFile="/Site.master"
    AutoEventWireup="true" CodeBehind="Default.aspx.cs" 
    Inherits="myWebRole._Default" %>

<asp:Content ID="HeaderContent" runat="server" ContentPlaceHolderID="HeadContent">
</asp:Content>
<asp:Content ID="BodyContent" runat="server" ContentPlaceHolderID="MainContent">
    <h2>
        Bienvenido a Windows Azure Platform!
    </h2>
    <p>
        Esta petición fue atendida por la instancia <%:Server.MachineName %>
    </p>
</asp:Content>
Listado 1.

En el caso del proyecto myWorker­Role, podemos encontrar las mismas diferencias comentadas anteriormente, pero en esta ocasión el propio archivo de entrada, WorkerRole.cs, va a ser utilizado para implementar la aplicación a través del método Run (listado 2). En el código contenido inicialmente en la plantilla, se sobrescribe el método Run para hacer que nuestro proceso se ejecute cada cierto tiempo.

Podemos decir que nuestro servicio está listo y con unas pocas líneas es totalmente funcional. Para comprobar que todo funciona correctamente, pulsamos "F5" para ejecutar nuestra solución y comprobar que estamos listos para pegar el salto a la nube :-).

La primera vez que arranquemos una aplicación cloud, aparecerá el cuadro de diálogo de la figura 3. En él se nos informa de que una serie de endpoints van a ser reservados, así como de la creación de una base de datos necesaria para la simulación de uno de los servicios de almacenamiento de Windows Azure. De ello se encarga Storage Emulator, servicio local que se lanza automáticamente y que nos ayudará a simular Windows Azure Storage. En este artículo no nos centraremos en este servicio. Pulsamos "OK" para aceptar los cambios y continuar con el inicio de la depuración.

Una vez que el entorno de simulación de almacenamiento esté inicializado, un nuevo icono con el logo de Windows Azure aparecerá en la barra de tareas.

Figura 3.

La necesidad de activar Storage Emulator es la primera de las razones por las que iniciamos VS 2010 como administrador. La segunda tiene que ver con otro emulador, Compute Emulator, a través del cual obtendremos la funcionalidad aportada en la nube por Fabric Controller, un software desplegado en los centros de datos de Microsoft encargado de la gestión de los mismos. Sus principales cometidos son desplegar las aplicaciones de sus clientes en el data center y comprobar el estado de salud de los servidores, así como de los servicios desplegados en ellos. Para acceder a este segundo emulador, pulsamos con el botón derecho sobre el nuevo icono de la barra de tareas y seleccionamos "Show Compute Emulator UI" (figura 4).

Figura 4.

En la parte izquierda de la ventana, se visualizan todos aquellos servicios simulados en local; en este caso, nuestra solución HelloCloud con los dos roles implementados. Si desplegamos cada uno de los nodos correspondientes, veremos que aparece un círculo de color verde con un cero a la derecha (figura 5), lo que significa que por cada rol tenemos una instancia desplegada, o lo que es lo mismo, una máquina virtual sirviendo nuestro rol.

Figura 5.

Por cada una de las instancias, tendremos una consola que nos informará de datos relativos a la misma como trazas, estado, etc. Para acceder a cada una de las consolas, basta con pulsar en cada uno de los círculos que representan las instancias.

Para el primero de los roles, myWebRole, se abre además una nueva página en el navegador mostrando el contenido del sitio web. En el caso de myWorkerRole, podremos visualizar las trazas a través de la consola por instancia de Compute Emulator.

Desplegando nuestra aplicaciónen la nube

Una vez que hemos superado las fases de desarrollo y testing en nuestro entorno de simulación en local, estamos preparados para desplegar nuestra solución en la plataforma Windows Azure.

Normalmente, cuando queremos publicar un proyecto del tipo ASP.NET Web Application en un servidor de aplicaciones no-cloud, lo que solemos hacer es posicionarnos sobre el mismo y seleccionar la opción "Publish…" del menú de contexto, que colectará los archivos necesarios para el despliegue. En las soluciones cloud, el proceso varía ligeramente. En este caso, el proceso de publicación será delegado en el proyecto de Windows Azure, y deberemos seleccionar "Publish…" a través del proyecto HelloCloud (figura 6).

Figura 6.

El resultado de esta acción será un cuadro de diálogo ofreciéndonos distintas formas de despliegue:

  1. Create Service Package Only. Generar los paquetes necesarios para subir nuestro servicio a la nube. Utilizando esta opción, tendremos que acceder al portal para seleccionar de forma manual dónde serán asignados los paquetes.

  2. Deploy your Windows Azure Project to Windows Azure. Desplegar los mismos paquetes a través de VS 2010, para lo cual necesitaremos el uso de certificados y el ID de suscripción de nuestra cuenta.

Si aún no dispone de una cuenta de Windows Azure, puede ver las opciones disponibles en http://www.microsoft.com/windowsazure.

Para no añadir más complejidad al artículo, seleccionaremos la primera opción y pulsaremos "OK" para continuar. A partir de este momento, el proceso será el siguiente: VS 2010 compilará nuestra solución, asegurándose de que la misma no contiene errores. Si este proceso finaliza de manera satisfactoria, VS 2010 procederá a la generación del paquete para el despliegue. Cuando esa generación finalice, se abrirá una nueva ventana del Explorador de Windows, donde se nos facilitarán los archivos necesarios para la publicación:

  • Service Package File. Se trata de un archivo comprimido y encriptado conteniendo todo el código necesario para el despliegue de nuestros roles en la plataforma.
  • ServiceConfiguration. Contendrá toda la configuración modificable en tiempo de ejecución de nuestro servicio, tal y como comentamos anteriormente con relación a ServiceConfiguration.cscfg.

¡Y ahora sí que estamos listos para el despliegue! Accedemos al portal de Windows Azure Platform a través de http://windows.azure.com y seleccionamos la sección "Hosted Services, Storage Accounts & CDN" y el apartado "Hosted Services", al que se debe recurrir siempre que queramos desplegar un servicio, y en donde encontraremos todas las suscripciones activadas y desactivadas asociadas a nuestro Windows Live ID. Lo primero que debemos hacer es crear un servicio alojado (Hosted Service) para nuestro nuevo servicio. Podemos tener un máximo de 6 hosted services por suscripción. Para reservar uno de ellos, hacemos clic en "New Hosted Service" en el menú superior (figura 7).

Figura 7.

Cada vez que reservemos un hosted service para un servicio, deberemos definir una serie de valores iniciales en la ventana de creación:

  • Choose a subscription. A través de este combo desplegable podremos elegir entre las distintas suscripciones asociadas a nuestro Windows Live ID.
  • Enter a name for your service. Se trata de un nombre descriptivo interno para nuestro servicio. Ningún usuario podrá conocer el mismo desde Internet.
  • Enter a URL prefix for your service. Prefijo único dentro de la plataforma Windows Azure que se utilizará en el entorno de producción (myprefix.cloudapp.net).
  • Choose a region or affinity group. Por temas de legalidad y latencia en los servicios, Microsoft proporciona a sus clientes la posibilidad de desplegar sus aplicaciones en distintas regiones alrededor del mundo, con el fin de que éstos puedan aproximar sus servicios a los usuarios y ajustarlos a las leyes de cada región. Tenemos dos opciones para definir la localización:
    • Eligiendo la región deseada a través del combo.
    • Creando un grupo de afinidad que determine la región. De este modo, todos aquellos servicios que estén dentro de un grupo serán desplegados en la región asociada al mismo.
  • Deployment options. Una de las características de Windows Azure es la disponibilidad de dos entornos: pruebas (Staging) y producción (Production). El primero de ellos difiere del entorno de producción en la URL de acceso al mismo. Por otro lado, se nos ofrece la posibilidad de no desplegar nada por el momento, reservando de esta manera el nombre DNS para el futuro servicio. Para este ejemplo utilizaremos el entorno de staging.
  • Deployment name. Se trata de un nombre aclarativo de la release que se va a ejecutar en pruebas o producción.
  • Package location. En este apartado debemos localizar en nuestro sistema de archivos local la ubicación del paquete que generó VS 2010 para la subida.
  • Configuration file. Ubicación del archivo de configuración en nuestro sistema de archivos local.
  • Add Certificate. Nos permite asociar un certificado x509 a nuestro servicio para diferentes cometidos (conexiones remotas, HTTPS, etcétera).

Una vez que la configuración haya sido completada, pulsaremos en el botón "OK" para confirmar la subida. En este caso, nos aparecerá el aviso que muestra la figura 8. En él se nos informa de que al menos uno de los roles que estamos intentando desplegar tiene solamente una sola instancia; es decir, que solo habrá una máquina virtual sirviendo nuestra aplicación. Por ello, la plataforma Windows Azure no podrá garantizarnos una alta disponibilidad de nuestro servicio, ya que si esa máquina virtual falla no tendremos otra atendiendo peticiones de los usuarios hasta que la fallida se recupere. Pulsaremos en "Yes" para asumir ese riesgo :-).

Figura 8.

A partir de este momento comenzará el proceso de despliegue, el cual puede tardar hasta 15 minutos aproximadamente. Una vez que el despliegue finalice, nuestros servicios cambiarán al estado "Ready" (figura 9) y estarán listos para recibir las peticiones de nuestros usuarios. Para acceder a nuestra página web, bastará con acceder a la URL mostrada en el apartado de propiedades.

Figura 9.

Conclusiones

A lo largo de este artículo, hemos hecho una demostración práctica de cómo crear una aplicación básica para Windows Azure y desplegarla en la nube. Espero que su lectura le haya convencido de lo fácil que es comenzar a desarrollar para esta plataforma. Happy clouding!

blog comments powered by Disqus
autor
referencias