Subir una aplicación a Windows Azure

in .NET Microsoft Azure on by Gisela Torres

En el primer post sobre Windows Azure hablamos de la importancia de crear un servicio dentro de la plataforma, ya que será una forma de indicar qué tipo de servicio vamos a facilitar a nuestros usuarios. En este post voy a centrarme en la parte de Visual Studio a la hora de crear una aplicación adaptada a Windows Azure y cómo es posible publicar la misma.

Este artículo ha sido revisado durante la migración desde geeks.ms por lo que trabajaremos con Visual Studio 2010, aunque es posible instalar las herramientas en Visual Studio 2008. Es importante saber que para poder trabajar con este tipo de proyectos es necesario tener Windows Vista o superior.

Creación del proyecto

Una vez que tenemos instaladas las herramientas, abrimos Visual Studio e iniciamos la creación de un nuevo proyecto. Al abrirse el cuadro de diálogo para seleccionar el tipo de proyecto que queremos crear, veremos que tenemos un nuevo apartado llamado Cloud.

Elegimos el nombre de la solución y, al pulsar sobre el botón OK, vemos que aparece una nueva ventana. Esta vez se nos muestran una serie de proyectos que podemos agregar a nuestra solución cloud:

 

  • ASP.NET Web Role: Aplicación web de tipo Web Forms.
  • ASP.NET MVC 2 Web Role: Aplicación web siguiendo el patrón MVC.
  • WCF Service Web Role: Proyecto utilizado para la creación de servicios web con Windows Communication Foundation.
  • Worker Role: Se utiliza para crear aplicaciones que se ejecutarán en segundo plano de forma similar a un servicio Windows.
  • CGI Web Role: Esta solución nos da la posibilidad de poder subir a la nube aplicaciones FastCGI, como por ejemplo una aplicación en PHP.

Debemos saber que cada proyecto que incluyamos a nuestra solución es lo que se llama en Azure un rol y cada uno de ellos implica una máquina virtual diferente (y el coste que ello supone ;)).

Ahora que ya conocemos todas las posibilidades hasta el momento, vamos a hacer un pequeño ejemplo con una aplicación web normal y escribiremos un código de lo más simple. Para ello, solamente tenemos que seleccionar del lado izquierdo el tipo de proyecto (en este caso sería el primero de la lista), pulsamos la flecha que señala hacia la derecha y, antes de aceptar los cambios, nos posicionamos sobre el lápiz que aparece al seleccionar nuestro nuevo proyecto para cambiarle el nombre al mismo.

A partir de este momento, tendremos generados dos proyectos en nuestra solución (podemos agregar más proyectos en un futuro si fuera necesario):

El primero de los proyectos, ReturnGis, contiene todo lo necesario para que Windows Azure pueda interpretar correctamente los roles que tiene esa publicación, los parámetros que se han utilizado en cuanto a instancias, protocolos, diagnostico, etcétera. Dentro de la carpeta roles aparecerán tantos archivos de configuración como proyectos agreguemos a nuestra solución y, cada uno de ellos, con sus correspondientes preferencias. Para ver los parámetros de configuración basta con hacer doble click sobre el archivo para verlo en formato xml o bien con el botón derecho sobre él pulsamos sobre la opción Properties.

ServiceConfiguration.cscfg contiene una serie de ajustes relacionados con el servicio en conjunto, como por ejemplo: el número de instancias, un apartado para definir ajustes y poder utilizarlos dentro de nuestros roles, etcétera. Por otro lado, ServiceDefinition.csdef es el archivo que contiene la metadata necesaria para que la plataforma de Azure conozca cuales son los roles que queremos utilizar, los endpoints establecidos, etcétera.

El segundo proyecto es el que elegimos en un primer momento y con el que vamos a interactuar en este post. Por lo pronto, lo único que vamos a hacer es modificar el archivo Default.aspx y vamos a mostrar el nombre de la máquina donde se está ejecutando el sitio web.

<%@ Page Language="C#" AutoEventWireup="true" CodeBehind="Default.aspx.cs" Inherits="WebRole._Default" %>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "<a href="http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd</a>">
<html xmlns="<a href="http://www.w3.org/1999/xhtml">http://www.w3.org/1999/xhtml</a>">
<head runat="server">
    <title></title>
</head>
<body>
    <form id="form1" runat="server">
    <div>
        <p>
            Esta aplicaci&oacute;n se est&aacute; ejecutando en:
            <%=Server.MachineName %></p>
    </div>
    </form>
</body>
</html>

Si en este momento arrancamos la aplicación, nos daríamos cuenta de que no le es posible hacerlo:

El motivo es que, cuando trabajamos con proyectos de Windows Azure, Visual Studio necesita tener privilegios de administrador para poder arrancar un entorno simulado de desarrollo y obtener unas condiciones de ejecución lo más parecidas a un entorno en la nube. Por ello, si cerramos Visual Studio y volvemos a iniciarlo con privilegios elevados podríamos arrancar la aplicación ocurriendo lo siguiente:

Vemos que Visual Studio ha iniciado dos nuevas aplicaciones y en la barra de tareas tenemos un nuevo icono con el que podremos interactuar:

  • Development Fabric: Simula la parte de Hosted Services que vimos en el post anterior donde se hablaba de los tipos de servicios. Tenemos a nuestra disposición una interfaz donde podemos visualizar el número de instancias, la consola de cada rol, los mensajes de diagnósticos configurados, etcétera.
  • Development Storage: Se trata del entorno de desarrollo que llaman Storage Account en la nube, el cual todavía no hemos tratado y no tiene sentido hablar por el momento de él.

A la par, una nueva página de nuestro explorador se abrirá y mostrará el mensaje codificado anteriormente con el nombre del equipo local.

Publicación del proyecto en la nube

Ya que hemos podido comprobar que nuestra aplicación funciona correctamente, ha llegado la hora de subirla a la nube 🙂 Para ello el sistema es bien simple: Nos posicionamos en el proyecto Cloud (ReturnGis) y con el botón derecho pulsamos sobre la opción Publish …
Al hacer esto, ocurrirán dos cosas: Por un lado de forma automática se abrirá una nueva ventana del navegador, la cual se dirigirá al portal de Windows Azure, y por otro lado una ventana de Windows donde aparecen dos archivos necesarios en la subida:

  • ReturnGis.cspkg, el cual contiene los archivos de nuestra aplicación.
  • ServiceConfiguration.cscfg, que se ocupará de los ajustes del servicio (Aquellos que especificamos en el proyecto Cloud).

Seleccionamos el servicio que tengamos para este fin, y pulsamos sobre el botón Deploy del entorno de Staging. A partir de este momento se nos pedirán ambos archivos y una etiqueta explicativa para la subida. Además, debido a las continuas actualizaciones que están realizando en la plataforma para mejorar la misma, podemos seleccionar cualquiera de las versiones de los SO existentes hasta el momento por temas de compatibilidad con nuestros desarrollos.

Pulsamos en Deploy y vemos un progreso y un mensaje de aviso importante:

El mensaje que aparece justo encima del deploy nos está avisando que, aunque nuestra aplicación esté parada, si tenemos desplegado un paquete como estamos haciendo ahora, esto generará gastos económicos. Por lo tanto, si se trata de demostraciones, pruebas de concepto, etcétera es necesario eliminar las publicaciones realizadas para que no suponga ningún coste al cliente.

Una vez ha finalizado el proceso de subida de los archivos. Tendremos una nueva imagen con una serie de opciones:

  • Upgrade: Necesario para subir una nueva versión de nuestro desarrollo.
  • Run: Permite arrancar la máquina virtual que servirá nuestra aplicación.
  • Configure: Nos da acceso al archivo de configuración ServiceDefinition.csdef que subimos durante el despliegue. Podríamos decir que nos puede aportar una función similar a un archivo web.config aunque no en su totalidad.
  • OS Settings: Nos permite cambiar de versión del sistema operativo.
  • Delete: Borramos la publicación actual de la nube.
  • Web Site URL: Se trata de la URL de pre producción asignada a nuestro servicio en la nube. Es un enlace difícil de recordar a propósito para poder mostrar el resultado de nuestra subida en un entorno aparte del de producción. Esta URL está compuesta del Deployment ID + cloudapp.net y será invariable independientemente de las subidas que hagamos en nuestro servicio.

Por último, sólo falta pulsar sobre el botón Run… y esperar a que el deployment sea habilitado, pasando por los siguientes estados (Puede tardar varios minutos):

Si pulsamos sobre el link podremos ver que nuestra aplicación funciona perfectamente, dando como nombre el de la máquina la virtual en la nube :).

Cuando comprobemos que todo está OK, pulsaremos sobre el botón de sincronización y finalmente tendremos nuestra aplicación en producción con el enlace de acceso que elegimos cuando dimos de alta el servicio en la plataforma de Azure.

Espero que haya sido de utilidad 🙂

¡Saludos!