Como ya saben los habituales de este blog, nuestro Cliente Preferido
TM dispone de una web con bastante demanda, con una arquitectura algo inusual, basada en Windows Server, Apache, MySQL y ColdFusion. En general, y después de un par de cambios a servidores más potentes y bastante
fine tuning de ColdFusion y MySQL, el conjunto respondía bastante bien, con picos de hasta 30.000 páginas servidas en una hora a un ritmo bastante decente.
Pero diversos inconvenientes (principalmente un molesto bug de Windows por el cual el servidor se reiniciaba al menos una vez al día), y una cierta previsión de futuro, han sido la causa de que las últimas semanas nos hayamos dedicado a migrar todo el servidor: unos cuantos gigas de contenidos, cientos de scripts en CF, una veintena de bases de datos, y todo el software asociado (análisis de estadísticas, tratamiento de imágenes, blogs, y cosas por el estilo). Y ya que estábamos de mudanza, aprovechamos para cambiar la arquitectura y nos pasamos a Linux. Así que ahora lo tenemos sobre una arquitectura más habitual de Linux, Apache, MySQL, y el no tan común ColdFusion. Puestos a mudar, pasamos también de la versión 4 a la 5 de MySQL.
La mudanza, para que negarlo, ha tenido sus momentos "infernales". Por las características del cliente, cuyas bases de datos se actualizan constantemente, la ventana para pasar de pruebas a producción en su nuevo hogar era muy pequeña. Después de semanas de pruebas en el nuevo servidor, la calculamos en una hora y media, un viernes por la tarde-noche. Así que a las 19:30 bloqueamos los servicios más delicados, transferimos los datos actualizados, hacemos una última prueba, y por último activamos todo en el nuevo servidor y hacemos una redirección a nivel de Apache para desviar todas las peticiones al nuevo servidor en lo que se completaba la propagación de las nuevas IPs. Eso fue a las 20:15, más o menos, por lo que íbamos muy bien sobre el horario previsto. A las 3:00 aproximadamente, conseguimos dejarlo todo más o menos operativo.
A las 20:15 todo parecía ir bien, pero en poco tiempo empezamos a recibir avisos de que no, el servidor no estaba atendiendo a las peticiones... Aunque nosotros podíamos entrar perfectamente. Tardamos un buen rato en descubrir que era un problema de ColdFusion: en determinadas instalaciones, al pasar de la versión trial a la estándard, aunque reconozca el número de serie y diga que sí, que se ha actualizado, en realidad no lo hace, sigue pensando que está en trial, y por tanto, sólo admite conexiones de 5 IPs distintas... Por eso nosotros veíamos la web, pero el ordenador de al lado, que iba por otra red, no.... La única solución, reinstalar CF desde cero :P
Para no cansarles, el principal problema que tuvimos, tanto en las semanas de pruebas como en esa noche infernal, y en menor medida los días siguientes, fueron los permisos: el usuario de FTP subía ficheros que luego el usuario de ColdFusion no podía modificar o borrar, o el usuario de CF no podía leer determinados directorios, olos ficheros creados por CF no podían ser borrados por el usario de FTP, o .... Permisos y usuarios. Si algún día migra algo de Windows a Linux, mire eso lo primero. Es donde se le vá a liar todo...
Otro problema fué el UTF-8. CF usa UTF-8 de forma nativa, así como MySQL, y toda la aplicación está diseñada para usarlo. Pero las plantillas las trabajamos con Homesite, que parece que no respeta mucho esta codificación de caracteres, pero a Windows le dá igual. A Linux no. Así que todos los acentos y eñes que no salían de la base de datos se veían como unos lindos cuadraditos, que le daban un cierto toque pop a la página, pero resultaban algo incómodos de leer. Por suerte, una pasada con un script a base de
iconv
y la cosa se resolvió en minutos. Aunque aún estamos intentando que Verity devuelva correctamente estos caracteres, esperamos resolverlo en breve... :(
Por supuesto, también tuvimos problemas con mayúsculas/minúsculas. El comportamiento de MySQL es distinto en Windows y en Linux, y mientras que en el primero le da igual, en el segundo es sensible a mayúsculas. Así que la tabla plantillasdefecto no se daba por enterada cuando llamábamos a PlantillasDefecto en el código. Todavía estaba temblando ante la perspectiva de tener que cambiar cienes de nombres de tablas cuando descubrimos la maravillosa variable
lower_case_table_names
, que controla este comportamiento. Ponerla a 1, reiniciar MySQL, y volver a la "normalidad". Uf.
Pero lo que realmente me interesaba comentar en este post (¿alguien ha llegado hasta aquí?) es que
no tuvimos que tocar ni una de las miles de líneas de código de la aplicación. El salto de Windows a Linux y de MySQL 4 a 5 fue completamente transparente para ColdFusion. Consultas a bases de datos, servicios web, creación dinámica de PDFs y gráficos en Flash.... Todo todito todo.
Bueno, vale, miento. Algunas páginas que trabajaban con ficheros usaban los paths con "\", que funcionan en Windows, pero no en Linux, que usa "/". En esas páginas incluimos un "detector" de sistema operativo y ahora se usan las barras correctas en función del SO utilizado, o sea que si ahora hiciéramos el cambio, no habría que tocarlo. También hubo que cambiar el programa (externo) de tratamiento de imágenes, que se llama con un
cfexec
. La ruta del programa se configura en el panel de control de la aplicación, pero la cadena que se le pasa si está codificada "on the fly", y hubo que retocarla para adaptarla al nuevo programa.
Pero aparte de eso, nada, niente, none. Varios miles de líneas. Decenas de CFCs, cientos de funciones... Y todas han seguido funcionando a la perfección.... Ah, que bonita es la transportabilidad....
(nuestro más profundo agradecimiento a Eduardo, que aguantó como un campeón al otro lado del GoogleTalk peleándose con el servidor, y a Kuko, que junto a Eduardo, nos ayudaron a afinar las cosillas pendientes los siguientes días).