A raíz de una consulta que me llega de Jesús González a través de Google+, parece que instalar WordPress en una carpeta de Azure Websites no es tan común como pensaba, o, al menos, no está demasiado documentada. La idea es que http://www.miwebsite.com/blog pueda alojar una instancia de WordPress, mientras que en el raíz se mantenga una aplicación .Net. Este mismo escenario es el que tengo yo aquí mismo, en este blog.

Para ello, la primera opción sería seguir uno de los tutoriales que existen para ello, como este: http://blogs.msdn.com/b/kaushal/archive/2014/04/19/microsoft-azure-web-sites-deploying-wordpress-to-a-virtual-directory-within-the-azure-web-site.aspx. Este tutorial aborda una instalación desde cero de WordPress, realizando una instalación en local a través de la galería de aplicaciones de WebMatrix, y realizando la publicación a posteriori sobre el website.

Sin embargo, se puede dar el caso de que ya dispongamos de un WordPress funcionando y no queremos que WebMatrix le meta mano a nuestro código. Para ello necesitaremos realizar un par de pequeñas modificaciones manuales.

En este post anterior, en el que desglosaba un poco los detalles técnicos que he utilizado para implementar esta web, ya indicaba la problemática de compartir WordPress con MVC en Azure, y cómo lo había solucionado, pero parece que el tema tiene entidad suficiente como para dedicarle este pequeño post.

Configurando el Website

El problema principal de intentar hacer convivir una aplicación basada en .Net con otra basada en PHP, como es el caso, es saber discernir cuándo las peticiones que recibe el website las tiene que manejar un framework y cuándo el otro. En este caso, todo lo que se reciba a la url “/blog” y por debajo de ésta, lo tiene que renderizar el motor de PHP, y, en concreto, WordPress. Todas las demás, dejaremos que las maneje .Net.

Para ello, añadiremos la siguiente configuración al archivo web.config que se encuentra en el raíz del sitio web:

De esta manera, utilizamos el módulo url_rewrite para enviar al motor de WordPress todas las peticiones que se reciban en la carpeta “/blog”

En segundo lugar, crearemos un segundo archivo web.config y lo alojaremos dentro de la carpeta “/blog”, con el mismo contenido:

Finalmente, también sería recomendable configurar el Website para indicarle que hay una aplicación virtual en la carpeta “/blog”, tal y como se indica en el enlace que he dejado al inicio.

Dependiendo del tipo de aplicación .Net que tengamos instalada, tendremos que decirle a su vez que ignore todas las peticiones a “/blog”. En mi caso,que utilizo MVC, esto se consigue añadiendo la siguiente configuración de enrutamiento:

En general, el concepto es el mismo para hacer convivir cualquier aplicación .NET y PHP:

  • Redirigir las peticiones desde la aplicación raíz a la carpeta de la otra aplicación
  • Configurar la aplicación raíz para que ignore las peticiones a la aplicación anidada.

¡Espero que os sea de utilidad!

Servidores(cc) Foto por Rob Halsell

Después del post inicial de presentación, ahora viene el rollete con los detalles técnicos de cómo he montado esta web, qué tecnologías y servicios hay detrás y demás tecnicismos frikis. ¡Avisado quedas!

La web se divide en dos aplicaciones: Páginas estáticas y el Blog.

Las páginas estáticas

Tanto la pantalla de Inicio, como la parte de Proyectos y la Biografía las he implementado mediante ASP.NET MVC 5.

Dispone de un pequeño Backend, para almacenar los datos de los Proyectos, Clientes, Imágenes, etc. para el que utilizo sencillos archivos XML que deserializo a objetos DTO (Data Transfer Object) que luego manipulo con Linq. El coste de la deserialización de estos archivos está entre 5 y 10ms, que es despreciable, y que además cacheo en memoria, por lo que no supone una penalización mayor que tenerlos en una BD relacional al uso. De hecho, es apreciablemente más rápido y barato, y el volumen de datos que manejo es relativamente pequeño.

A modo de ejemplo, esta es una muestra del archivo que almacena las categorías de proyectos:

y este, un fragmento resumido de la clase C# que lo deserializa:

Una vez dispongo del modelo de datos modelado y los archivos XML con la información controlados, desarrollo las 4 vistas principales del proyecto, utilizando Razor como View engine y Bootstrap + el template Unify para el diseño y la implementación del frontend.

El blog

Para montar el blog me decidí a utilizar WordPress, porque no tiene sentido reinventar la rueda y ponerme a programar un gestor de blogs desde cero, y porque últimamente he estado trabajando con esta plataforma por motivos profesionales y le estoy cogiendo el tranquillo, además de para seguir aprendiendo y probando cosas nuevas para futuros proyectos.

Como era importante para mi mantener una uniformidad visual, decidí utilizar el mismo tema que para el resto de la web, por lo que me tocó adaptar el tema a WordPress, ya que en origen no viene preparado para ello.

Como curiosidad, comentaré que el blog está incluido dentro de la misma solución de Visual Studio que implementa la web, en una carpeta /blog, ya que me facilita las cosas a la hora de hacer el deploy del site a Azure desde el propio IDE, además de ahorrar costes de hosting porque sólo necesito un site. Pero para que esto funcione y convivan ambas tecnologías (ASP.NET MVC 5 y PHP) hay que hacer un par de retoques, para que cada una enrute sus peticiones y no interfiera en las de la otra.

En mi caso, utilizo como alojamiento Azure Websites, por lo que mi servidor web es un IIS ejecutando PHP 5.5.

Por una parte, en el archivo Web.config común hay que incluir la regla de enrutamiento de WordPress:

Importante comprobar como sólo enrutamos las peticiones a blog/*. De esta manera, el motor de PHP ignora las peticiones que no vayan explícitamente al blog y se las deja a MVC. Igualmente es importante cambiar el nombre de la regla, de “wordpress” (por defecto) a otro (en mi caso, “blog“). Esto es debido a que es muy probable que tengamos otro archivo web.config dentro del directorio del blog que utilice los valores por defecto y esto crea un conflicto en IIS que generará un error y el blog dejará de funcionar.

Por otro lado, es importante decirle a MVC que no enrute las peticiones al blog, para que las maneje PHP. Esto se consigue añadiendo la siguiente línea antes del código de definición de las rutas de nuestra aplicación:

Los servicios

Para el alojamiento utilizo 1 Azure Website, que comparten tanto el site en MVC 5 como el blog en WordPress, así comparto gastos de hosting.

Para mejorar el rendimiento, utilizo CloudFlare como proxy DNS, que me proporciona servicios de seguridad y optimización automáticos de forma transparente, y Varnish como servidor proxy-caché, que tengo instalado en una máquina virtual Extra pequeña con Ubuntu, también sobre Azure. La unión de estos dos servicios reduce enormemente el número de peticiones que recibe el sitio web, por lo que es suficiente con una instancia compartida del Website para mantener el site.

Finalmente, una vez aplicadas las técnicas de optimización WPO al site principal, www.sergigisbert.com, obtenemos la siguiente calificación de GTMetrix:

gtmetrix webVer el informe completo

Siempre penalizada por la inclusión de recursos externos a los que no tenemos acceso.

Dudas, aclaraciones, preguntas, sugerencias, ¡aquí me tenéis!