La intención final no es que realicen paso a paso de nuevo todo lo que yo he tenido que hacer, sino que de algún modo dispongáis de un distribuible con todos los cambios. Según he leído en los términos y condiciones de la edición Community no hay ningún problema en ello, así que en cuanto esté más avanzado -sobre el hito 2- lo subo a algún sitio ¿Codeplex?
A continuación pongo el índice que espero ir completando y actualizando. El contenido de los mismos será como un diario de bitácora en el que comentaré los detalles y problemas solucionados. Muchos de ellos servirán incluso para otros proyectos que no sean sobre DNN, ya que son comunes a cualquier despliegue en Azure.
El índice es el siguiente:
- DotNetNuke en Azure: publicando en la plataforma Azure
- DotNetNuke en Azure: convirtiendo los archivos de configuración
- DotNetNuke en Azure: utilizando Azure Storage para contenidos
- DotNetNuke en Azure: adaptando módulos a Azure
- DotNetNuke en Azure: añadiendo autenticación AppFabric basada en claims
- DotNetNuke en Azure: añadiendo soporte AppFabric Caching
Creando la base de datos
Tal y como comenté en la introducción, partí de la descarga Community del paquete de instalación del portal en su versión 5.5.1, que hasta la fecha es la última versión -veo que ahora mismo está también disponible la 5.6.0 en beta. Como me imaginaba que iba a tener que tocar código, me bajé la versión con los fuentes.
Quise afrontar la prueba de migración por partes, así que lo primero era comprobar qué problemas de compatibilidad me iba a encontrar con SQL Azure, no fuera que me encontrara con algún detalle escabroso e insalvable. De este modo, descomprimí el paquete y lo publiqué en mi IIS7 local para iniciar el asistente de instalación que trae el propio DNN que se encarga de configurar la base de datos entre otras cosas. Si alguien tiene dudas de cómo se hace, puede seguir las instrucciones de este post de Mitchel Sellers, saltándose obviamente la parte de configuración de bases de datos.
Al abrir el sitio web por primera vez apareció la siguiente pantalla del asistente para comenzar a instalar:
Seleccioné personalizado y pulsé siguiente. En el siguiente paso se hace una comprobación de permisos de escritura sobre las carpetas. Pulsamos otra vez siguiente para continuar con la instalación de la base de datos...por fin!
Aparece la siguiente pantalla (con los datos en blanco):
Llegado este momento, tenía 3 posibles estrategias a seguir, con sus pros y contras:
- Instalar en una base de datos local y utilizar el exportador de Management Studio de SQL Server 2008 R2 para generar el script de instanación. Esta opción, que en un principio es sencilla porque hace el trabajo por nosotros, tiene el inconveniente de que siempre tienes que instalar en un servidor local o en la red para luego subirlo a la nube. Si quería preparar un paquete que lo hiciera el solito en la nube no era una opción viable;
- Instalar una base de datos local y utilizar el utilizar el SQL Azure Migration Wizard, una herramienta gratuita en Codeplex que sinceramente está muy bien -la utilizo desde hace más de 1 año, muy aconsejable. Sin embargo, también chocaba con la idea de hacer que fuera autoinstalable;
- Modificar los propios scripts de creación y actualización que trae el DNN para que fueran compatibles tanto con SQL Server como con SQL Azure. Esta tercera opción, que tenía como contra que iba a tener que revisar muchos scripts, iba a ser la única que permitiría la autoinstalación futura del portal.
Para que el asistente de instalación pueda continuar este paso, es necesario previamente crear la base de datos en SQL Azure. Para ello nos dirigimos al portal de SQL Azure y creamos, por ejemplo, una nueva base de datos edición web de 1Gb. También permití en las reglas del firewall de SQL Azure acceso remoto a la IP desde la que accedo a Internet y las de la red de la plataforma Azure para que más tarde el portal publicado pudiera acceder:
Una vez creada, accedí desde el Management Studio de SQL Server ya que también iba a crear un login personalizado con acceso restringido sólo a esta base de datos.
Ejecuté primero el comando de creación del login a través conectándome a la master. Luego creé un usuario en la base de datos recién creada para dicho inicio de sesión:
-- first, connect to the master database
CREATE LOGIN DNNLogin WITH password='<put your password here>';
GO
-- Establish a new connection to the DotNetNuke database
CREATE USER DNNUser FROM LOGIN DNNLogin
GO
EXEC sp_addrolemember 'db_owner', 'DNNUser';
GO
Una vez creada la base de datos en blanco en SQL Azure, le di la oportunidad al asistente de instalación de DNN de proseguir con la instalación. Consiguió conectar sin problemas, pero al cabo de unos instantes se detuvo por fallo instalando los scripts de la base de datos, cosa que me esperaba.
Viendo el archivo de log que deja la instalación veo el error que dio y efectivamente era debido a un problema de compatibilidad con SQL Azure. Viendo el código fuente del proceso de instalación, también observé el orden de los scripts que se iban a ir ejecutando en orden y verifiqué que el resto de scripts también iban a tener problemas. Como resumen de dos días de trabajo adaptando y compatibilizando estos scripts para que soportaran SQL Azure dejo la tabla siguiente -si por algún motivo alguien quiere el detalle que me lo pida:
Resumen de errores detectados en los scripts
Error | Solución adoptada |
Deprecated feature 'String literals as column aliases' is not supported in this version of SQL Server. | Sustituimos las comillas simples (‘) por corchetes “[“ “]” |
Reference to database and/or server name in 'msdb..backupset' is not supported in this version of SQL Server. | En el SP Dashboard_GetDbBackups se ha comentado el código y se ha añadido la excepción RAISERROR (N'Backups on SQL Azure are not yet implemented', 10, 1). Pendiente hasta que salga esta funcionalidad en Azure o cambiar por un COPY DATABASE. Tarea pendiente. |
Deprecated feature 'Table hint without WITH' is not supported in this version of SQL Server. | Añadido el WTIH en el SP UpdateListSortOrder |
Tables without a clustered index are not supported in this version of SQL Server. Please create a clustered index and try again. | Añadidos índices clustered a las tablas que le faltaban los mismos. Recuerden post al respecto en este enlace. |
Deprecated feature 'Multiple table hints without comma' is not supported in this version of SQL Server. | Añadida una coma “,” para evitar el error de multiple table hints WITH (HOLDLOCK, TABLOCKX) |
Problemas de instalación del soporte ASPNET: membership, profiles, roles, etc. | Los scripts de ASPNET han sido sustituidos por los compatibles con Azure. Ver http://support.microsoft.com/kb/2006191 para más información |
Finalmente, la lista completa de scripts modificados para este paso del asistente es la siguiente (el resto de scripts intermedios no tenían problemas de compatibilidad):
- Providers\DataProviders\SqlDataProvider\DotNetNuke.Schema.SqlDataProvider
- Providers\DataProviders\SqlDataProvider\DotNetNuke.Data.SqlDataProvider
- Providers\DataProviders\SqlDataProvider\InstallCommon.sql
- Providers\DataProviders\SqlDataProvider\InstallMembership.sql
- Providers\DataProviders\SqlDataProvider\InstallProfile.sql
- Providers\DataProviders\SqlDataProvider\InstallRoles.sql
- Providers\DataProviders\SqlDataProvider\05.01.01.SqlDataProvider
- Providers\DataProviders\SqlDataProvider\05.02.03.SqlDataProvider
- Providers\DataProviders\SqlDataProvider\05.04.00.SqlDataProvider
- Providers\DataProviders\SqlDataProvider\05.05.00.SqlDataProvider
- Providers\DataProviders\SqlDataProvider\05.05.01.SqlDataProvider
Pero como decía Super Ratón,
"¡No se vayan todavía, aún hay más!"
Si bien la cosa iba marchando, el asistente de instalación no había finalizado. Aún quedaban varios pasos críticos en los que quedaba trabajo por hacer. Fui completando los pasos intermedios del asistente sin problemas, hasta llegar al paso de instalación de módulos. Al ver todos los que podía instalar y desesperado por ver en funcionamiento el portal usando SQL Azure, dejé sólo los predeterminados: HTML, Telerik, Messaging y Taxonomy, el resto ya los migraría más adelante.
Al pulsar el botón siguiente me encontré con problemas de instalación del módulo HTML:
Del mismo modo que con la instalación de la base de datos, revisando el log de instalación del módulo el error vi que se trataba de problemas de compatibilidad de los scripts de bases de datos (realmente son los únicos errores que podía dar, ya que para eso era la estrategia de hacerlo desde un IIS7 en local). El módulo se encontraba empaquetado en "Install\Module\HTML_Community_05.04.03_Install.zip" y se descomprimía dinámicamente en la carpeta "/DesktopModules/HTML/Providers/DataProviders/SqlDataProvider".
Las correcciones realizadas sobre los ficheros no eran muy complicadas:
- Comentadas las cadenas NOT FOR REPLICATION ya que no es soportada en Azure
- Comentadas las cadenas ON [PRIMARY] ya que no se soporta en Azure especificación de grupos de ficheros
- Eliminado el índice clustered de la tabla dnn_HtmlText para volver a crearlo por el campo ItemID
Los ficheros modificados fueron los siguientes:
- /DesktopModules/HTML/Providers/DataProviders/SqlDataProvider/03.00.00.sqlDataProvider
- /DesktopModules/HTML/Providers/DataProviders/SqlDataProvider/05.01.00.sqlDataProvider
- /DesktopModules/HTML/Providers/DataProviders/SqlDataProvider/05.01.00.sqlDataProvider
Finalizando el asistente de instalación
Una vez realizados los cambios en el módulo, el siguiente intento de instalación finalizó correctamente con los módulos por defecto. Cruzando dedos seguí paso a paso completando los pasos de Skins, Containers, paquetes de idiomas, sistemas de autenticación, proveedores, configuración del portal inicial. Todo transcurrió sin incidencias. Casi me sale una lagrimita de la emoción.
Cuando pulsé el botón de comenzar a navegar por el portal, sonaron redobles de tambores y apareció la pantalla de inicio, preparada para su edición.
Conclusión
Una vez realizado este trabajo, tenía una instalación de DNN preparada para usar como base de datos SQL Azure. Sin embargo, aunque fuera un gran paso, había bastante trabajo en el horizonte. Tener el portal DNN en un servidor fuera de Azure y la base de datos en SQL Azure no era ni mucho menos óptimo -se notaba en la velocidad- sino que además podría salir caro -se cobra el tráfico de entrada y salida del datacenter.
El siguiente objetivo estaba claro: desplegar el portal sobre Azure usando la base de datos en la nube.
Hasta aquí el capítulo de hoy. Les dejo con unos dibus para aquellos que les entró dolor de cabeza y sobre todo para aquellos llegaron aquí abajo saltándose todo el post. Por lo menos algo les resultará entretenido :)
"¡Y no olviden supervitaminarse y supermineralizarse!"
No hay comentarios:
Publicar un comentario