Syntax Highlighter

viernes, 31 de diciembre de 2010

Adiós 2010. Bienvenido 2011

Me voy a unir a la idea de Yeray de escribir el último post del año. Así cuando se acerquen las mismas fechas dentro de doce meses, podré echar una mirada atrás y ver, cerveza en mano, qué ha cambiado y qué no :)

2010 ha sido un año...distinto

Posiblemente, 2010 sea para mí uno de esos años de los que cuando uno se hace mayor rememora contando batallitas después de alguna comida copiosa. Han ocurrido cosas buenas y otras no tanto. El que me conoce sabe que mi lado optimista me puede, y soy de los que piensa que tras la lluvia, tarde o temprano siempre vuelve a salir el sol.

Quizás para cerrar el año, me quedo con el mejor concepto que he aprendido en 2010, que no es otro que el que resume la palabra Acción. Puedes equivocarte en lo que hagas, puede salir bien o mal, pero haz algo. Cada acción tiene una repercusión. Si no haces nada, no pasará nada, no hay repercusión. Si te equivocas, aprenderás de los errores y podrás corregirlos. Si aciertas, tendrás base para seguir un camino. Tan simple, tan importante. 

Es por ello que mi objetivo en 2011 lo resumo en una frase: "pasar a la acción", y con ello, el retorno de la ilusión. 

Gracias a los amigos y amigas, por mostrarme su sonrisa cuando todo va bien y saber que están ahí cuando las cosas se complican. Gracias a los colegas de trabajo, con los que me he enriquecido tanto personal como profesionalmente. Gracias a los compañeros de viaje, ¡qué grandes! Gracias a la familia, que han demostrado ser eso, una gran familia. Gracias a todos y todas por estar siempre ahí, por ser parte en la travesía.

Y en especial a Carmen, mi esposa, mi amor y mi compañera, de la que tanto he aprendido y ha puesto la luz en el camino.

Sin más me despido por este año, o sea, hasta mañana. Os deseo un feliz y PRÓSPERO año 2011 a tod@s.

Un abrazo,

David Rodríguez

miércoles, 29 de diciembre de 2010

Nuevo grupo de usuarios .NET: @TenerifeDev

Buenas a todos. Después de unos días con la familia, turrones a cascoporrillo y acabar con un día lleno de inocentadas curiosas, llegó el momento de hacer una recopilación de las impresiones del evento de la semana pasada sobre Windows Azure y Windows Phone 7 en la ETSII.

Algo que quizás con las prisas no se publicitó en la agenda -yo mismo me uní a las sesiones a última hora- , era la intención de crear un grupo de usuarios .NET en la isla donde compartir experiencias de desarrollo y un punto de encuentro para estar al corriente de las últimas novedades en el sector. 

La creación de dicho grupo de usuarios está en marcha y queremos contar contigo. Hay un espacio para todos, ya quieras participar como oyente o colaborador, a través de los canales de comunicación del grupo. En breve montaremos un portal que sea el punto de encuentro inicial donde se centralice todas la información.

Por ahora, los canales de comunicación son los siguientes:
Como resumen del evento de la semana pasada, os dejo los enlaces a los materiales:
  • Descarga de las presentaciones desde SkyDrive
  • Vídeos resumen de las presentaciones: (parte 1 y parte 2)
  • Algunas fotos de las sesiones en SkyDrive


Finalmente, dar gracias a Alberto Díaz por cederme un hueco, ser benevolente con los comentarios y demostrar ser un excelente organizador además de un gran técnico; a Jose Fortes por su magnífica puesta en escena y acercar el concepto cloud de un modo directo y claro; y como no, a Yeray Julián por dedicar parte de su tiempo en estas fechas tan complicadas a traernos de primera mano las novedades de un nuevo mundo de oportunidades en el desarrollo móvil.

Anécdota: nunca había visto un despliegue tan rápido sobre Azure como el que hice durante la demo. Por lo rápido que iba pensé que algo malo estaba sucediendo, pero no fue así. La red de comunicaciones de la ETSII es formidable, lástima no seguir siendo universitario :) 


¡Anímate y participa!


martes, 21 de diciembre de 2010

Evento sobre Windows Azure y Windows Phone 7 en Tenerife

Como dice Alberto, no ha habido margen para avisar con más anterioridad. 

MAÑANA, 22 DE DICIEMBRE DE 2010 POR LA TARDE -si a alguien le cae el gordo por la mañana que no se lo pierda y que lleve cava para el final- tenemos unas sesiones sobre lo último de Windows Azure y Windows Phone 7.

Ven a conocer las últimas novedades en desarrollo sobre Windows Phone 7 y la plataforma Windows Azure, en el Salón de Grados de la Escuela de Informática de la Universidad de La Laguna.

El poco tiempo de antelación es debido a que podemos contar con la presencia de Josué Yeray Julían Ferreiro, antiguo compañero y que ahora ejerce en Plain Concepts para que nos cuente todo sobre Windows Phone 7 y las herramientas de desarrollo disponibles para la plataforma. 

También estarán Alberto Díaz para abrir las sesiones y hacer una retrospectiva inicial, y José Fortes que nos hablará de Cloud Computing y las capacidades de Windows Azure. Como incorporación de última hora, entre medio estaré yo contando un ejemplo de despliegue sobre Azure y la experiencia de subir el portal DotNetNuke Community a la plataforma.

Se pueden registrar -aunque no es obligatorio- siguiendo este enlace. Si se registran mejor para tener una previsión de aforo.

Dejo los datos y agenda:

Día: 22 de diciembre de 2010

Hora comienzo/fin: 17:30-20:15

Lugar: Salón de Grados, Escuela Técnica Superior de Ingeniería Informática

Universidad de La Laguna, Camino San Francisco de Paula s/n 
38271, La Laguna, Tenerife, SPAIN

La agenda es la siguiente:

17:30 Bienvenida y presentación de las sesiones (Alberto Díaz)
17:30 Cloud Computing con Windows Azure (José Fortes) 
18:15 Desarrolla con Windows Azure (David Rodríguez) 
19:00 Descanso 
19.15 Desarrolla con Windows Phone 7 (Josué Yeray)

No se lo pierdan. Es el primero de una serie de eventos que haremos en Tenerife.

¡Saludos a tod@s!


Windows Azure Connect: "¿Por qué? ¡Porque podemos!"

Hoy toca hablar de uno de las nuevas características que se ha puesto en marcha en la plataforma Azure y que, aún estando en CTP -todavía no es ni Beta, sino una preview abierta a comentarios-, me ha llamado mucho la atención la sencillez con la que se pueden crear redes virtuales en la nube.

Esta nueva característica se llama Windows Azure Connect y es la primera que se ha habilitado al público dentro del conjunto de herramientas de gestión de redes que se denominan Windows Azure Virtual Network.

¿Qué es lo que permite esta característica?

Resumiéndolo en una frase: "construir de manera sencilla y rápida redes virtuales seguras en la nube, para interconectar equipos y roles que estén tanto en la nube como en una red privada".


¿Por qué de manera sencilla y rápida?

Porque la configuración se realiza automáticamente instalando un software cliente que es el que se encarga de realizar y mantener las comunicaciones, o a través de configuración de los roles desplegados en Azure.


¿Por qué segura?

Porque todas las comunicaciones van cifradas a través de IPsec. IPsec protege las comunicaciones sobre redes IP a través del uso de servicios criptográficos. 



Los elementos de red

Para gestionar la red virtual contamos simplemente con dos tipos de elementos:

  • Endpoints: que son los extremos de las comunicaciones. Pueden ser locales (PCs, equipos virtualizados, etc. a través de la instalación del agente software de Connect) o Roles de Azure (WebRoles o WorkerRoles)
  • Grupos: un grupo es un conjunto de EndPoints más las reglas que indican con qué otros grupos se comunica.
Y ya está, no hay más. Más simple que el mecanismo de un chupete. 

Combinando estos dos elementos se puede configurar innumerables casos de uso que solucionan la mayoría de las situaciones: nubes híbridas en las que una parte está en la nube y otra en tu propio datacenter, comunicaciones entre distintos proveedores de cloud -por ejemplo conectando infraestructura existente de GoGrid con WebRoles en Azure-, etc. etc. etc.

El diagrama siguiente muestra un ejemplo de interconexiones posibles, aunque el esquema final depende de la solución a implementar:



Por ahora, durante este periodo de pruebas los Endpoints locales sólo pueden ser equipos ejecutando sistema operativo Windows (ya que el software de instalación sólo está disponible para esta plataforma), aunque ya se ha anunciado en los foros que en un futuro se añadirá la posibilidad de conectar Azure con dispositivos VPN, lo que permitirá comunicación a bajo nivel con recursos no-Windows que ahora mismo el agente de Connect no soporta.

NOTA IMPORTANTE: al estar esta característica en periodo de pruebas previas a su lanzamiento en BETA, aún no está alojado en los datacenters de Windows Azure sino en otros externos. Su uso durante este periodo de pruebas no tiene coste alguno, pero sí el uso de ancho de banda de salida de los elementos alojados en Windows Azure. 


HelloWorld, Azure Connect

Como ejemplo de prueba de conectividad, he realizado una simple conexión entre el PC de mi casa y el portátil sin llegar a conectar con un webrole -lo dejo para otro post-. Con ello, incluso teniendo IPs dinámicas en ambos extremos he conseguido establecer una comunicación segura entre ambos equipos con lo que puedo gestionar remotamente todos los recursos de la red de mi casa -imaginen las posibilidades de poder ampliar esta red con quien tú quieras, a través de comunicaciones seguras.

Los pasos que seguí fueron:
  1. Acceder al portal de Azure y pulsar en el menú "Virtual network". En la parte superior aparecen las suscripciones disponibles
  2. Al pulsar sobre una suscripción, nos sale un cuadro de diálogo indicando si queremos activar Microsoft Connect para esa suscripción. Aceptamos la condición y sis tenemos activada esta características sobre la suscripción -no olvidemos que ahora mismo está en CTP y hay que solicitarla- el proceso acaba por habilitar más opciones en el portal
  3. Una vez activado Connect en la suscripción, pulsamos el botón "Install Local EndPoint" para instalar el software cliente en el equipo local
  4. Pulsamos el botón "Copy Llink to Clipboard" para copiar la URL de descarga al portapapeles (si sale una advertencia de seguridad de Silverlight indicando que la aplicación va a interactuar con el portapapeles le damos a "Ok")
  5. Pegamos la dirección en el navegador -ojo, ahora mismo sólo se soporta Internet Explorer- con lo que aparece el cuadro de diálogo de descarga sobre el que pulsamos la opción "Ejecutar" directamente
  6. Seguimos los pasos del asistente de instalación hasta completar la misma

Una vez realizada esta instalación, al acceder de nuevo al portal y seleccionar el nodo "Activated Endpoints" veremos nuestro equipo en la lista de Endpoints, así como otras estadísticas de conexión.


Después de esta instalación, el equipo se considera un "local endpoint". Hay que tener en cuenta que sólo se puede instalar una instancia de este software por equipo, ya que utiliza el token de activación para la suscripción en cuestión. Si se desea que el equipo se conecte con otra suscripción, hay que desinstalar el software actual desde el panel de control y repetir el proceso para la nueva suscripción. Si se desea eliminar el local endpoint, se puede realizar o bien desinstalando el software del equipo o bien yendo al portal de Azure y eliminarlo de la lista usando la opción "Delete Endpoint".

Para instalarlo en otro equipo basta con seguir de nuevo los pasos descritos -ojo, no vale el mismo enlace de descarga, con lo que hay que repetir la operación desde el inicio-, con lo que repetí los pasos en el segundo equipo, para tener finalmente los dos EndPoints.

Con los EndPoints en marcha, ahora sólo faltaba comunicarlos entre sí. Para ello, creamos un grupo siguiendo estos tres pasos:

  1. Desde el portal de Azure, seleccionamos el nodo "Groups and Roles" que está justo debajo de la suscripción
  2. Pulsamos el botón "Create Group" para abrir el formulario de creación de grupo, introduciendo los datos solicitados -para que se puedan comunicar entre sí, marcad la opción "Interconnected".
  3. Pulsamos el botón "Create" para finalizar la operación



Ahora podemos ver el grupo recién creado, y que además cada elemento tiene una nueva propiedad "Addresses" en formato IPv6 en el panel lateral derecho.


Si abrimos una consola de comandos y hacemos un simple ping a la IPv6 podemos ver la respuesta de comunicación a través del tunel IPsec.


No os echéis las manos a la cabeza con los tiempos de respuesta. Hay que tener en cuenta muchos factores: el ping ha viajado encriptado a través de Internet desde Tenerife, ha pasado por varios satélites y cables de fibra óptica submarinos hasta llegar a un Datacenter en Estados Unidos que actualmente no es de Azure sino uno en pruebas, y ha vuelto realizando el mismo camino de vuelta -el vídeo final de las conclusiones explica mejor este apartado :). Teniendo en cuenta que en Tenerife tenemos un ping mínimo en las ADSLs de Telefónica de 120ms, más de la mitad del tiempo ha sido por la comunicación entre Canarias-Cádiz-Canarias. 

Veremos en cuánto se queda este tiempo cuando el futuro NAP que esté operativo en Tenerife a partir de Marzo y cuando Connect esté disponible en los datacenters europeos como Dublín.

Del mismo modo, podemos comprobar que podemos acceder por escritorio remoto al otro equipo sin ningún problema:



Conclusiones 

Cada vez queda más patente que el público objetivo de la plataforma Azure son los desarrolladores, ya que a golpe de dos clicks de ratón puedes crearte una red virtual sin tener pajorera idea de lo que es una máscara de red, un router, una VLAN o una VPN (no quiero decir que no sepamos algo de ello, pero seguro que bastante menos que los de IT). Para los desarrolladores, disponer de una herramienta integrada con Azure en la que crear una red virtual sea un proceso tan sencillo y seguro, es todo un lujo.

El otro día hablando con un amigo de IT que ha también ha estado evaluando distintos proveedores de cloud computing, una vez que había visto lo que ofrecía Azure se inclinaba más por soluciones tipo GoGrid o Amazon EC2, y es normal, ya que Azure -por lo menos lo que se ofrece ahora mismo- es más una plataforma sobre la que construir y desarrollar aplicaciones que sobre la que desplegar y configurar sistemas pre-existentes. Esto puede cambiar con la entrada de los VM Roles, veremos qué sucede.

Como siempre, os dejo un enlace para acabar el post, esta vez a una escena que viene al pelo de la serie Big Bang Theory, lástima que no se pueda incrustar. Todo queda dicho en el diálogo siguiente:

Penny: ¿Por qué lo hacéis?
Todos: ¡Porque podemos!

http://www.youtube.com/watch?v=94c03FArdnQ


martes, 30 de noviembre de 2010

Nuevo portal de Windows Azure y SDK 1.3

Por fin comienzan a llegar las novedades presentadas en el PDC10 sobre la plataforma Windows Azure. Ayer mismo se anunció la salida del SDK 1.3 de Windows Azure con importantísimas novedades (¡por fin el role de Virtual Machine!). 

Las principales novedades son:
  • Role VM Beta (Virtual Machine): permite crear una imagen VHD personalizada usando Windows Server 2008 R2 y alojarla en la nube -...olé, olé y olé!
  • Acceso a escritorio remoto: facilita la conexión a instancias de servicio individuales usando el cliente de Acceso a escritorio remoto (lo anterior sin esta característica, dejaría mucho que desear)
  • Soporte Full IIS en los web roles: habilita el alojamiento de web roles bajo IIS
  • Privilegios elevados: habilita la realización de tareas con privilegios elevados en una instancia de servicio
  • Virtual Network (CTP): habilita el soporte para Windows Azure Connect, que provee de conectividad a nivel IP entre alojamiento "on-premises" y los recursos de Windows Azure -...ole otra vez!
  • Diagnósticos: mejoras en Windows Azure Diagnosticos para habilitar la recolección datos de diagnóstico en más condiciones de error
  • Mejoras en conexiones de red: permite a los roles restringir tráfico inter-role y usar puertos fijos en InputEndpoints
  • Mejoras de rendimiento: mejora significativa  en el rendimiento al desplegar una máquina local (uf! a probarlo pero ya!).



Nuevo portal de Windows Azure
Otra de las novedades importantes -acaba de ponerse en producción hace menos de una hora- es la puesta en marcha del nuevo portal de gestión de la plataforma.

El nuevo portal, basado en Silverlight, por lo que he visto por encima facilita muchísimo la configuración y gestión, no teniendo que estar pasando entre distintos portales (Windows, SQL  Azure, App Fabric -bueno, a este último todavía sí, por ahora se limita a un enlace al portal-, etc.) como se hacía antes, sino teniendo todo en la misma herramienta centralizada.



Hay muchísimas novedades para las que hay muchos posts que escribir (Reporting, Azure Connect -redes virtuales con Azure-, aunque hay una muy sencilla que me ha llamado la atención sobre el resto y que llevaba esperando desde hace más de 2 años -parece una chorrada, pero en un entorno empresarial es muy importante. 

La característica a la que me refiero es la de poder añadir co-admnistradores para gestionar una suscripción de Windows Azure -sí, hasta ahora no se podía hacer, supongo que habría alguna cuestión técnica que ha hecho que esta característica se demorara en el tiempo.

Al acceder a la nueva sección de "User management", al pulsar sobre el botón "Add New Co-Admin" se nos presenta una ventana para indicar el Windows Live ID del usuario o usuarios que queremos que "co-administren" la suscripción. 




Otra de las novedades es la de poder unirse fácilmente a los programas Beta desde el mismo interfaz con sólo dos clicks. Ahora mismo aparecen las instancias Extra Smalls, Windows Azure Connect y el ya comentado VM Role, que es lo que voy a probar hoy mismo. En cuanto tenga novedades del funcionamiento del Virtual Machine Role comento algo.



Un saludo.

lunes, 22 de noviembre de 2010

Control de código fuente en la nube

Como algunos ya saben, desde el 17 de noviembre esta disponible la versión 5.06 del portal DotNetNuke Community, con algunos cambios y correcciones muy interesantes. Este momento lo tenía en el horizonte y llego el momento de fusionar los cambios que he realizado en el portal para que soporte la plataforma Azure con esta nueva versión, con el objetivo de comprobar la viabilidad de ir manteniendo una versión paralela con cada nueva versión oficial (por lo menos hasta que DNN soporte oficialmente la plataforma Azure).

Hace algunas semanas comenté en el grupo especializado en LinkedIn de DNN Community la estrategia que tenía en mente, que no es otra que la de utilizar una herramienta de control de código fuente como Team Foundation Server con ramificaciones -branching & merging-. Para mí lo ideal para ello es CodePlex, ya que mis conocimientos sobre TFS son totalmente extrapolables a este entorno -detrás de CodePlex hay un TFS, con muchas menos opciones que la versión completa, pero las suficientes para poder hacer lo que me propongo.

Ahora mismo estoy inmerso en la mezcla de las dos versiones y ya publicaré más adelante una entrada con mis impresiones finales al respecto.


Si bien CodePlex nos ofrece una integración perfecta con las herramientas de Visual Studio, tiene un pequeño problema, que no tiene repositorios privados -no se ofrece esta opción- y por lo tanto, si no se publica en menos de 30 días el proyecto, éste es eliminado del servidor. 


No es que para este proyecto en cuestión sea lo que busco, pero quizás sí para alguno más adelante con lo que la opción de tener algún repositorio privado es, cuando menos, necesario.

No quería dejar de comentar otra alternativa que me comentó Marco para poder almacenar y compartir código fuente en la red: GitHub, una herramientra de control de código fuente construida en la nube, tal y como reza a su pie de página (Powered by the Dedicated Servers and Cloud Computing of Rackspace Hosting).

Lo primero que me ha llamado la atención, es la política de precios. En una frase: "para todos los bolsillos", ya que es gratuita para repositorios públicos y para los privados comienza desde 7$ al mes. Me ha parecido un buen ejemplo de SaaS en la nube por sus planes de ampliación y el gran abanico de posibilidades.



Si bien la integración con Visual Studio se ciñe a una extensión que pone una barra de herramientas dentro del entorno y que abren diferentes ventanas el interfaz de Git, soporta protección bajo SSL, envío de notificaciones por email, Wikis, workitems, descargas y lo que está muy conseguido, el branching y merging, ya que se soportan diversos métodos para estas tareas. ¿Dije que es multiplataforma? (Windows, LinuxMac).

Después de un rato tecleando comandos en la consola de Git hice una prueba de publicación. Lo que no creo que con DNN Azure realice los branchs y merges con él, ya que con CodePlex me manejo mejor, pero por 5€ al mes, tener un backup privado en la nube con control de código fuente vale la pena. Para todo lo demás, Mastercard.



Pregunta para la bruja Lola

¿Cuáles serán las políticas de precios del Team Foundation Server que se ejecutará sobre plataforma Azure, que fue anunciado en el PDC10 y que estará disponible para el año que viene?

Os dejo un enlace al blog de Ibon Landa donde resume muy bien lo que fue anunciado en el PDC sobre este tema.

¡Happy coding!

lunes, 15 de noviembre de 2010

DotNetNuke en Azure: desplegando en la nube

Este fin de semana he estado haciendo algunos avances en el siguiente objetivo de la lista -adaptar la configuración de DNN a Azure-  y me he dado cuenta que aún no había publicado cómo desplegar el paquete de instalación en Azure ni traducido los posts a inglés, así que hoy toca trabajo documentar el trabajo de hace dos semanas. El hábito de ir haciendo capturas de pantalla y pegándolas en word a medida que avanzas facilita mucho la tarea.

El último capítulo del diario de bitácora finalizó con la creación y despliegue en Development Fabric, el entorno de desarrollo que viene con el SDK de Azure y que emula el entorno de producción. Llegaba la hora de publicar en real el webrole y ver con qué problemas nos podíamos encontrar. 

Desplegando en Azure

Desplegar el paquete que ya funcionaba en Development Fabric no tenía porqué ser diferente de desplegar cualquier otra aplicación adaptada a la plataforma. De hecho no lo fue, aunque cuando finalicé el trabajo me di cuenta de lo que quedaba aún por hacer -ver conclusiones finales.

Paso 1. Crear el servicio de almacenamiento 

El primer paso fue dirigirme al portal de Windows Azure para crear el servicio de almacenamiento, que es un servicio para almacenar de forma persistente la información. Hay que tener en cuenta que la información almacenada localmente en una instancia de un webrole es totalmente volátil, por lo que hace falta un espacio de almacenamiento persistente. 

Un ejemplo de este tipo de almacenamiento que utiliza DNN son los contenidos que se van agregando dinámicamente desde el módulo File Manager o desde el mismo editor HTML, y si bien en esta fase aún no había tocado código para que soportara esta característica de Azure, sí que lo iba a usar para almacenar la información de diagnóstico de Windows Azure. En cualquier caso, es obligatoria la creación de al menos un servicio de almacenamiento para poder desplegar más tarde un servicio de hosting.

Desde la pantalla inicial seleccionamos "Storage Account" para dar soporte de almacenamiento a nuestro portal en Azure:


En el siguiente paso, simplemente le ponemos un nombre y descripción al servicio de almacenamiento:


Al pulsar el botón "Next", tendremos que introducir el nombre público del servicio de almacenamiento que debe ser único a nivel global. Por otra parte, al seleccionar el grupo de afinidad, es importante seleccionar el mismo que utilizamos cuando creamos el servidor de SQL Azure (ojo, el servidor es al que se le da el grupo de afinidad, no a las bases de datos), tanto para evitar problemas de latencia como para evitar costes de tráfico de entrada/salida del datacenter. 


Transcurridos unos segundos se nos presenta la página de resumen del servicio que acabamos de crear -no perdáis el tiempo usando los datos de la imagen, es un servicio de prueba que ya eliminé sólo para escribir el artículo. De los datos presentados, hay dos muy importantes con los que tenemos que quedarnos para modificar el paquete que vamos a desplegar:
  • Account Name: es el nombre público "corto" que le pusimos antes. Siempre se puede ver, por ejemplo, en las URLs de los EndPoints (la parte http://<PublicStorageAccountName>.blob.core.windows.net, por ejemplo)
  • Primary Access Key: es el "churro" de caracteres que aparece en esa misma pantalla. Se puede utilizar tanto la primaria como la secundaria. 

Ahora volvemos al Visual Studio para modificar el paquete de instalación para que use este servicio en vez de Development Storage. En vez de explicar cómo se puede hacer a través de transformaciones de configuración -pendiente escribir un artículo sobre este tema, ya que difiere de las transformaciones a los .config- lo hago de manera sencilla:

1) Accedemos a la configuración del WebRole en nuestro DotNetNukeCloudService, en la pestaña "Settings"


2) Pulsamos sobre el botón para modificar el valor y utilizamos los dos datos anteriormente indicados y pulsamos aceptar:

NOTA IMPORTANTE: cuando estamos en producción, es obligatorio usar protocolo HTTPS con los EndPoints. En caso contrario, tendremos un problema de ciclado al iniciar el WebRole como se comenta en el Paso 5.


Paso 2. Crear el servicio de hosting

Para poder desplegar a continuación el WebRole, el primer paso es crear un servicio de hosting. Para ello, volvemos a la página de creación de servicios y esta vez selecionamos un Hosted Service:



Del mismo modo que hicimos con el servicio de almacenamiento, le ponemos una etiqueta y una descripción:


A continuación le damos el nombre público donde va a estar alojado el servicio comprobando que está disponible globalmente. También seleccionamos el mismo grupo de afinidad que el servicio de almacenamiento y el servidor de SQL Azure para evitar los costes y latencias comentados previamente.


Una vez que pulsamos el botón "Create", ya tenemos listo el servicio para poder desplegar el WebRole.




Paso 3. Desplegar en Azure

Pulsando el botón "Deploy" de la pantalla anterior nos sale un interfaz para subir el paquete de instalación. Se pueden seguir los pasos hasta finalizar el asistente. Sin embargo voy a explicar la forma "integrada" con Visual Studio que viene desde la versión 1.1 del SDK:

1) Agregamos un certificado X.509 al servicio que acabamos de crear. Este paso lo describí hace algunas semanas por lo que me lo salto;
2) Pulsamos con el botón derecho sobre el servicio y pulsamos sobre "Publicar" para iniciar el asistente 
3) Seleccionamos la opción "Deploy your Cloud Service to Windows Azure"
4) Configuramos las credenciales con las que vamos a publicar desplegando el cuadro combinado y seleccionando "Add...": indicamos el certificado X.509 que configuramos en el paso 1; introducimos el ID de suscripción del portal de Azure y finalmente indicamos un nombre para los credenciales con el fin de volver a usarlos más adelante. Pulsamos el botón OK para comprobar que todo está correcto;


5) Al volver de la pantalla de credenciales, nos aparecen los servicios que acabamos de configurar: el servicio de hosting -que podemos utilizar el de producción o preproducción- y la cuenta de servicio de almacenamiento a través de la que se va a realizar el despliegue. También se pueden activar en este momento las opciones para habilitar IntelliTrace en el despliegue -por favor, un gran "clap!" por el que tuvo la idea de incluir esta funcionalidad.



6) Pulsamos el botón "OK" y...¡comienza la fiesta! 

Paso 4. Ir a hacerse un café...un sandwich...subir un personaje en el WoW a nivel 80...conseguir el título de Matarreyes

Comienza la publicación automática. Quiero dejar claro desde el principio, que por lo que he podido comprobar habilitar IntelliTrace tiene sus inconvenientes, y es que el despliegue viene tardando más del doble que sin él. ¿Y cuánto es el doble? Depende del servicio y número de instancias a desplegar. Lo mínimo que he tardado en un despliegue con un HelloWorld sin IntelliTrace es alrededor de 8 minutos. El de DNN con IntelliTrace activado, me ha llegado a tardar casi 1 hora en finalizar. En el PDC10 anunciaron que en breve el despliegue iba a tardar muchísimo menos...a ver si llega esto.

Resumiendo: 
1) primero la subida del paquete a la nube, que tardará más o menos dependiendo de la línea de comunicaciones que tengamos (tengo que hacerme con una línea de esas de 50Mb...es un buen momento para mirar en los distintos proveedores a ver si alguno te da cobertura...).
2) inicialización de las instancias a desplegar
3) entrando en estado ocupado "Busy"...
4) Stopping... ¡me voy a <censored> en todo lo que se menea!



Paso 5. Tómatelo con calma, todo es cuestión de perseverancia

El error de ciclado en la inicialización es muy común en los primeros despliegues. Para ello, recomiendo este artículo en el foro de MSDN en el que puedes repasar cada una de las causas comunes de este problema.

Después de una detenida lectura -el tiempo desperdiciado con un despliegue fallido hace que te lo tomes bastante en serio- realicé los siguientes cambios:
  • Configuré los EndPoints del servicio de almacenamiento para que usaran protocolo HTTPS ya que es obligatorio en Azure -una prueba sobre desarrollo me hizo dejarlo sobre HTTP 
  • Reconfiguré la compilación de los proyectos para que utilizaran .NET Framework 4.0 y 64bits. Si bien lo de Framework 4.0 no es obligatorio, según el artículo no se deben referenciar ensamblados de 32bits -por lo que he probado, esto es obligatorio para los WorkerRoles pero no así para los WebRoles, con lo que creo que no fue determinante
  • Agregué referencias que estaban en el web.config y que no estaban en el proyecto. Esto se había quedado al migrar del WebSite al WebApplication
  • Me aseguré de que todas las referencias estaban como "Copy Local"
Tras estos cambios el WebRole se desplegó correctamente. Pulsé rápidamente sobre el enlace y el resultado es lo que veis hoy en http://dotnetnukecommunitytest.cloudapp.net 




Conclusión

Con este trabajo conseguía lo que, por lo que he podido comprobar, es la primera publicación de DNN sobre Azure. Sabía que faltaban muchas cosas por delante, como separar la configuración, utilizar el servicio de almacenamiento para contenidos, migrar más módulos, etc. pero era un gran paso...no como caminar por la luna, pero emocionaba.

El mejor consejo que puedo dar para este paso en las migraciones es "empaparse" del foro de MSDN de Windows Azure Platform Troubleshooting, Diagnostics & Logging. No usarlo sólo cuando tengamos un problema, sino leerlo frecuentemente, ya que nos ahorrará mucho tiempo y despliegues intermedios. Estáis tardando en ponerlo como fuente RSS.

El siguiente objetivo: cambiar el sistema de configuración para usar Service Configuration.


Off-Topic: lo de matar a Arthas en el WoW no era coña. Conseguimos el logro de "Matarreyes" en una raid entre despliegue y despliegue del DNN sobre Azure -un saludo para la gente de la guild. No veas lo contento que acabamos ese día, sobre todo yo :) Podéis comparar la fecha del logro con la de la captura del primer deploy con éxito que está unas líneas más arriba.








Related Posts Plugin for WordPress, Blogger...