NexTool Solutions

Docker ist der schnellste und am besten reproduzierbare Weg, GLPI 11 aufzusetzen. In weniger als 10 Minuten haben Sie MariaDB, persistente Volumes und eine produktionsreife Umgebung. Aber der Unterschied zwischen einem Labor, das Sie wegwerfen, und einem GLPI, der ein docker compose up -d --force-recreate übersteht, liegt in einer einzigen Sache: welche Daten Sie persistiert haben. Im Betrieb trennt genau dies „Ich habe den Container neu erstellt“ von „Ich habe GLPI verloren“.

Voraussetzungen

• Linux-Server (Debian 12, Ubuntu 22.04+ oder AlmaLinux 9).
• Docker Engine 24+ und Docker Compose v2.
• Mindestens 2 GB RAM und 20 GB Festplatte.
• Domain, die auf den Server zeigt (für SSL erforderlich).

1. Die fünf Volumes, die über alles entscheiden

Verstehen Sie vor der Compose-Datei, was den Lebenszyklus des Containers überdauern muss. Diese Pfade persistieren wir bei jedem GLPI in Docker, den wir aufsetzen:

Legen Sie die Verzeichnisstruktur an:

mkdir -p /opt/glpi/{data,config,plugins,marketplace,db}

2. Secrets in .env, nie in der Compose-Datei

Ein fest codiertes Passwort in docker-compose.yml landet eines Tages versioniert in irgendeinem Git. Isolieren Sie die Secrets in einer .env neben der Compose-Datei und versionieren Sie diese Datei nicht:

# .env - sits next to the compose and does NOT go to git
MARIADB_ROOT_PASSWORD=change-to-a-strong-password
MARIADB_PASSWORD=change-to-another-strong-password

3. docker-compose.yml

Beachten Sie zwei Vorsichtsmaßnahmen: Der Tag von MariaDB ist fixiert (nie latest, das eine Major-Version überspringen und etwas kaputt machen kann), und die Passwörter kommen aus der .env:

services:
  glpi-db:
    image: mariadb:10.11
    container_name: glpi-db
    restart: unless-stopped
    environment:
      MARIADB_ROOT_PASSWORD: ${MARIADB_ROOT_PASSWORD}
      MARIADB_DATABASE: glpi
      MARIADB_USER: glpi
      MARIADB_PASSWORD: ${MARIADB_PASSWORD}
    volumes:
      - /opt/glpi/db:/var/lib/mysql
    command: --character-set-server=utf8mb4 --collation-server=utf8mb4_unicode_ci

  glpi:
    image: glpi/glpi:11.0
    container_name: glpi-app
    restart: unless-stopped
    ports:
      - "127.0.0.1:8080:80"
    depends_on:
      - glpi-db
    volumes:
      - /opt/glpi/data:/var/lib/glpi
      - /opt/glpi/config:/etc/glpi
      - /opt/glpi/plugins:/var/www/glpi/plugins
      - /opt/glpi/marketplace:/var/www/glpi/marketplace

Beachten Sie, dass der Port auf 127.0.0.1:8080 veröffentlicht wird, nicht auf 0.0.0.0: Mit dem Internet spricht der Reverse Proxy, nicht der Container.

4. Starten und über die Konsole installieren

Starten Sie die Dienste und warten Sie, bis die Datenbank initialisiert ist:

docker compose up -d
docker compose logs -f glpi

Installieren Sie statt über den Web-Assistenten per CLI – reproduzierbar und ohne manuellen Schritt im Browser:

docker exec -it glpi-app php bin/console glpi:database:install --db-host=glpi-db --db-name=glpi --db-user=glpi --db-password="${MARIADB_PASSWORD}" --default-language=pt_BR --no-interaction

Entfernen Sie anschließend aus Sicherheitsgründen den Installer:

docker exec -it glpi-app rm -f /var/www/glpi/install/install.php

5. Der Cron: der Fehler mit crontab im Container

Hier liegt die Falle, die wir in der Praxis am häufigsten gesehen haben. Oft liest man die Anweisung „Führen Sie crontab im Container aus“, aber ein GLPI-Image ist flüchtig: Eine dort geschriebene crontab verschwindet beim nächsten up -d. Und GLPI 11 ist darauf gar nicht angewiesen – die automatische Auslösung erfolgt durch Aufruf des Crons über die Kommandozeile. Dauerhaft tragfähig ist es, den Job auf dem Host einzuplanen und den Container aufzurufen:

# host crontab - fires the GLPI cron every minute
* * * * * docker exec -u www-data glpi-app php /var/www/glpi/front/cron.php >/dev/null 2>&1

Mit dem Cron auf dem Host übersteht die Planung jede Neuerstellung des Containers. Wer dies vergisst, zeigt ein klassisches Symptom: Benachrichtigungen gehen nicht raus, SLAs eskalieren nicht und die Warteschlange „hängt“ ohne erkennbaren Grund – alles, weil die automatischen Aufgaben nie laufen.

6. Reverse Proxy mit SSL

Stellen Sie GLPI in der Produktion nie direkt auf Port 80 bereit. Setzen Sie einen Reverse Proxy (Nginx Proxy Manager, Traefik oder manuelles Nginx) mit gültigem Zertifikat davor:

server {
    listen 443 ssl;
    http2 on;
    server_name glpi.suaempresa.com;

    ssl_certificate     /etc/ssl/certs/glpi.crt;
    ssl_certificate_key /etc/ssl/private/glpi.key;

    location / {
        proxy_pass http://127.0.0.1:8080;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-Proto $scheme;
    }
}

7. Erster Zugriff und Standardpasswörter

Rufen Sie https://glpi.suaempresa.com auf und melden Sie sich mit den Standardkonten an: glpi/glpi (Admin), tech/tech, normal/normal und post-only/postonly. Ändern oder deaktivieren Sie alle sofort – diese Zugangsdaten sind öffentlich bekannt, und Scanner testen sie schon am ersten Tag.

Die Falle, an der GLPI in Docker am häufigsten scheitert

Im Betrieb ist der häufigste Vorfall mit GLPI in Docker nicht die Datenbank: Es ist die Neuerstellung des Containers, ohne /etc/glpi zu persistieren. Passiert dies, verliert GLPI die config_db.php und landet wieder auf dem Installationsbildschirm, als wäre es das erste Mal – während die Datenbank daneben intakt ist. Der Benutzer schwört, „Docker hat GLPI gelöscht“; in Wahrheit weiß der Container nur nicht mehr, wo die Datenbank liegt. Deshalb prüft unsere Checkliste vor jedem up -d --force-recreate, ob die fünf Volumes aus der Tabelle eingebunden sind. Eine Minute, die einen Sonntag mit Wiederherstellung erspart.

Bewährte Vorgehensweisen für die Produktion

• Automatisches Backup von /opt/glpi/db und /opt/glpi/data (Datenbank und Anhänge).
• Fixieren Sie den Tag der Images (Datenbank und GLPI); aktualisieren Sie bewusst, nie über latest.
• Konfigurieren Sie SMTP für die Benachrichtigungen und prüfen Sie, ob der Cron auf dem Host läuft.
• Installieren Sie Plugins über den Marketplace (Einrichtung > Plugins) und prüfen Sie, ob sie im persistierten Volume landen.

Nächster Schritt

Sobald GLPI läuft, konfigurieren Sie SLA und OLA, bauen den Servicekatalog auf und prüfen die Module von NexTool. Wenn Sie den Betrieb lieber Leuten überlassen, die dies jeden Tag tun, sprechen Sie mit dem Team.

Geprüft vom Team von NexTool Solutions.