Such mal im Container! – Solr zieht um

Die Idee des Umzugs der Solr-Instanzen war somit geboren. Als Nächstes musste ein Weg erarbeitet werden, die verschiedenen Solr-Pakete als Container neu anzulegen. Im Anschluss musste jede betroffene TYPO3-Installation die neue URL zum Solr-Server sowie neue Zugangsdaten dazu erhalten und einmalig komplett neu indiziert werden, damit der neue Solr-Suchserver mit Inhalten befüllt werden konnte. Wir haben die Gelegenheit genutzt, um gleichzeitig alle Solr-Instanzen noch einmal auf den allerneuesten Softwarestand zu heben.

Der Betrieb von Solr als Container bringt ein wenig Extraarbeit mit sich. Wir müssen uns beispielsweise selbst darum kümmern, dass die von TYPO3 benötigte Konfiguration in den Suchserver geladen wird. Außerdem müssen die benötigten Solr-Cores angelegt werden. Auf Basis des offiziellen Solr-Docker-Images werden hierzu einige XML-Dateien mit der Feldkonfiguration sowie der Grundkonfiguration von Solr in dessen Datenverzeichnis abgelegt.

Wir setzen bereits erfolgreich Terraform ein, um einen Teil unserer Infrastruktur automatisch zu verwalten. Glücklicherweise gibt es für mStudio einen Terraform-Provider, der uns erlaubt, programmatisch Ressourcen dort anzulegen. Dadurch können wir später auch die Solr-Administrationsoberfläche auf intern genutzte Hostnamen legen und inklusive Authentifizierung zugänglich machen. Dieser Weg bietet uns Infrastructure as Code und schafft eine Lösung, die wir auch dann nachhaltig weiternutzen können, wenn neue Sitesprachen - und damit Solr-Cores - hinzugefügt werden sollen.

Mittwald selbst hat erkannt, dass es einen Bedarf gibt, Solr-Instanzen auf der Cloudinfrastruktur programmatisch anzulegen. Daher gibt es ein entsprechendes Terraform-Modul, das einen möglichen Weg aufzeigt, wie das mit Terraform umgesetzt werden kann. Das Modul startet einen Container auf Basis des offiziellen Solr-Docker-Images und ergänzt dann das Konfigurationsset aus dem Repository der TYPO3-Extension solr. Auf diese Weise lässt sich das später auch aktualisieren. Im Ergebnis sieht eine typische Projektkonfiguration jetzt wie folgt aus:

locals {
  mittwald_project_id = "02159b81-c0bb-4f62-ae57-8dd2e6bd5113"

  solr_version = "9.9"
  solr_heap = "1g"
  solr_hostname = "solr.live.mfc.invalid"

  solr_users = {
    cs = "9PxfZq9si08ebsxB1pwOylsB6uw3nCAkKz4dlKPzfws= ZGtkNHhyNWE5czAxN2xhZA=="
    mp = "2/JqksIj3gA3lXgA7E9BuW9D4t8Ki+x/yWLRUGcFFBY= bjljYzdzbnYwNGVxcTB5ag=="
    sk = "wE0pHBx3d0osQUP2i2LSDiGeqfJhSuc1viaWB5+y6Ao= cWIwZTY3cmNkbDh2aXB1Ng=="

    mfd = "Slw0Dts2bGMS7hKEyuXSxYMpahP8eaAF/3wAXyluwiQ= ZHJlcHlhcGwwcHlpZXBvcQ=="
  }
  solr_cores = {
    "www_marketing_factory_de_de_de" = {
      language = "german"
    }
    "www_marketing_factory_com_en_us" = {
      language = "english"
    }
    "sg_marketing_factory_de_de_de" = {
      language = "german"
    }
    "sg_marketing_factory_com_en_us" = {
      language = "english"
    }
  }
}

Sie definiert die Solr-Version, die einzurichtenden Solr-Cores samt ihrer Sprache sowie die Nutzer, die Zugriff haben sollen. Darunter am Ende einer, den TYPO3 selbst benutzen wird. Zu Beginn wird noch angegeben, in welchem Mittwald-Projekt das Ganze angelegt werden soll. Hierzu ist die Projekt-ID hinterlegt - eine UUID, die jedes Projekt in der Cloudinfrastruktur eindeutig beschreibt.

Ein Aspekt darf nicht vergessen werden: das Thema Sicherheit. Die von Mittwald zuvor bereitgestellten Solr-Pakete wurden hinter einem Reverse-Proxy betrieben, der gleichzeitig Authentifizierung per HTTP-Basic durchgeführt hat. Der Solr-Container selbst stellt diese Funktionalität derzeit nicht bereit. TYPO3 kommuniziert später über ein internes, privates Netzwerk mit dem Container, sodass das da nicht ins Gewicht fällt. Im Regelfall will man allerdings auch auf den Solr-Admin zugreifen wollen. Da es in der Cloudinfrastruktur keine eingebaute Möglichkeit gibt, Authentifizierung für Domains zu aktivieren (Mittwald verschiebt diese Aufgabe auf die dahinterliegende Applikation), haben wir die Authentifizierung in Solr aktiviert.

Das geht mittels einer security.json, die man im Datenverzeichnis von Solr ablegt. Diese würde sogar feingranulares Rollen- und Rechtemanagement erlauben. Da wir das bei uns allerdings nicht in dieser Komplexität benötigen, haben wir darauf verzichtet. Die nötigen Benutzerpasswörter werden als Hashes hinterlegt. Es gibt Online-Tools, die das benötigte Format samt Salt lokal per JavaScript im Browser erzeugen können und die man sehr gut nutzen kann. Jeder Nutzer kann sein Passwort dann selbst hashen und im Konfigurations-Repository committen, sodass die Vertraulichkeit gewahrt bleibt.

Diese Datei sieht dann im Beispiel wie folgt aus (die Hashes sind natürlich nicht echt und für dieses Beispiel neu erzeugt 😉):

{
  "authentication": {
    "blockUnknown": true,
    "class": "solr.BasicAuthPlugin",
    "credentials": {
      "cs": "9PxfZq9si08ebsxB1pwOylsB6uw3nCAkKz4dlKPzfws= ZGtkNHhyNWE5czAxN2xhZA==",
      "mfd": "Slw0Dts2bGMS7hKEyuXSxYMpahP8eaAF/3wAXyluwiQ= ZHJlcHlhcGwwcHlpZXBvcQ==",
      "mp": "2/JqksIj3gA3lXgA7E9BuW9D4t8Ki+x/yWLRUGcFFBY= bjljYzdzbnYwNGVxcTB5ag==",
      "sk": "wE0pHBx3d0osQUP2i2LSDiGeqfJhSuc1viaWB5+y6Ao= cWIwZTY3cmNkbDh2aXB1Ng=="
    },
    "forwardCredentials": false,
    "realm": "Solr administration",
    "scheme": "basic"
  },
  "authorization": {
    "class": "solr.RuleBasedAuthorizationPlugin",
    "permissions": [
      {
        "name": "security-edit",
        "role": "admin"
      }
    ],
    "user-role": {
      "cs": "admin",
      "mfd": "admin",
      "mp": "admin",
      "sk": "admin"
    }
  }
}

Inzwischen sind alle bisherigen Solr-Pakete umgezogen, die Migration hat reibungslos funktioniert. Das neue Setup ermöglicht uns, die Services rund um ein Projekt zusammen mit diesem auf derselben Infrastruktur zu betreiben. Die Nutzung von Terraform bringt den zusätzlichen Vorteil, dass wir nötige Arbeiten wie das Eintragen von IP-Adressen für den Zugriff auf den Solr-Admin auch durch Terraform durchführen lassen können, sofern es für den jeweiligen Domain-Registrar einen Terraform-Provider gibt. Das verringert manuelle Arbeiten nochmals zusätzlich und reduziert Fehlerquellen.

Mit dem Container-Hosting können wir neben Solr natürlich jetzt noch weitere Dinge, die aktuell rund um die Projekte betrieben werden, umziehen, sofern sie als Docker-Image vorliegen. Ideen gibt es da auch bereits.