Hacía tiempo que estaba pensando en darle una vuelta a las tripas de Incognitosis. Mi afición por Linux me ha permitido trastear con temas de administración de sistemas durante muchos años, y de hecho me encargué de la infraestructura técnica de TPNet mientras ejercí como CTO de esa empresa.

Aquella etapa me convirtió una afición en una profesión, y me dio la oportunidad de investigar mucho, pasar buenos ratos (y malos, lo de que todo funcione perfecto 24/7 genera estrés), aprender y también conocer más en profundidad un tema que luego siempre he tenido vigilado de cerca: el rendimiento web, o web performance.

De cuando en cuando comparto cosas en Twitter del tipo #sysadminporn, pero lo que hago de forma no transparente es guardar enlaces y tutoriales que me ayudan a comprender por dónde van los tiros en el ámbito de la seguridad y el rendimiento.

Todo milisegundo cuenta

Eso me llevó hace unos años a montar Incognitosis con una configuración singular que dio lugar a aquel megapost titulado ‘WordPress a toda pastilla con Nginx+PageSpeed, MariaDB, HHVM y más en Ubuntu 12.04‘ y en el que sobre todo destacaba el uso de HHVM y PageSpeed para acelerar la carga del blog de forma bastante notable.

Aquello tenía algún problema, porque HHVM es medio inestable con WordPress y tuve que utilizar monit para levantar el servidor hhvm cuando se quedaba tonto. La solución molaba y funcionaba, pero no era óptima.

Eso me hizo migrar a otra plataforma para olvidarme de HHVM. Desde hacía tiempo seguía la evolución de PHP 7, una versión que sin ser tan rápida como HHVM ya ganaba muchos enteros respecto a la anterior, así que quise ponerla en marcha y hacerlo además con otro experimento: Centminmod.

Siempre he sido bastante fan de los scripts que permiten automatizar tareas pesadas en Linux, y en los temas de administración de sistemas esos scripts han sido poderosos aliados durante mucho tiempo. Años atrás hablaba de Tuxlite, pero el desarrollador de esta pequeña maravilla dejó de trabajar en él, así que busqué una solución similar y la encontré en Centmin Mod, un script mucho más ambicioso y potente que eso sí, se basa en Cent OS una distro a la que estoy poco habituado aunque sea básicamente una Fedora en versión «pro».

Objetivos de la nueva plataforma

Acabé migrando a este sistema hace un año y estaba tan contento, pero lo cierto es que Incognitosis seguía quedándose atrás en algunas cosas. La idea con la nueva renovación técnica de Incognitosis era lograr varias cosas:

1. HTTPS al poder: para cifrar todas las peticiones entre vosotros, los lectores, y el servidor. En Google lo tienen muy en cuenta para posicionar, por ejemplo, pero mi blog no posiciona bien de todos modos (sigo con PR 3 a pesar de mis esfuerzos). Hay varias razones de peso adicionales para usarlo.
2. HTTP/2: el nuevo protocolo HTTP/2 que inicialmente tomó como base SPDY pero que luego evolucionó de forma significativa para hacer que todo vaya más rápido gracias a una serie de técnicas muy chulas. El resultado, dicen (veremos) es que la carga de la página mejora de forma notable.
3. Incognitosis bajo Git: otro de los cambios importantes ahora que mi mujer trabaja habitualmente con Git es el de poder hacer cambios en el blog de forma mucho más pura desde el punto de vista de un desarrollador web, con una versión de preproducción local para hacer pruebas y una versión de producción que será la que veáis vosotros. Todo bajo Git para ir controlando versiones y volviendo a anteriores si las cosas no van como deben. No se trata de usar la última versión de WordPress vía Git, sino solo la del tema y componentes específicos de mi blog.

Seguro que surgen más cosas durante el proyecto, así que iré apuntándolas por aquí. Vamos allá.

Bienvenido, EasyEngine

Hacía tiempo que pensaba reinstalar Centmin Mod de cero para aplicar estos cambios, pero en medio del proceso de investigación —de hecho ya había iniciado las pruebas en el VPS— me encontré con una sorpresa: otro script que permitía hacer básicamente lo que quería y con la misma orientación que Centmin Mod.

Ese script se llama EasyEngine, y es una pequeña maravilla tanto por su simplicidad como por su eficiencia. Está muy enfocado a automatizar instalaciones de WordPress en VPS para que sean realmente óptimas, y con la base tradicional de una plataforma LEMP (Linux, Nginx, MySQL y PHP, la «E» es por lo de la pronunciación de nginx, que es «engine-x«) añade unas cuantas cosas muy, muy chulas.

Por ejemplo, el soporte (si quieres) para HHVM y Pagespeed, además del soporte de varias opciones de cacheo que incluyen plugins como W3 Total Cache, WP Super Cache, FastCGI o la que yo he elegido, que es Redis.

Otra de las cosas que me atrajo de EasyEngine es que está orientado a Ubuntu y a Debian, distros con las que me siento más a gusto, así que acabé reinstalando el SO en uno de mis dos VPS para aplicar allí la instalación de un Ubuntu 16.04 LTS. Tras hacerlo y actualizar todo por si las moscas ejecuté dos comandos:

wget -qO ee rt.cx/ee && sudo bash ee

El primero descarga el script de instalación y prepara el VPS para poder ejecutar, mientras que el segundo es el que parece mágico:

ee site create javipas.com --wpredis --letsencrypt --php7

Ahí lo tenéis. Con esa simple línea de comandos en 15 minutos tenía creado el sitio javipas.com con WordPress, Redis, un certificado de seguridad asignado al sitio para dar soporte (al fin) a HTTPS con LetsEncrypt, y además PHP7, que como dije en la anterior versión se lleva mejor con WordPress que HHVM aunque creo que en rendimiento sigue yendo (algo) mejor HHVM.

En realidad no pude asignar el certificado de LetsEncrypt de primeras porque una de las condiciones para lograrlo es que en el registro del dominio se verifique que ese dominio apunta al servidor donde realizas la petición. O sea, que tenía que migrar todo Incognitosis primero, cambiar las IPs en mi registro de dominios y hacer un

ee site update javipas.com --letsencrypt

cuando estuviera todo hecho para asignar el certificado de una vez por todas. Es lo que hice con un scp entre ambos VPS y una copia de la BBDD (mysqldump al rescate) que también transferí por scp. Tras crear la BBDD en el nuevo VPS e importar la del VPS de origen, estaba todo listo. Por cierto, el script de EasyEngine crea un cronjob para renovar el certificado cada 90 días, cuando caducan los que te da este proyecto. Maravilloso.

O casi.

Tras aplicar el certificado la página de inicio mostraba que todo había ido bien: Incognitosis ya era «segura». En Chrome aparece el candado en verde y el deseado «Es seguro», pero al navegar a algún post se mostraba una advertencia: parte del contenido era seguro, pero por ejemplo me avisaba de que las imágenes no lo eran y podían ser usadas para hacer cosas malitas.

El tema es bastante conocido: los llamados contenidos mixtos hacen que parte del sitio esté protegido, pero que haya scripts, imágenes y otros objetos que no lo estén. En ManageWP encontré una buena explicación para resolverlo, y al final acudí a dos cosas: este plugin para corregir la mayoría de fallos, y además, la consola de Google Chrome para analizar qué más recursos estaban fallando.

Encontré dos un poco tontos: el código de Statcounter no estaba actualizado y tuve que copiar y pegar uno con soporte HTTPS, y también había un fallito en Feedburner, que sigo usando para generar los avisos de nuevos posts en Incognitosis por correo (os podéis apuntar al final del post, antes de los comentarios). En el enlace faltaba añadir la «s» del «https://».

Voilà. Incognitosis ya es seguro a tope. Que viva HTTPS. Ah, y ya que estamos, que viva HTTP/2 (se puede comprobar aquí), que también está activado por defecto y funcionando (ALPN incluido) gracias a Nginx, que desde hace algún tiempo ya da soporte nativo a HTTP/2 en sus versiones estables. Ole.

Lejos de la perfección

Actualización (26/04/2017): pues la cosa no era para tanto. Los dos GET aparecen porque en GTmetrix usaba la URL no segura en lugar de meter directamente la segura, https://javipas.com. Al hacerlo desaparece el primer GET que redirige a la versión segura. ¡Hurra!

La migración a la nueva infraestructura ha traído un problemilla: ha empeorado el tiempo de carga. No creo que lo notéis mucho, pero aquí he cometido algún error que ha hecho que en algún lado esté metiendo redirecciones que no deberían estar ahí. Un test rápido en GTmetrix lo demuestra:

Ahí lo tenéis: esos dos GET deberían ser uno que además debería ser bastante más rápido. Pierdo casi un segundo en el acceso al dominio, algo que también viene motivado porque la región de pruebas es Canadá.

El tiempo de carga no es malo, pero desde luego tampoco es una maravilla, sobre todo cuando hace tiempo que traté de trabajar en minimizar la carga de la página y en hacer que todo fuese más suave. Como comenté por aquí, hay compromisos con temas como la tipografía, y aunque en general estoy contento con el rendimiento, me gustaría afinar en unas cuantas opciones para ganar más en rendimiento y hacer la página más ligerita.

Sé que podría lograr bajar a la mitad el tiempo (o menos), pero eso lleva (redundante e irónicamente) tiempo. Tiempo que no me sobra, sobre todo cuando uno se da cuenta de que para lograr la migración al final he invertido un par de días de vacaciones (a ratos) entre investigar (mucho de esto), probar, cagarla y volver a probar.

Quedan además muchos flecos por atar, como la seguridad del servidor (medio controlado, pero aquí haré quizás un post adicional si os interesa), el tema de controlar con Git la versión de WordPress (ídem, caerá post cuando lo haga) y esos ajustes finos de Nginx, Redis, PHP y MySQL que ayudan a rebajar milisegundos, pero sea como fuere, aquí tenéis un Incognitosis cifradito y con ese soporte HTTPS que hacía tiempo que tenía que haber aplicado.

Puede que en el proceso algo no vaya como debe, así que si detectáis fallos o cosas raras, avisad. Y si hay algún gurú del #webperformance que quiera darme consejitos (yo aquí soy un principante con mucho interés), por favor, que comente. Todo por hacer que esto vaya más rápido y mejor.

Ale. Bienvenidos a Incognitosis en versión HTTPS.