Wie man 40 Drupal-Seiten patcht, ohne 40 manuelle Bereitstellungen durchführen zu müssen

Standardisierung der Infrastruktur: automatisierte Updates für die Verwaltung mehrerer Standorte

Es gibt eine bestimmte Art von Update, die Drupal-Agenturen und Unternehmensteams fürchten: ein Sicherheitsupdate für etwas, auf dem die gesamte Flotte läuft – die PHP-Laufzeitumgebung, die Datenbank-Engine oder ein gemeinsam genutzter Dienst –, bei dem eine gepatchte Version bereits verfügbar ist und eine Frist gilt. Für ein Team, das eine einzelne Website verwaltet, ist die Umstellung auf die gepatchte Version eine Nachmittagsarbeit. Für ein Team, das 40 Drupal-Installationen über ein Kundenportfolio oder eine Tochtergesellschaftsstruktur hinweg verwaltet, ist es ein Wettlauf gegen die Zeit mit 40 manuellen Bereitstellungen, die noch erledigt werden müssen.

Am Ende des Tages sind die meisten Websites gepatcht. Ein paar nicht, weil unterwegs etwas schiefgelaufen ist und sie auf der Prioritätenliste nach hinten gerutscht sind. Diese wenigen Websites stehen ungepatcht in der queue – länger, als irgendjemand beabsichtigt hatte.

Das ist das Problem des Flottenmanagements. Es geht nicht um eine einzelne Website. Es geht darum, was passiert, wenn man den Aufwand für die Verwaltung einer Website mit der Anzahl der Websites in der Flotte multipliziert. Das gilt auch nicht nur für Drupal: Jede Flotte von Websites, die denselben Stack nutzt, stößt an dieselbe Grenze, egal ob es sich um Symfony, WordPress oder ein Node.js-Frontend handelt. Drupal ist hier nur das aktuelle Beispiel.

Warum manuelles Flottenmanagement nicht skalierbar ist

Das Wichtigste auf einen Blick: Manuelle Updates sind für eine einzelne Website in Ordnung. Bei einer Flotte steigt der Arbeitsaufwand linear mit der Anzahl der Websites, während sich das Risiko von Inkonsistenzen vervielfacht. Jeder Prozess, bei dem ein Mensch dieselbe Aktion 40 Mal wiederholen muss, führt irgendwann dazu, dass eine Website übersehen wird.

Der Standardansatz zur Verwaltung einer Flotte von Framework-Installationen ist im Grunde derselbe Prozess wie bei der Verwaltung einer einzelnen Installation – nur wiederholt. Sich bei jeder Website anmelden, das Update anwenden, die Bereitstellung überprüfen und zur nächsten übergehen. Bei einer Flotte von zehn Websites ist das mühsam. Bei einer Flotte von fünfzig beschäftigt das jemanden tagelang. Bei einer Flotte von zweihundert ist es eine eigene Stelle.

Die Wiederholung ist nicht nur kostspielig, sondern in besonderer Weise fehleranfällig. Manuelle Prozesse, die in großem Maßstab angewendet werden, führen zu inkonsistenten Ergebnissen – nicht, weil jemand nachlässig ist, sondern weil Menschen nicht in der Lage sind, genau dieselbe Vorgehensweise in Dutzenden von Umgebungen identisch anzuwenden. Eine Website erhält eine leicht abweichende Konfiguration. Eine andere wird bei einer fehlgeschlagenen Bereitstellung übersprungen, ohne dass ein erneuter Versuch unternommen wurde. Eine dritte wird mit einer anderen PHP-Version aktualisiert, weil die zuständige Person die Konfigurationsdatei nicht überprüft hat.

Die Flotte startet identisch. Mit der Zeit driftet sie auseinander. Websites, die vor sechs Monaten aus derselben Vorlage gestartet wurden, laufen mit unterschiedlichen PHP-Versionen, unterschiedlichen Service-Versionen und unterschiedlichen Infrastrukturkonfigurationen. Die Abweichungen sind unsichtbar, bis etwas kaputtgeht – und dann muss der Debugging-Prozess berücksichtigen, dass die defekte Website möglicherweise nicht mit der funktionierenden übereinstimmt.

Versionsdrift: das sich verschärfende Problem

Das Wichtigste auf einen Blick: Versionsdrift innerhalb einer Website-Flotte ist nicht nur ein Wartungsproblem. Sie stellt eine Sicherheitslücke dar und erschwert die Fehlerbehebung. Eine Website-Flotte, in der jede Seite mit derselben Konfiguration läuft, lässt sich grundsätzlich einfacher absichern und betreuen als eine, in der sich jede Seite geringfügig unterscheidet.

Versionsabweichungen werden oft als kosmetisches Problem abgetan – etwas, das man irgendwann mal in Ordnung bringen muss, wenn Zeit ist. Tatsächlich handelt es sich aber um ein Sicherheits- und Betriebsrisiko, das umso teurer wird, je länger es besteht.

Aus Sicherheitssicht weist eine Flotte mit uneinheitlichen Patch-Ständen eine uneinheitliche Angriffsfläche auf. Eine Schwachstelle, die auf 38 deiner 40 Drupal-Websites gepatcht wurde, ist immer noch eine offene Schwachstelle, da die beiden ungepatchten Websites echte Angriffsziele darstellen. Die Sicherheit der Flotte ist nur so stark wie die am wenigsten gepatchte Website.

Aus Support-Sicht bedeutet eine Website-Flotte, in der jede Seite leicht unterschiedlich ist, dass eine Lösung, die für eine Seite funktioniert, für eine andere möglicherweise nicht funktioniert. Um ein gemeldetes Problem zu beheben, muss zunächst festgestellt werden, was auf dieser bestimmten Seite tatsächlich läuft – was sich von dem unterscheiden kann, was du für den Fall hältst, da die Konfigurationsdatei zwar vor sechs Monaten aktualisiert wurde, diese bestimmte Seite aber nicht in diesem Bereitstellungsbatch enthalten war.

Die einzige nachhaltige Antwort auf Versionsdrift besteht darin, sie strukturell überflüssig zu machen: nicht durch strengere Disziplin bei manuellen Updates, sondern indem man manuelle Updates von vornherein überflüssig macht.

Wie Automatisierung tatsächlich aussieht

Das Wichtigste auf einen Blick: Flottenautomatisierung ist kein Projekt zur Entwicklung benutzerdefinierter Tools. Es geht darum, die Plattform-API und eine versionsverwaltete Konfigurationsdatei gemeinsam zu nutzen: Die Konfiguration legt fest, was auf jeder Website laufen soll, und die API wendet diese Definition auf die gesamte Flotte an, ohne dass ein Eingriff auf jeder einzelnen Website erforderlich ist.

Upsun ist eine Platform-as-a-Service, die die Infrastruktur-Ebene deines Anwendungsstacks verwaltet, damit dein Team das nicht tun muss. Für das Flottenmanagement bedeutet das, eine gemeinsame Konfigurationsdatei mit der Upsun-API zu kombinieren, um Änderungen automatisch auf alle Websites der Flotte zu übertragen.

Die Konfigurationsdatei definiert den Zielzustand für jeden Standort. Eine Drupal-Flottenkonfiguration könnte etwa so aussehen:

applications:
  drupal:
    type: php:8.3                          # change this once to update the whole fleet
    variables:
      env:
        DRUPAL_HASH_SALT: "change-per-site" # overridden at the project level per site
    relationships:
      database:
        service: db
        endpoint: mysql
      cache:
        service: redis
        endpoint: redis

services:
  db:
    type: mariadb:10.11                    # platform manages patching within this version
  redis:
    type: redis:7.2

Wenn PHP 8.3 auf 8.4 aktualisiert werden muss oder MariaDB ein Versions-Update benötigt, erfolgt diese Änderung in der Konfigurationsdatei. Eine Änderung, ein Commit, eine Code-Prüfung. Anschließend durchläuft ein Skript jedes Projekt in der Flotte und löst eine Bereitstellung aus:

import requests

API_TOKEN = "your-api-token"
FLEET_PROJECT_IDS = ["project-1", "project-2", "project-3"]  # or fetched dynamically via API

# Exchange the API token for a short-lived access token (valid ~15 minutes)
auth = requests.post(
    "https://auth.upsun.com/oauth2/token",
    auth=("platform-api-user", ""),
    data={"grant_type": "api_token", "api_token": API_TOKEN},
)
access_token = auth.json()["access_token"]

for project_id in FLEET_PROJECT_IDS:
    response = requests.post(
        f"https://api.upsun.com/projects/{project_id}/environments/main/redeploy",
        headers={"Authorization": f"Bearer {access_token}"},
    )
    if response.status_code in (200, 201, 202):
        print(f"{project_id}: redeploy triggered")
    else:
        print(f"{project_id}: redeploy failed - {response.status_code}")

Das Skript konfiguriert nichts. Die Konfigurationsdatei definiert bereits den Zielzustand. Das Skript weist lediglich jedes Projekt an, diesen anzuwenden. Jede Neubereitstellung wird unabhängig ausgelöst, sodass kein Projekt auf ein anderes warten muss, und die Ausgabe liefert dir einen klaren Überblick darüber, welche Projekte erfolgreich waren und welche noch Aufmerksamkeit erfordern.

So sieht Flottenmanagement aus, wenn es kein manueller Prozess ist. Der Aktualisierungszyklus lautet: Konfigurationsdatei ändern, committen und das Skript ausführen. Der menschliche Aufwand liegt in der Entscheidung, was geändert werden soll, nicht darin, die Änderung 40 Mal anzuwenden.

Was eine einheitliche Flotte ermöglicht

Das Wichtigste auf einen Blick: Eine Flotte, bei der bekannt ist, dass auf jedem Standort genau das läuft, was in der Konfigurationsdatei steht, beseitigt eine ganze Kategorie von Unsicherheiten in den Bereichen Betrieb, Support und Sicherheit. Du fragst dich nicht mehr „Was läuft auf diesem Standort?“, sondern weißt es einfach.

Die betrieblichen Vorteile einer einheitlichen Flotte gehen über die Zeitersparnis bei Updates hinaus.

Der Support wird schneller, da jede Website in der Flotte eine bekannte Konfiguration aufweist. Wenn ein Kunde ein Problem meldet, feilst du an der Anwendung, nicht an der Umgebung. Die Umgebung ist identisch mit jeder anderen Umgebung in der Flotte.

Die Sicherheit wird überprüfbar. „Alle Standorte laufen unter PHP 8.3.x mit der MariaDB 10.11-Service-Schicht“ ist eine Aussage, die du treffen und verifizieren kannst, da die Konfigurationsdatei versionsverwaltet ist und die API-Bereitstellungsprotokolle bestätigen, welche Projekte welche Version davon ausführen.

Die Einbindung einer neuen Tochtergesellschaft oder eines neuen Kundenstandorts in die Flotte ist unkompliziert. Die Konfigurationsdatei forken, die standortspezifischen Variablen anpassen (Datenbank-Anmeldedaten, standortspezifische Konfiguration), bereitstellen. Der neue Standort startet mit derselben Ausgangsbasis wie jeder andere Standort in der Flotte.

Und wenn an einem Freitagnachmittag eine kritische Sicherheitswarnung für eine Laufzeitumgebung oder einen Dienst eintrifft, von dem die Flotte abhängt, lautet die Vorgehensweise: Konfigurationsdatei aktualisieren, Skript ausführen, Ausgabe überprüfen. Keine 40 manuellen Bereitstellungen.

Verwaltest du eine Flotte bereits manuell?

Der Ansatz mit der Konfigurationsdatei erfordert nicht, dass bestehende Standorte von Grund auf neu aufgebaut werden. Die Konfiguration beschreibt den Zielzustand, daher besteht die Migration lediglich darin, aufzuschreiben, was an jedem Standort bereits läuft: die PHP-Version, die Dienste, die Beziehungen zwischen ihnen. Beginne mit einem Standort als Vorlage, überprüfe, ob er in der Produktivumgebung übereinstimmt, und erweitere das Konzept dann auf den Rest der Flotte. Die Flotte beginnt sich ab dem ersten Standort, der umgestellt wird, anzugleichen.

Häufig gestellte Fragen (FAQ)

Müssen alle Websites in der Flotte identisch sein?

Die Konfigurationsdatei definiert die gemeinsame Basis: Laufzeitversion, Dienstversionen und Infrastrukturkonfiguration. Website-spezifische Variablen (Datenbank-Anmeldedaten, umgebungsspezifische Einstellungen, benutzerdefinierte Domains) werden pro Projekt separat konfiguriert und überschreiben oder erweitern die Basiskonfiguration. Die Flotte kann eine gemeinsame Infrastrukturdefinition nutzen, während jede Website unabhängig konfigurierbar bleibt.

Wie verwalten wir die Konfigurationsdatei in einer großen Flotte ohne Monorepo?

Ein gängiges Muster ist ein eigenes „Flottenvorlagen“-Repo, das die gemeinsame Konfigurationsdatei enthält. Die Repos der einzelnen Standorte beziehen diese Vorlage oder verweisen darauf. Wenn die Vorlage aktualisiert wird, kann eine CI-Pipeline alle registrierten Flottenprojekte durchlaufen und über die API Deployments auslösen. Die Plattform-API unterstützt dieses Muster direkt.

Was passiert, wenn ein Deployment an einem Standort mitten in einer Flottenaktualisierung fehlschlägt?

Der Skript-Ansatz bedeutet, dass jede Bereitstellung unabhängig ist. Ein Fehler bei einem Projekt blockiert die anderen nicht. Die Skript-Ausgabe zeigt dir an, welche Projekte erfolgreich waren und welche fehlgeschlagen sind, sodass du eine klare Liste hast, um es erneut zu versuchen oder zu untersuchen, anstatt herausfinden zu müssen, welche Standorte erreicht wurden und welche nicht.

Können wir ein Flotten-Update rückgängig machen, wenn etwas schiefgeht?

Ja. Da die Konfigurationsdatei versionsverwaltet ist, bedeutet ein Rollback, den Commit rückgängig zu machen und die Bereitstellung erneut durchzuführen. Upsun verwaltet außerdem den Bereitstellungsverlauf pro Umgebung, sodass einzelne Umgebungen bei Bedarf über die Plattform zurückgesetzt werden können.

Wie gehen wir mit Websites um, die aus triftigen Gründen eine andere Konfiguration benötigen als der Rest der Flotte?

Ausnahmen werden auf Projektebene behandelt. Eine Website, die PHP 8.2 benötigt, während die Flotte auf 8.3 standardisiert ist, kann dies in ihrer eigenen Konfigurationsdatei festlegen, die dann Vorrang hat. Das Muster lautet: gemeinsame Vorlage für die Flotten-Baseline, projektbezogene Überschreibungen für begründete Ausnahmen. Der entscheidende Unterschied zu einem vollständig manuellen Ansatz besteht darin, dass Ausnahmen explizit und dokumentiert sind und nicht zufällig entstehen.