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.
No hay comentarios:
Publicar un comentario