Otra de las grandes noticias de la plataforma es que tenemos la posibilidad de crear máquinas virtuales en la nube!

Resumiendo y simplificando un poco podemos decir que es una especide Hyper-V en la nube, dónde podemos desplegar cualquier tipo de sistema operativo, ya sea de plataforma Microsoft o de plataforma Linux, sí, Linux.

Utilizando este tipo de máquinas tendremos todo el control sobre la máquina, sobre lo que instala, se actualiza y demás…pero claro, a costa de tener que hacer más cosas, tener que gastar más tiempo y dinero en tares que no son propias de la aplicación. En un entorno PaaS como el que teníamos disponible hasta hace poco nos podemos centrar en el desarrollo de la aplicación y olvidarnos de muchos aspectos de la infraestructura.

Disponer en un entorno de máquinas virtuales con estado también nos va a permitir otros escenarios, como la instalación de un SQL Server, un SharePoint, un Active Directory o cualquier otro producto que consideremos.

En este post vamos a ir viendo cómo es posible crear una máquina virtual y poco a poco iré entrando en detalle en alguna cosa que hay que conocer si queremos trabajar con VM de Azure.

Desde el portal de Windows Azure podemos crear una VM,usando por ejemplo la galería:

En la galería podemos encontrar ya algunas plantillas que podemos usar para crear nuestra máquina virtual; Windows 2008. Windows 2012,CentOS, SUSE, OpenSUSE, Ubuntu etc…

Estas son simplemente algunas de las que a día de hoy existen, pero seguro que cada vez habrá más. Por ejemplo, existe ya una preview de una plantilla que instala SQL Server 2012.

A su vez también Microsoft dispone de diversos partners que ofrecen también distribuciones Linux certificadas que pueden desplegarse en Windows Azure.

Claro está, podríamos también subir nuestras imágenes (plantillas) o generarla a partir de una máquina ya desplegada.

El siguiente paso nos pide que le demos un nombre a la máquina y una contraseña para el usuario administrador.

Otro tema de los temas importantes es que debemos elegir el tipo de máquina que queremos usar, que marca los recursos asignados.

Como podéis ver se elige el tamaño de la máquina, como se hace cuando se despliega un Cloud Service (Web-Worker role). Eso realmente es así porque realmente, aunque aquí no lo veamos, cuando Windows Azure aprovisiona una nueva máquina virtual está creando un Cloud Services dónde despliega una máquina virtual con estado.

En el siguiente paso podemos elegir si queremos crear la máquina en un servicio independiente o si queremos conectarla a otra máquina.

Dos máquinas conectadas estarán en el mismo grupo de disponibilidad y lo que hace Windows Azure es desplegarla dentro del mismo servicio.

Windows Azure ofrece para una máquina un SLA del 99,9%, 99,95% si ponemos dos dentro del mismo grupo de disponibilidad, es decir, dentro del mismo servicio. Cuando le pedimos a la plataforma que las establezca en el mismo grupo ésta coloca cada máquina virtual en un fault domain diferente para asegurar que si una máquina cae la otra esté disponible.

Si la máquina la establecemos como standalone podemos crear un nuevo grupo de disponibilidad, para que cuando creemos la segunda máquina podemos asociarla.

Es importante comentar, que para escalar las máquinas virtuales no disponemos de las mismas capacidades que si usáramos Cloud Services.

Por ejemplo, si queremos tener dos máquinas en balanceo, somos nosotros los que tenemos que crear las dos máquinas conectadas, dentro del mismo grupo de disponibilidad.

Dos máquinas que están dentro del mismo grupo de disponibilidad están dentro del mismo servicio, se pueden comunicar entre ellas y se las puede configurar para que balanceador de Windows Azure haga balanceo sobre un determinado puerto.

Recordad también, que Windows Azure dispone de un API de administración REST que permite realizar todas las acciones que están disponibles en el portal, ya que éste hace uso del mismo API que cualquiera de nosotros podría utilizar.

Así mismo existen Sdks para trabajar desde plataforma Microsoft, Linux y MAC. https://www.windowsazure.com/en-us/develop/downloads/

Una vez terminados los pasos del Wizard Windows Azure se encargará de aprovisionar la máquina.

En la parte inferior podremos ver diversas acciones que podemos hacer; conectarnos a la máquina, reiniciarla, pararla, añadirle un disco, quitárselo, generar una imagen (plantilla) a partir de la máquina virtual o borrarla.

Si la máquina es Windows nos podremos conectar por RDP, si es Linux podremos usar otras herramientas como Putty o VNC si lo instalamos.

Un concepto que es importante tener claro es la diferencia entre discos e imágenes. Los dos son ficheros VHDs que se almacenan en Windows Azure Storage, pero sirven para cosas diferentes.

Cuando creamos una máquina virtual, ésta monta un disco que está en el storage.

Cuando creamos una máquina desde una imágen, se hace una copia del VHD y se monta el disco a partir de la copia.

Nosotros podemos crear imágenes con la acción “capture” (tras haber hecho un sysprep) o simplemente subir nuestros propios VHDs. Se pueden migrar máquinas que estén en un entorno local  Hyper-V a la nube simplemente  subiendo el VHD (o viceversa), sin ninguna acción adicional.

Una máquna virtual tiene que tener cómo mínimo un disco, el del sistema operativo, pero también se le pueden asociar (attach) discos adicionales de datos.

El disco del sistema operativo puede tener como máximo 127 Gb y puede tener discos adicionales hasta 1TB. El número de discos depende de cada versión.

Otro tema importante a conocer son los endpoints, que no son más que los puertos y protocolos a través de los cuáles se podrá acceder desde fuera de Windows Azure.

A nivel de comunicación, recordad que dos máquinas dentro del mismo grupo de disponibilidad se pueden comunicar sin problemas. Si queremos escenarios más complejos con conectividad entre diferentes máquinas virtuales, aplicaciones desplegadas en Cloud Services o incluso con entornos on-premise, tendremos que usar Virtual Network, otra de las novedades de la plataforma.

También, si queremos que las IPs de las máquinas se mantengan, tendremos que usar Virtual Network.

Por defecto, cuando se crea una máquina virtual, se crea un único endpoint para permitir la conexión remota, RDP en el caso de máquinas Windows.

Se pueden añadir los endpoints que se consideren, indicando el puerto y el protocolo.

Si dos máquinas están en el mismo grupo de disponibilidad podremos crear un endpoint simplemente asociándolo a otro que ya exista. De esta manera, Windows Azure sabrá que tiene que balancear la carga entre las N máquinas del grupo de disponibilidad para el puerto y protocolo indicado.

Como podéis ver, se puede elegir el protocolo UDP, otra de las novedades de la nueva versión!

También por último destacar que existe un campo que nos pide el puerto público y otro para el puerto privado.

De esta manera, una aplicación que haga uso de un puerto, podemos exponerla por otro puerto y será el balanceador el que se encargue de redirigir el tráfico del puerto público al privado.

Tanto el protocolo UDP como el “post forward” de puertos está también disponible para Cloud Services, lo que por ejemplo va a posibiltar escenarios dónde desde fuera de la nube podamos realizar conexiones contra instancias concretas de un servicio.

Unos días después de ver las nuevas funcionalidades, ya tenemos disponible también para descarga el Training Kit de la versión de Junio.

Podéis descargarlo desde aquí.

El training kit incluye más de 40 laboratorios y unas 20 presetaciones sobre todos los aspectos de la plataforma; máquinas virtual, Web Sites, PHP, Node.js, Linux etc

Como veíamos en post anteriores la nueva versión de Windows Azure ofrece la posibilidad de disponer de base de datos MySQL.

El portal permite crear una base de datos MySQL, pero comentar que este servicio no es ofrecido directamente por Microsoft, sino por cleardb, uno de los numerosos partners que están colaborando con Microsoft para ofrecer soluciones sobre Window Azure.

A través del portal no se puede realizar la administración. En este post veremos cómo poder conectarnos a las base de datos usando MySQL WorkBench.

Desde el portal de administración podemos ver los datos del servidor y de la base de datos y éstos son los que tendremos que usar.

En este caso estoy usando MySQL WorkBench, pero podría ser cualquier otro cliente de MySQL.

Podemos añadir una nueva conexión, indicando los valores que hemos obtenido desde el portal de administración de Windows Azure.

Una vez hecho, ya estaremos conectados y podremos hacer las labores que necesitemos sobre la base de datos.

Como hemos comentado en varias ocasiones, Windows Azure Web Sites permite integrarse con TFS y con Git. A continuación veremos cómo configurar esta integración y qué nos puede aportar.

Desde el portal de administración podremos acceder a ambas opciones, sólo puede configurarse una a la vez.

Si seleccionamos la opción de integración con TFS deremos indicar la URL de nuestro TFS Preview (TFS Preview es la versión en la nube de Team Foundation Server).

Si no disponemos de una cuenta podremos crearnos una directamente, el servicio en la nube a día de hoy es gratuito.

Si no conocéis la versión en la nube de TFS os recomiendo este video de mi compañero Jose Luis Soria.

Una vez tenemos nuestro servicio e indicamos la URL, nos autenticaremos con nuestro LiveID. Nos saldrá una ventana como la siguiente ya que ya estamos autenticados.

Seleccioamos el proyecto de TFS al cual queremos conectarnos:

Y ya está, el Web Site está “linkado” al proyecto de TFS Preview!

Una vez que lo tenemos unido, tenemos que ver cómo podemos trabajar y cómo podemos desplegar aplicaciones que está en el TFS a nuestro Web Site.

Desde Visual Studio 2010 (o 2012) podremos conectarnos a TFS Preview, empleando la URL del mismo, dónde una vez autenticados podremos ver los proyectos que existen.

Comentar que si usáis Visual Studio 2010 es necesario instalarse una actualización que permite conectarse a esta versión, versión que usa autenticación con LiveID.

Una vez nos conectamos al TFS, la manera de funcionar es cómo trabajar con un Team Foundation Server on-premise, no hay ninguna diferencia! Podemos subir nuestros fuentes,trabajar con workItems,tener informes etc…Casi toda la funcionalidad de la que dispone una versión on-premise.

La única peculiaridad que tenemos que conocer, es que cuando hemos unido el Web Site al proyecto de TFS se ha creado una build de integración continúa, que provoca que cada vez que se hace un checkin se compile la solución y se despliegue de forma automática en el Web Site.

Si creamos un nuevo proyecto, una aplicación ASP.NET MVC por ejemplo, y hacemos checkin, podremos ver cómo se lanza una nueva build.

Esta build no tiene nada especial, salvo que se le indica que debe desplegar el resultado de la compilación en un Web Site de Windows Azure.

Una vez que termine la ejecución de la build podremos acceder al site a través de la URL y ver el site desplegado!

y en la pestaña de despliegues podremos ver un histórico de los despliegues realizados y si quisiéramos, volver a una versión anterior.

Y finalmente mencionar, que si quisiéramos la integración con Git el sistema sería muy similar, pero usando Git con herramienta cliente. Desde el portal se ofrece la opción de descargarse un cliente Git y los comandos básicos que permiten desplegar la aplicación usando Git.

En los post anteriores veíamos como de fácil es posible crear un WordPress y cómo conectarnos por FTP.

En este post veremos cómo es posible usar WebMatrix y Visual Studio para desplegar Web Sites en Windows Azure. Con el primero usaremos el WordPress creado anteriormente y para ver el segundo caso crearemos un nuevo Web Site dónde desplegar una aplicación ASP.NET MVC.

Si partimos de WordPress creado anteriormente, veremos que en la parte inferior tenemos un botón “WebMatrix”.

Si seleccionamos esta opción podemos descargarnos el Web Site a nuestro equipo, usar WebMatrix para realizar modificaciones y desplegar los cambios de forma muy sencilla.

Si no lo tenemos instalado no es necesario hacer nada, el proceso de descarga se encarga de instalar WebMatrix si es necesario, descargarse los ficheros, instalar MySQL etc…todo para poder tener el entorno de desarrollo en nuestro equipo local.

Una vez tenemos descargado el portal, haremos las modificaciones que creamos convenientes, pudiendo publicar los cambios a través de la acción “Publicar”, la cuál nos mostrar un wizard de publicación similar a este que muestro a continuación, donde se indican los ficheros que han sido modificado y por tanto, lo que se desplegarán al Web Site de Windows Azure.

y desde la opciones de configuración podemos ver la configuración del servidor dónde se está realizando el Web Deploy, que no son más que los datos del servidor de Windows Azure.

Una vez que hemos visto como desplegar desde WebMatrix,veremos cómo hacer lo mismo con Visual Studio,en este caso, publicando una aplicación ASP.NET MVC 4.

Lo primero será crear un Web Site:

Una vez lo tenemos, crearemos desde Visual Studio una aplicación ASP.NET MVC 4. En este caso la aplicación es lo de menos, nos vale con lo que se genera por defecto. No hay que hacer ningún cambio especial para poder funcionar en Windows Azure.

Una vez que tenemos la aplicación, podremos usar la acción “Publicar” para hacer un Web Deploy directamente sobre el Web Site recién creado.

Desde el portal de Windows Azure podemos descargar los datos del servidor sobre el cuál hacer el despliegue, los cuáles importaremos en el wizard de publicación.

Como veis el proceso es prácticamente igual que el visto con WebMatrix, pero desde Visual Studio.

Una vez realizada la acción ya tendremos el portal disponible!