Drush runserver al rescate

Para uno de los clientes empresariales de LakeDrops hemos desarrollado un conjunto bastante complejo de intranets con Drupal 9, donde uno de los sitios es un hub de contenido con decenas de miles de nodos y términos de taxonomía que se mantienen, revisan y publican en ese hub. Todos los demás sitios requieren esas entidades en modo de sólo lectura también, y hemos elegido el gran módulo Entity Share para sincronizar fácilmente todas las entidades del hub a todos los demás sitios.

Aunque esto está funcionando muy bien, nos topamos con un gran muro al desplegar esto en producción. El proceso de sincronización se inició con éxito, sólo para fallar mal después de un par de segundos.

Entity share utiliza el JSON-API de Drupal para intercambiar toda la información entre el hub de contenidos y los clientes, que quieren recibir las entidades de contenido. Por lo tanto, utiliza peticiones http para recibir listas de entidades y después las propias entidades, por supuesto sólo aquellas que no han sido sincronizadas todavía o han sido actualizadas desde la última sincronización. Para un centro de contenidos tan grande, esto se traduce en un enorme número de peticiones http desde una única fuente hacia siempre el mismo destino. Dicho esto, después de unos cientos de respuestas 200 como se esperaba, de repente sólo recibimos códigos de error 503 - y ya no hay entidades.

El registro de errores de Drupal del hub de contenidos no contenía ninguna indicación de lo que estaba pasando. Esas solicitudes para las que recibimos respuestas 503 ni siquiera llegaron a ese sitio de Drupal en absoluto. Deben haber sido rechazados en algún lugar anterior en la pila de TI de esa empresa internacional, que es completamente desconocido para nosotros, el equipo de desarrollo de Drupal.

Apertura de incidencias en Jira, varias llamadas telefónicas, un montón de correos electrónicos de ida y vuelta, y varias horas después hemos tenido más preguntas sin responder que al principio de ese proceso. Mientras que la explicación parece obvia: hay un límite de peticiones o un WAF (firewall de aplicaciones web) involucrado, cualquiera de los cuales se activó por el patrón de peticiones que enviamos. El mero hecho de averiguar de qué se trata exactamente, quién es el responsable y qué formulario debemos rellenar para la solicitud de cambio ha provocado más quebraderos de cabeza que esperanzas de resolución. Para empeorar las cosas, ha habido varios departamentos en varios países esperando el resultado, ya que reservaron su propio tiempo para la revisión de nuestra configuración. Se necesitaba una solución rápida.

Así las cosas, todas las instancias de Drupal implicadas - el centro de contenidos y todos los clientes que leen desde él - están ubicadas en la misma LAN y pueden comunicarse entre sí. Entonces, ¿por qué no solicitar el contenido internamente, es decir, desde un sitio Drupal cliente al hub de contenidos, sin utilizar el dominio oficial y la ruta a través de la pila de TI completa? Porque eso requiere que el concentrador de contenidos ejecute su propio servidor web para recibir solicitudes http y responder a ellas. Pedirle a TI que configure uno para nosotros, habría sido igualmente difícil de explicar, si no imposible.

Ahí es donde la herramienta CLI de Drupal, drush, vino a ayudar. Por alguna razón, drush tiene un servidor web integrado implementado en PHP, que por supuesto estaba disponible en la infraestructura existente. Así que decidimos darle una oportunidad, aún siendo escépticos si podría manejar la enorme carga de todos los clientes para todas esas entidades:

$ > drush runserver 8080

[notice] Servidor HTTP escuchando en 127.0.0.1, puerto 8080 (ver http://127.0.0.1:8080/), sirviendo el sitio, sites/default
[Fri Jul 15 14:22:52 2022] Servidor de desarrollo PHP 7.4.30 (http://127.0.0.1:8080) iniciado

Eso es todo, no se requiere ninguna otra configuración o puesta en marcha. Esto utiliza la configuración existente del sitio de Drupal, accede a la base de datos igual que con una pila LAMP y lo mejor de todo es que no interfiere con la infraestructura existente, que se sigue sirviendo en paralelo, mientras que el servidor web incorporado de Drush responde a las peticiones internas de los clientes de entity share. Sólo se tuvo que reconfigurar para hablar con la dirección IP interna del centro de contenido en lugar de su dominio público, y eso fue todo.

Pero espera, ¡esto se estrelló después de 4 horas! ¿Por qué? Porque el servidor web contenía un tiempo de espera codificado de 14400 segundos. Bueno, no hay problema, creé un pull request en el repositorio de GitHub de Drush para eliminar ese tiempo de espera, y sólo 5 horas después Moshe Weitzman lo aceptó y fusionó el cambio en Drush.

Problema resuelto, el cliente está contento, no se han incumplido los plazos y se ha vuelto a demostrar la fortaleza de Drupal. Gracias