Drush runserver als Rettung

Für einen der LakeDrops-Unternehmenskunden haben wir ein ziemlich komplexes Intranet mit Drupal 9 entwickelt, bei dem eine der Seiten ein Content-Hub mit zehntausenden von Nodes und Taxonomie-Begriffen ist, die auf diesem Hub gepflegt, überprüft und veröffentlicht werden. Alle anderen Sites benötigen diese Entitäten ebenfalls im Lesemodus, und wir haben uns für das großartige Modul Entity Share entschieden, um alle Entitäten aus dem Hub einfach mit allen anderen Sites zu synchronisieren.

Während dies wirklich großartig funktioniert, stießen wir beim Rollout in die Produktion auf eine große Mauer. Der Synchronisationsprozess startete erfolgreich, um dann nach ein paar Sekunden abzubrechen.

Entity Share nutzt die JSON-API von Drupal, um alle Informationen zwischen dem Content Hub und den Clients auszutauschen, die die Content Entities erhalten wollen. Dazu werden http-Requests verwendet, um Entity-Listen und anschließend die Entities selbst zu empfangen, natürlich nur die, die noch nicht synchronisiert wurden oder seit der letzten Synchronisation aktualisiert wurden. Bei einem so großen Content-Hub führt dies zu einer großen Anzahl von http-Anfragen von einer einzigen Quelle an immer dasselbe Ziel. Abgesehen davon erhielten wir nach einigen hundert 200er-Antworten wie erwartet plötzlich nur noch 503-Fehlercodes - und keine Entitäten mehr.

Das Drupal-Fehlerprotokoll des Content-Hubs enthielt keinen Hinweis darauf, was vor sich ging. Die Anfragen, für die wir 503-Antworten erhielten, kamen gar nicht auf der Drupal-Site an. Sie müssen irgendwo im vorgelagerten IT-Stack dieses internationalen Unternehmens abgelehnt worden sein, was uns, dem Drupal-Entwicklungsteam, völlig unbekannt ist.

Nach dem Öffnen von Issues in Jira, einer Reihe von Telefonaten und vielen E-Mails hin und her, hatten wir einige Stunden später mehr unbeantwortete Fragen als zu Beginn des Prozesses. Dabei scheint die Erklärung offensichtlich: Es handelt sich entweder um ein Anfragelimit oder eine WAF (Web Application Firewall), eines von beiden muss durch das von uns übermittelte Anfragemuster ausgelöst worden sein. Allein herauszufinden, worum es sich genau handelt, wer dafür zuständig ist und welches Formular wir für den Änderungsantrag ausfüllen sollten, bereitete mehr Kopfzerbrechen als Hoffnung auf eine Lösung. Erschwerend kam hinzu, dass mehrere Abteilungen in verschiedenen Ländern auf das Ergebnis warteten, da sie ihre eigene Zeit für die Überprüfung unserer Einrichtung gebucht hatten. Eine schnelle Lösung war nötig.

Als es passierte, befanden sich alle beteiligten Drupal-Instanzen - der Content Hub und alle Clients, die daraus lesen - im selben LAN und konnten miteinander kommunizieren. Warum also nicht die Inhalte intern abfragen, d. h. von einer Drupal-Kundenseite zum Content Hub, ohne die offizielle Domain zu verwenden und den gesamten IT-Stack zu durchlaufen? Weil dies voraussetzt, dass die Inhaltsdrehscheibe ihren eigenen Webserver betreibt, um http-Anfragen zu empfangen und zu beantworten. Die IT-Abteilung zu bitten, einen solchen Server für uns einzurichten, wäre ebenso schwierig zu erklären gewesen, wenn nicht gar unmöglich.

Da kam das CLI-Tool Drush von Drupal zu Hilfe. Aus welchem Grund auch immer, hat Drush einen eingebauten Webserver, der in PHP implementiert ist, was natürlich in der bestehenden Infrastruktur vorhanden war. Also beschlossen wir, es auszuprobieren, wobei wir immer noch skeptisch waren, ob es die riesige Last aller Clients für all diese Entitäten bewältigen könnte:

$ > drush runserver 8080

[notice] HTTP server listening on 127.0.0.1, port 8080 (siehe http://127.0.0.1:8080/), serving site, sites/default
[Fri Jul 15 14:22:52 2022] PHP 7.4.30 Entwicklungsserver (http://127.0.0.1:8080) gestartet

Das ist alles, keine weitere Konfiguration oder Einrichtung erforderlich. Dies verwendet die bestehenden Drupal-Site-Einstellungen, greift auf die Datenbank zu, genau wie bei einem LAMP-Stack, und das Beste ist, dass es die bestehende Infrastruktur nicht beeinträchtigt, die weiterhin parallel bedient wird, während der in Drush eingebaute Webserver auf die internen Anfragen der Entity-Share-Clients antwortet. Sie mussten lediglich so umkonfiguriert werden, dass sie mit der internen IP-Adresse des Content-Hubs anstelle seiner öffentlichen Domain kommunizieren, und das war's.

Aber halt, nach 4 Stunden stürzte das System ab! Und warum? Weil der Webserver einen hart kodierten Timeout von 14400 Sekunden enthielt. Nun, kein Problem, ich erstellte einen Pull-Request im GitHub-Repository von Drush, um diese Zeitüberschreitung zu entfernen, und nur 5 Stunden später akzeptierte Moshe Weitzman die Anfrage und fügte die Änderung in Drush ein.

Problem gelöst, Kunde ist zufrieden, Termine wurden gehalten und die Stärke von Drupal wurde erneut unter Beweis gestellt. Danke!