De LAMP a LEMP

Como fundador de la difunta Frikipedia, una de mis primeras labores fue el montar un servidor web. En 2005 la elección por antonomasia era, por supuesto, el stack LAMP en Debian. Por aquel entonces no existía verdadera competencia en el segmento de webs personales, y sigue siendo hoy día el recomendado para MediaWiki.

Para los rezagados, LAMP significa Linux+Apache+MySQL+PHP, y es uno de los stacks más utilizados a la hora de construir páginas web personales. Linux (estrictamente distribuciones de GNU/Linux) provee el sistema de explotación de la máquina, Apache el servidor HTTP, MySQL la base de datos y PHP el lenguaje de programación.

Esta elección es robusta y más que probada, y hay tanta documentación y soporte en Internet que cualquiera puede aprender en poco tiempo a montar un servidor si elige adecuadamente el sistema operativo correcto. En mi caso fue Debian, pero pudo ser igualmente alguno de los sabores de Red Hat, Ubuntu Server o incluso Gentoo. Eso sí, que tengan un buen gestor de paquetes es casi imprescindible.

Pese a la citada robustez, las aplicaciones se asientan sobre unos cimientos más bien vetustos. Apache empezó en 1995 con el código base de NCSA HTTPd, que a su vez data de alrededor de 1993. MySQL es ahora propiedad de Oracle, y PHP como CGI o incluso como módulo de Apache es un planteamiento desfasado hoy día. Por ello cada vez más se habla del stack LEMP.

¿Qué hay detrás de este baile de letras? Bueno, Linux en servidores sigue funcionando bien, aunque hay quien prefiere usar Windows (en cuyo caso hablaríamos de WAMP, o WEMP). Apache sin embargo se enfrenta a alternativas muy interesantes, caso de Nginx. (El nombre es una especie de apócope angloparlante de Engine X, Motor X, de ahí la E de LEMP.)

Las diferencias entre Apache y Nginx empiezan por lo básico. Apache es toda una torre de módulos, sistemas y esquemas de configuración que abarcan todo uso posible, y se nota el paso de los años al tratar de construir soluciones complejas. Nginx es relativamente nuevo, cuenta con un planteamiento bastante purista y sobre todo es relativamente liviano y rápido.

La configuración de ambos en apariencia no es muy diferente. Sus parámetros no serían muy distintos de otros servicios: interfaz de red en escucha, puertos a bloquear, páginas por defecto… pero la forma de configurarlos cambia sustancialmente. Si bien Apache se configura en ficheros parecidos a un XML bastante estricto, Nginx usa una especie de JSON bastardo mucho más flexible, que permite definir Vhosts de forma mucho más elegante o añadir condiciones y configuraciones mediante expresiones regulares. No obstante, Nginx no permite añadir módulos sin compilar y no admite ficheros tipo .htaccess por principios de diseño. Aunque, realmente, para un servidor de producción esto más que un problema termina por ser un requisito si pretendemos realizar un buen diseño.

En desempeño bruto, Nginx es más rápido y liviano en casi cualquier circunstancia, sobre todo a la hora de servir contenido estático. Cierto es que Apache puede modularizar su módulo de multiproceso, pero no justifica el detrimento del rendimiento; además Nginx veremos cómo permite emular los MPM más importantes. El principal problema de entrada de Nginx aparentemente sería la falta de configuraciones por directorio, el famoso .htaccess de Apache. En realidad el único impedimento no poder definirlo en caliente, dado que todas estas configuraciones pueden incluirse en el vhost en el arranque. Para un entorno de producción esto debería ser más que suficiente.

Anteriormente comento que, a la hora de usar PHP en nuestro servidor, usar una pasarela CGI o un módulo de servidor es un concepto completamente obsoleto. La pasarela CGI es lenta, normalmente depende de esperar a un proceso por cada petición; y si usamos un módulo de Apache estamos atados a dicho software y es muy poco modular. La alternativa a esto es, curiosamente, una variante de las pasarelas CGI: PHP-FPM, que usa FastCGI.

PHP-FMP no es más que una forma de abstraer PHP del servidor web, de manera que creamos un servicio del sistema para atender las peticiones de ficheros PHP. Este servicio gestiona un pool completamente configurable de instancias preparadas para gestionar nuestras peticiones. Aunque el MPM ITK es interesante porque permite ejecutar PHP con un UID concreto por vhost, podemos tener un pool distinto para cada usuario, de manera que el funcionamiento es virtualmente idéntico (y podemos configurar cada pool como mejor nos convenga). Podemos comunicarnos con este servicio mediante sockets de UNIX o mediante red, pudiéndolo así tener en otra máquina si nos interesa.

El conjunto Nginx+PHP-FMP funciona con las aplicaciones actuales sin cambios o simplemente convirtiendo los .htaccess a reglas del vhost. Como mucho nos enfrentaremos a cambios en la forma de tratar reglas específicas de Apache, en cuyo caso se resuelven de forma similar. De depender de módulos concretos estaremos en desventaja, pero lo cierto es que ya hay un montón de módulos disponibles. Aplicaciones como MediaWiki o WordPress no funcionan directamente con URLs bonitas debido a que no tenemos el mod_rewrite, pero hay herramientas en la web para convertir los dichosos .htaccess en reglas del vhost. Fuera de eso, funcionan como siempre.

El último punto es MySQL. Soy de la opinión que considera este sofware como «de juguete» pese a que grandes aplicaciones como Facebook, la Wikipedia o WordPress lo usen, y que en la mayoría de los casos vale la pena optar por PostgreSQL. Lógicamente esto no siempre es posible, dado que la sintaxis no es siempre la misma, o simplemente porque sea un requerimiento el usarla. La cuestión es que, al haber absorbido Oracle a Sun Microsystems, el futuro y la licencia de MySQL están en entredicho. Hay opiniones encontradas al respecto, pero en todo caso vale la pena considerar un fork llamado MariaDB.

Las premisas de este nuevo proyecto son claras: Por un lado, la continuidad con el proyecto en forma de compatibilidad binaria. Por otro, la promesa más que creíble de mantener el proyecto como software libre sin concesiones. En cuanto a la licencia, está claro que puede ser tanto una cuestión de principios o simplemente de conveniencia. La compatibilidad binaria es algo más complicado, pero dado que comparten su código base esto se empieza a entender. MariaDB nos pone las cosas muy fáciles porque no sólo los binarios son compatibles, sino que todo se instala en la misma ruta, se configura de la misma forma y por supuesto se usa exactamente igual. Es, por tanto, una alternativa «drop-in» para MySQL. En el rendimiento, MariaDB puede ser más rápido en determinadas circunstancias debido a que se han desarrollado ciertas optimizaciones.

Hay, sin embargo, una contra a considerar. Si bien MariaDB por ahora tiene la delantera a MySQL, es de esperar que a partir de ahora los desarrollos transcurran en paralelo. Por ahora MariaDB tiene más motores de persistencia, más opciones y más características punteras; pero MySQL bien podría tener añadidos paralelos a éste. Eso y los omnipresentes bugs de MySQL, que podrían ser distintos en MariaDB. Pero todo esto es harina de otro costal.

Para terminar, bajo mi valoración personal creo que vale la pena tener en cuenta el stack LEMP a la hora de desarrollar, realizar reingeniería o incluso portar aplicaciones existentes. Máxime cuando se trate de entornos de producción estables. También parece interesante si vamos a usar soluciones usuales (WordPress, Joomla, Drupal, etc). Como casi todo, parece poco recomendable en caso de aplicaciones muy antiguas, que dependan de reglas muy complejas o módulos personalizados o que dependan de sistemas heredados. En ese caso ya se sabe: si a la primera no funciona… a hacer puñetas y no se toca más.

Hasta aquí son mis consideraciones a la hora de modernizar el stack LAMP. En el caso de la Frikipedia esta migración era más que posible, y de hecho estuvo en pruebas unos días, pero a falta de tiempo para perfeccionar el traslado se volvió al antiguo LAMP. En mi experiencia personal, configurar un entorno LEMP en Debian no podía ser más sencillo. Todos los programas se pueden instalar mediante apt-get rápidamente y sin ningún contratiempo. Tan sólo el paquete phpmyadmin requirió crear a mano un enlace simbólico, y sólo por empeño personal en usar el paquete de Debian en lugar del canal oficial de distribución.

Por último, cabe decir que el desarrollo de software en PHP y la administración de sus servidores no es específicamente mi campo de especialización profesional, pero como la necesidad es la madre de todas las cosas me he visto en la ídem de aprender someramente a montar y mantener este tipo de servicios. PHP no es santo de mi devoción, y hoy día existen alternativas que considero más apropiadas, pero chi lo sa.