Docker ist kein Trend mehr, sondern die Standardmethode, mit der wir GLPI für Kunden ausliefern und betreuen. Statt PHP, MariaDB und Webserver direkt auf dem Betriebssystem zu installieren, verpacken wir GLPI und seine Abhängigkeiten in versionierte Container – damit wird die Installation reproduzierbar, ein Rollback trivial und die Wartung planbar. Dieser Leitfaden fasst die Befehle zusammen, die wir im Betriebsalltag wirklich verwenden, und die Praktiken, mit denen wir einen Service Desk sicher produktiv betreiben.
Wie wir GLPI in Docker betreiben
Unsere Standardarchitektur ist bewusst schlank: ein Container für die GLPI-Anwendung (PHP-FPM und Webserver), einer für die MariaDB-Datenbank und, wenn es das Ticketvolumen rechtfertigt, ein Redis für Sessions und Cache. Alles wird über eine einzige docker-compose.yml orchestriert, hinter einem Reverse Proxy mit TLS. Daten, die jede Neuerstellung eines Containers überstehen müssen – Datenbank, hochgeladene Dateien und Konfiguration –, liegen in benannten Volumes, nie im Container. Diese Trennung zwischen Code (dem Image, austauschbar) und Zustand (dem Volume, wertvoll) macht aus einem Versionsupdate von GLPI einen Vorgang von Minuten statt einer durchgearbeiteten Nacht.
Artefakt: der GLPI-Stack, den wir bereitstellen
Dies ist ein Grundgerüst der Compose-Datei, die bei jeder Einführung zum Einsatz kommt, bereits mit getrennten Volumes und ohne Zugangsdaten im Klartext in der Datei:
# docker-compose.yml - stack GLPI de producao
services:
glpi:
image: glpi/glpi:11.0 # tag fixa, nunca 'latest'
restart: unless-stopped
depends_on:
- glpidb
volumes:
- glpi_files:/var/glpi # arquivos enviados e configuracao do GLPI
networks: [ edge, internal ]
glpidb:
image: mariadb:11.4
restart: unless-stopped
environment:
MARIADB_DATABASE: glpi
MARIADB_USER: glpi
MARIADB_PASSWORD_FILE: /run/secrets/db_password # senha via secret, nunca em texto plano
volumes:
- glpi_db:/var/lib/mysql # o banco vive aqui, fora do container
networks: [ internal ]
secrets: [ db_password ]
volumes:
glpi_files:
glpi_db:
networks:
edge: # exposta ao reverse proxy
internal: # banco privado, sem rota externa
internal: true
secrets:
db_password:
file: ./secrets/db_password.txt # arquivo 600, fora do git
Die Befehle, die wir im Betrieb wirklich verwenden
Im Support-Alltag lösen wenige Befehle die meisten Eingriffe. Diese tippt unser Team fast ohne nachzudenken:
| Befehl | Wann wir ihn im GLPI-Betrieb einsetzen |
|---|---|
docker compose up -d | Startet oder aktualisiert den Stack nach einer Änderung an der Compose-Datei oder am Image-Tag |
docker compose logs -f glpi | Verfolgt den Fehler eines Tickets in Echtzeit, wenn ein Kunde einen Ausfall meldet |
docker compose exec glpi bash | Öffnet eine Shell im Container, um php bin/console auszuführen (Cron, Cache, Migration) |
docker compose ps | Prüft, ob Anwendung und Datenbank laufen, bevor eine Störung eröffnet wird |
docker stats | Diagnostiziert CPU- und Speicherspitzen, wenn über Langsamkeit geklagt wird |
docker compose down (ohne -v) | Erstellt den Stack neu und behält die Volumes; -v würde die Datenbank löschen |
Der häufige – und teure – Fehler, den wir bei unvorsichtigem Betrieb schon gesehen haben: docker compose down -v auszuführen in der Annahme, die Container würden nur neu gestartet. Flag -v entfernt die Volumes und mit ihnen die gesamte GLPI-Datenbank. Im Betrieb behandeln wir -v als destruktiven Befehl: Er taucht in keinem Betriebsverfahren auf, und jedes Volume-Backup wird validiert, bevor eine Wartung auch nur in seine Nähe kommt.
Best Practices, die wir im Produktivbetrieb anwenden
- Fester Tag, niemals
latest– Wir fixieren die Image-Version (z. B.glpi/glpi:11.0,mariadb:11.4), damit einpullmitten in einer Wartung keine unerwartete Version mitbringt. - Kein Root und minimale Rechte – Die Anwendung läuft nicht als root, und die Datenbank liegt im Netzwerk
internal, ohne externe Route, nur vom GLPI-Container aus erreichbar. - Secrets außerhalb der Compose-Datei – Ein Datenbankpasswort kommt per Docker Secret oder schreibgeschützt eingebundener Datei, niemals im Klartext in einer
environment:, die in Git committet wird. - Volumes sind heilig – Datenbank, Dateien und Konfiguration liegen in benannten Volumes, mit täglichem logischem Dump der Datenbank, getestet durch eine echte Wiederherstellung (ein Backup, welches nie wiederhergestellt wurde, ist kein Backup).
- Schlanke und gescannte Images – Slim-Basis und Scan mit Trivy oder Docker Scout, um keine bekannte CVE in Produktion zu bringen.
Ein Detail, welches nur kennt, wer GLPI in Containern betreut: Ein Versionsupdate von GLPI bedeutet nicht nur, den Image-Tag zu tauschen. Nach docker compose up -d mit dem neuen Image muss die Datenbankmigration über die Konsole im Container ausgeführt werden, sonst startet die Anwendung mit einem alten Schema und antwortet auf der ersten Seite mit Fehler 500. Deshalb folgt unser Update-Verfahren immer derselben Reihenfolge: Backup des Datenbank-Volumes, Tausch des Tags, up -d, Migration und erst dann Freigabe für die Benutzer. Nutzt ein Kunde Plugin NexTool, lädt dieser Start auch die Module des Ökosystems neu – daher prüfen wir zusätzlich den Zustand der Integrationen (Webhook-Warteschlangen, Synchronisierung), bevor wir eine Umgebung als stabil freigeben.
Wenn Ihr GLPI-Betrieb noch direkt auf dem Server installiert läuft, ohne getrennte Volumes und ohne getestetes Backup, führt NexTool diese Umgebung richtig in Docker ein und betreut sie – mit versioniertem Stack, planbaren Updates und Observability neben Ihrem Service Desk. Sprechen Sie mit uns über den Betrieb von GLPI in Containern.
Geprüft vom Team von NexTool Solutions.
