DNM+ Online
dotnetmania 2.0
Windows Azure Startups. Aplicaciones inteligentes
En este artículo describimos cómo configurar en nuestros proyectos el entorno de ejecución que necesitarán nuestras aplicaciones una vez desplegadas en la nube.

Una de las características más interesantes de las aplicaciones pensadas para Windows Azure es que son capaces de acondicionar su entorno para que todo funcione como esperamos. Para ello, el equipo de Windows Azure pone a nuestra disposición un apartado llamado Startup, donde podemos definir tantas tareas como creamos necesario antes de que nuestra aplicación comience a dar servicio a los usuarios finales: instalación de complementos, configuración del firewall, modificación del IIS, etcétera.

En este artículo vamos a ver cómo podemos definir estas tareas y las posibilidades que la plantilla de Windows Azure nos ofrece.

Antes de comenzar, debemos tener en cuenta que las tareas deben ser autónomas; es decir, deben ser capaces de poder ser ejecutadas sin intervención de un usuario o administrador. Cuando se trata de una instalación, tales tareas se conocen como desatendidas o silenciosas.

Configuración

El lugar de configuración de las tareas iniciales es una sección llamada Startup ubicada en el archivo de definición de la solución, ServiceDefinition.csdef (figura 1).

Figura 1.

Para definirlo, basta con abrir la sección a nivel de rol (figura 2).

Figura 2.

Cada una de las operaciones que se quiera realizar se definirá como Task (tarea) y tendrá los siguientes atributos:

  • commandLine: se trata del nombre del programa o script que queremos ejecutar, seguido de posibles argumentos de línea de comandos.
  • executionContext:

    • limited: el proceso debería poder ejecutarse sin privilegios de administrador.
    • elevated: la tarea se ejecutará en el contexto del usuario NT AUTHORITY\SYSTEM.
  • taskType:

    • Simple (por defecto): la ejecución del rol será bloqueada hasta que la tarea termine de ejecutarse.
    • Background: el rol continuará ejecutándose mientras tanto la tarea se lleva a cabo.
    • Foreground: el comportamiento es similar al modo background, pero el rol no podrá pararse hasta que la tarea finalice.

Para ver todo esto mediante un ejemplo, vamos a crear una nueva tarea que nos permita habilitar ASP Clásico en el servidor que va a alojar nuestra aplicación.

El primer paso antes de configurarla será crear un ejecutable que habilite esta característica de IIS. El contenido del mismo será el siguiente:

start /w pkgmgr /iu:IIS-ASP

Guardamos el archivo con el nombre enableASPClasic.cmd y lo incluimos en la solución, modificando su propiedad Copy to Output Directory a Copy Always (figura 3) para que el mismo sea incluido en el paquete final.

Figura 3.

Nota: Si creamos o modificamos el archivo desde Visual Studio, es posible que tengamos resultados inesperados. Uno de los motivos puede ser las opciones de salvado por defecto de Visual Studio, que introducen marcas adicionales a nuestros archivos. Para cerciorarnos de que el funcionamiento es el deseado, lo más adecuado es seleccionar "Advanced Save Options" dentro del menú "File" y modificar la codificación (encoding) a Unicode (UTF8 without signature) codepage 65001, como muestra la figura 4.

Figura 4.

Ya tenemos la tarea que queremos ejecutar dentro de nuestra aplicación. El siguiente paso es declararla dentro de la sección Startup en el archivo ServiceDefinition.csdef (listado 1).

<?xml version="1.0" encoding="utf-8"?>
<ServiceDefinition name="Startups"
 xmlns="http://schemas.microsoft.com/ServiceHosting/2008/10/ServiceDefinition">
  <WebRole name="WebRole" vmsize="Small">
    <Startup>
      <Task commandLine="enableASPClasic.cmd" 
            executionContext="elevated"></Task>
    </Startup>
    <Sites>
      <Site name="Web">
        <Bindings>
          <Binding name="Endpoint1" endpointName="Endpoint1" />
        </Bindings>
      </Site>
    </Sites>
    <Endpoints>
      <InputEndpoint name="Endpoint1" protocol="http" port="80" />
    </Endpoints>
    <Imports>
      <Import moduleName="Diagnostics" />
    </Imports>
  </WebRole>
</ServiceDefinition
Listado 1.

Si nos fijamos en el código anterior, commandLine tomará como valor el nombre del archivo, y executionContext será elevated para tener permisos de administrador. Al no especificar el tipo de tarea, se tomará por defecto el valor Simple, o lo que es lo mismo, la aplicación no comenzará a dar servicio hasta que la acción haya finalizado con éxito.

Para comprobar que la tarea ha funcionado de manera satisfactoria, añadiremos a la solución un nuevo archivo llamado test.asp con el contenido que se muestra en el listado 2.

<html>
<head>
    <title>Hello Windows Azure!</title>
</head>
<body>
  <%= Response.Write(
    "Hello from Classic ASP and Windows Azure!") %>
</body>
</html>
Listado 2.

Y ya tenemos lista nuestra aplicación :-). Si subimos la misma al entorno de Windows Azure y ejecutamos nuestra página, comprobaremos que la misma funciona sin problemas (figura 5).

Figura 5.

Happy clouding!

blog comments powered by Disqus
autor
referencias