NexTool Solutions

GLPI in Docker zu aktualisieren wirkt trivial – Image-Tag tauschen und den Container starten –, doch gerade diese scheinbare Einfachheit verursacht ungeplante Ausfallzeiten. Beim Betrieb von Kundenumgebungen entstehen die meisten Update-Vorfälle nicht durch die Datenbankmigration selbst, sondern durch inkompatible Plugins, das im neuen Image enthaltene PHP oder ein falsch gemapptes Volume, durch das GLPI die Datenbankkonfiguration verliert. Dieser Leitfaden fasst den Ablauf zusammen, den wir in der Produktion anwenden, mit den Stellen, an denen es wirklich bricht.

Bevor Sie einen Container anfassen: die Kompatibilitätsinventur

Ein GLPI-Update ist nicht nur das Image. Es sind drei Schichten, die gemeinsam hochgezogen werden müssen: der Core, die Plugins und das Datenbankschema. Der klassische Fehler ist, das Image zu aktualisieren und bei ausgefallener Seite festzustellen, dass ein kritisches Plugin (zum Beispiel das native Inventar, ein SSO oder eine Feldanpassung) keine Version für den neuen Core hat. Erheben Sie vorher Folgendes:

• Exakte Ausgangs- und Zielversion – ein Minor-Sprung (10.0.15 auf 10.0.18) ist sicher; ein Major-Sprung (10.x auf 11.x) ändert die PHP-Anforderung und kann Plugins ausmustern.
• Plugin-Matrix – für jedes installierte Plugin bestätigen, dass ein mit dem Ziel kompatibles Release existiert. Ein Plugin ohne kompatible Version ist eine geschäftliche Entscheidung (deaktivieren, ersetzen oder das Upgrade verschieben), nie eine Überraschung um 2 Uhr morgens.
• Im Image enthaltenes PHP – das offizielle Image bringt bereits das richtige PHP mit, doch wenn Sie ein eigenes Image verwenden (Alpine + php-fpm), verlangt GLPI 11 PHP 8.2+. Ein neuer Core auf altem PHP ergibt einen weißen Bildschirm ohne klares Log.
• Speicherplatz – Dump und Tar der Volumes können die Belegung vorübergehend verdoppeln. Prüfen Sie das vorher, nicht währenddessen.

Entscheidungsmatrix: Minor, Major oder Versionen überspringen

Die Art des Sprungs bestimmt den Ablauf. Mit dieser Matrix bemessen wir Wartungsfenster und Risiko:

Der häufige Fehler hier ist die Annahme, das Überspringen von Versionen spare Zeit. GLPI garantiert keine Schemamigration über eine komplette Major-Version hinweg; die Routine db:update erwartet die Struktur der unmittelbar vorherigen Version. Wer von 9.5 direkt auf 11 springt, bringt die Migration meist mittendrin zum Stillstand, mit der Datenbank in inkonsistentem Zustand – und dann ist der Rollback nicht mehr optional.

Das Update Schritt für Schritt

1. Konsistentes Backup (Datenbank + Volumes)

Ein Backup ist nicht der Dump allein. Es ist der Datenbank-Dump plus das Tar der Datei-Volumes (Uploads, Dokumente, Plugin-Cache). Beide müssen vom selben Zeitpunkt stammen – deshalb stoppen wir zuerst die Anwendung und lassen nur die Datenbank für den Dump laufen:

# Stop the app, keep the database running
docker compose stop glpi-app

# Database dump (dedicated user, password via environment variable)
docker exec glpi-db sh -c 'mysqldump --single-transaction \
  -u glpi -p"${MYSQL_PASSWORD}" glpi' | gzip > /backup/pre-update-$(date +%F).sql.gz

# Tar of the GLPI file volumes
tar -czf /backup/pre-update-files-$(date +%F).tar.gz \
  /var/lib/docker/volumes/glpi_files/_data

--single-transaction garantiert einen konsistenten Dump, ohne die InnoDB-Tabellen zu sperren. Und setzen Sie das Passwort niemals im Klartext in die Kommandozeile: Es landet in der Shell-Historie und in docker inspect.

2. Die Zielversion im Compose festschreiben

Verwenden Sie in der Produktion nie den Tag latest. Er verschiebt das Ziel ohne Vorwarnung und verhindert einen deterministischen Rollback. Legen Sie die exakte Version fest:

# docker-compose.yml
services:
  glpi-app:
    # From:
    image: glpi/glpi:10.0.18
    # To (exact target version, never :latest):
    image: glpi/glpi:11.0.1
    volumes:
      - glpi_files:/var/glpi/files
      - glpi_config:/var/glpi/config   # config_db.php lives here - do NOT lose it

3. Das neue Image starten

docker compose pull glpi-app
docker compose up -d glpi-app

4. Die Schemamigration ausführen

Der Migrationsbefehl hat zwischen GLPI-Generationen den Namen gewechselt. Prüfen Sie, welcher Befehl verfügbar ist, bevor Sie blind loslegen:

# GLPI 10/11 (Symfony console):
docker exec -u www-data glpi-app php bin/console db:update --no-interaction

# Older GLPI (early 10.0) used:
# docker exec -u www-data glpi-app php bin/console glpi:database:update --no-interaction

Führen Sie ihn immer als Benutzer des Webservers aus (www-data oder apache), nie als root. Läuft die Migration als root, entstehen Cache-Dateien mit falschem Eigentümer, und GLPI meldet danach Berechtigungsfehler – ein falsches „beim Update kaputtgegangen“, das nur ein Ownership-Problem ist.

5. Cache leeren und validieren

docker exec -u www-data glpi-app php bin/console cache:clear

• Öffnen Sie die Oberfläche und prüfen Sie die Version unter Einrichtung > Allgemein.
• Führen Sie die interne Diagnose unter Einrichtung > Prüfungen aus (prüft PHP, Erweiterungen und Berechtigungen).
• Bestätigen Sie, dass die kritischen Plugins als aktiv erscheinen und nicht als „muss aktualisiert werden“.
• Testen Sie einen echten Ablauf: ein Ticket erstellen, ein Dokument anhängen, eine Benachrichtigung auslösen.

Was wir im Betrieb für Kunden gelernt haben

Im Betrieb ist der häufigste Vorfall nicht, dass die Migration fehlschlägt – sondern dass sie scheinbar geklappt hat und GLPI mit der leeren Standarddatenbank startet. Die Ursache ist fast immer dieselbe: Das Volume mit config/config_db.php wurde nicht gemappt oder in der neuen Version auf einen anderen Pfad gemappt. GLPI findet die Datenbankkonfiguration nicht, nimmt eine Neuinstallation an und zeigt den Installationsassistenten. Wer es eilig hat, klickt auf „Installieren“ und legt eine neue Datenbank darüber an – nun besteht zusätzlich zur Ausfallzeit das Risiko eines Datenverlusts. Deshalb ist in unserer Checkliste die erste Prüfung nach dem Start nicht die Version, sondern dass docker exec glpi-app cat /var/glpi/config/config_db.php die tatsächliche Konfiguration des Kunden zurückgibt. Erscheint der Assistent, stoppen wir alles vor jedem Klick und prüfen das Volume-Mapping – wir machen nie über die Oberfläche weiter.

Das zweite Muster ist OPcache, der nach dem Upgrade alten Code ausliefert. Das Image wurde getauscht, der Code auf der Festplatte ist neu, aber php-fpm hat noch die alte Version kompiliert im Speicher. Symptom: Fehler zu nicht existierenden Methoden oder eine Core-Version, die nicht zum Image passt. Den Container neu zu erstellen (und nicht nur neu zu starten) behebt das, weil der php-fpm-Prozess von Grund auf neu initialisiert wird.

Rollback-Plan (geprobt, nicht improvisiert)

Ein Rollback ist nur verlässlich, wenn er vorher durchdacht wurde. Mit Dump und Tar aus Schritt 1 ist die Rückkehr deterministisch:

# Tear down the new version
docker compose down

# Restore the database from the dump
gunzip < /backup/pre-update-2026-07-02.sql.gz \
  | docker exec -i glpi-db sh -c 'mysql -u glpi -p"${MYSQL_PASSWORD}" glpi'

# Revert the image tag in docker-compose.yml to the previous version
# (e.g. glpi/glpi:11.0.1 back to glpi/glpi:10.0.18)

docker compose up -d

Kritischer Punkt beim Rollback: das Schema. Sobald db:update die Struktur geändert hat, ist die Datenbank nicht mehr mit dem alten Image kompatibel. Deshalb muss der Rollback den Dump wiederherstellen – den Tag zurückzusetzen reicht nicht. Nur das Image zurückzusetzen, mit bereits migriertem Schema, lässt das alte GLPI Tabellen einer künftigen Struktur lesen, was stille und schwer nachvollziehbare Fehler erzeugt.

So gelingt es ohne ungeplante Ausfallzeit

Ist die Umgebung kritisch, muss das Wartungsfenster in einer Testumgebung mit einem Klon der Produktionsdatenbank geprobt werden. Dort stellt sich ohne Druck heraus, ob ein Plugin bricht oder ob die Migration länger dauert als das vereinbarte Fenster. Ohne diese Probe direkt in der Produktion zu aktualisieren heißt, die Verfügbarkeit des Kunden auf Glück zu setzen.

Wenn Ihr Team keine Zeit hat, jedes Upgrade zu proben, oder schon einmal ein Update erlebt hat, das bis in die Nacht ging, übernimmt NexTool den Betrieb und die Updates Ihres GLPI mit geprobtem Rollback und vereinbartem Wartungsfenster. Sprechen Sie mit uns über GLPI-Support und -Betrieb.

Geprüft vom Team von NexTool Solutions.