Comment installer GLPI 11 avec Docker : le guide définitif

Pas à pas pour installer GLPI 11 avec Docker Compose : les cinq volumes à persister, les secrets dans .env, l'installation par console, le proxy inverse avec SSL et la correction de la classique erreur du crontab dans le conteneur. Plus le piège qui fait le plus tomber GLPI : recréer le conteneur sans persister /etc/glpi.

Docker est la façon la plus rapide et reproductible de démarrer GLPI 11. En moins de 10 minutes, vous avez MariaDB, des volumes persistants et un environnement prêt pour la production. Mais la différence entre un labo que vous jetez et un GLPI qui survit à un docker compose up -d --force-recreate tient à une seule chose : quelles données vous avez persistées. En maintenance, c'est toujours ce qui sépare "j'ai recréé le conteneur" de "j'ai perdu GLPI".

Prérequis

  • Serveur Linux (Debian 12, Ubuntu 22.04+ ou AlmaLinux 9).
  • Docker Engine 24+ et Docker Compose v2.
  • Minimum 2 Go de RAM et 20 Go de disque.
  • Domaine pointant vers le serveur (nécessaire pour le SSL).

1. Les cinq volumes qui décident de tout

Avant le compose, comprenez ce qui doit survivre au cycle de vie du conteneur. Ce sont les chemins que nous persistons sur chaque GLPI en Docker que nous montons :

Volume (hôte - conteneur)Ce qu'il contientLe perdre signifie
/opt/glpi/db - /var/lib/mysqlToute la base de donnéesPerdre tous les tickets et actifs
/opt/glpi/config - /etc/glpiconfig_db.php, clé de chiffrement, local_defineGLPI revient en demandant une réinstallation
/opt/glpi/data - /var/lib/glpiFichiers, dumps, sessions, dépôtsPerdre pièces jointes et sessions actives
/opt/glpi/plugins - .../pluginsPlugins installés manuellementRéinstaller plugin par plugin
/opt/glpi/marketplace - .../marketplacePlugins téléchargés du MarketplaceRetélécharger tout depuis le Marketplace

Créez l'arborescence :

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

2. Secrets dans .env, jamais dans le compose

Un mot de passe en dur dans docker-compose.yml finit versionné dans un git un jour. Isolez les secrets dans un .env à côté du compose et ne versionnez pas ce fichier :

# .env - a cote du compose et ne va PAS dans git
MARIADB_ROOT_PASSWORD=remplacez-par-un-mot-de-passe-fort
MARIADB_PASSWORD=remplacez-par-un-autre-mot-de-passe-fort

3. docker-compose.yml

Notez deux précautions : la version de MariaDB est figée (jamais latest, qui peut sauter un major et casser) et les mots de passe viennent du .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

Remarquez que le port est publié sur 127.0.0.1:8080, pas sur 0.0.0.0 : ce qui parle à Internet, c'est le proxy inverse, pas le conteneur.

4. Démarrer et installer par la console

Lancez les services et attendez l'initialisation de la base :

docker compose up -d
docker compose logs -f glpi

Au lieu de l'assistant web, installez en CLI - c'est reproductible et supprime l'étape manuelle du navigateur :

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=fr_FR --no-interaction

Puis retirez l'installeur par sécurité :

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

5. Le cron : l'erreur du crontab dans le conteneur

Ici vit le piège que nous voyons le plus sur le terrain. Une consigne courante est "lancez crontab dans le conteneur", mais l'image GLPI est éphémère : un crontab écrit là-dedans meurt au prochain up -d. Et GLPI 11 n'en dépend même pas - le déclenchement automatique se fait en appelant le cron en ligne de commande. La façon durable est de planifier sur l'hôte, en appelant le conteneur :

# crontab de l'hote - declenche le cron GLPI chaque minute
* * * * * docker exec -u www-data glpi-app php /var/www/glpi/front/cron.php >/dev/null 2>&1

Avec le cron sur l'hôte, la planification survit aux recréations du conteneur. Le symptôme de l'oubli est classique : notifications qui ne partent pas, SLA qui n'escalade pas et une file "bloquée" sans raison apparente - tout cela parce que les tâches automatiques ne tournent jamais.

6. Proxy inverse avec SSL

En production, n'exposez jamais GLPI directement sur le port 80. Placez devant un proxy inverse (Nginx Proxy Manager, Traefik ou Nginx manuel) avec un certificat valide :

server {
    listen 443 ssl;
    http2 on;
    server_name glpi.votreentreprise.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. Premier accès et mots de passe par défaut

Ouvrez https://glpi.votreentreprise.com et connectez-vous avec les comptes par défaut : glpi/glpi (admin), tech/tech, normal/normal et post-only/postonly. Changez ou désactivez-les tous immédiatement - ces identifiants sont de notoriété publique et un scanner du premier jour les teste déjà.

Le piège qui fait le plus tomber GLPI en Docker

En maintenance, l'incident numéro un avec GLPI en Docker n'est pas la base : c'est recréer le conteneur sans persister /etc/glpi. Quand cela arrive, GLPI perd config_db.php et revient à l'écran d'installation comme si c'était la première fois - avec la base intacte à côté. L'utilisateur jure que "Docker a effacé GLPI" ; en réalité le conteneur ne sait plus où est la base. C'est pourquoi, avant tout up -d --force-recreate, notre checklist vérifie que les cinq volumes du tableau sont montés. C'est une minute qui évite un dimanche de récupération.

Bonnes pratiques pour la production

  • Sauvegarde automatique de /opt/glpi/db et /opt/glpi/data (la base et les pièces jointes).
  • Figez les tags des images (base et GLPI) ; mettez à jour consciemment, jamais via latest.
  • Configurez le SMTP pour les notifications et confirmez que le cron de l'hôte tourne.
  • Installez les plugins via le Marketplace (Configuration > Plugins) et vérifiez qu'ils tombent dans le volume persisté.

Étape suivante

GLPI en ligne, configurez SLA et OLA, montez le catalogue de services et évaluez les modules NexTool. Si vous préférez le faire maintenir par ceux qui en font tous les jours, parlez à l'équipe.


Ce contenu a été produit avec l'aide de l'intelligence artificielle et revu par l'équipe Nextool Solutions.

Questions fréquentes

Oui. Il existe des images officielles sur Docker Hub basées sur AlmaLinux, prenant en charge GLPI 10 et 11. Figez un tag précis (par exemple 11.0) au lieu de latest pour ne pas subir un saut de version par accident.

Oui, et c'est la façon recommandée : cela facilite les mises à jour, les sauvegardes et la reproductibilité. Les exigences sont des volumes persistants pour la base, les fichiers et la configuration, du SSL via proxy inverse, et le cron planifié sur l'hôte, pas dans le conteneur.

GLPI 11 exige une version récente de PHP (la série 8.x). L'image Docker officielle embarque déjà la bonne version, vous n'avez donc pas à installer ni maintenir PHP sur l'hôte - un des avantages du conteneur.

Presque toujours parce que le répertoire de configuration (/etc/glpi, qui contient config_db.php) n'a pas été persisté dans un volume. À la recréation, GLPI perd la référence de la base et retombe sur l'écran d'installation, même avec la base intacte. Persistez les cinq volumes et le problème disparaît.

N'écrivez pas le crontab dans le conteneur, qui est éphémère. Planifiez sur l'hôte une ligne qui appelle le cron de GLPI dans le conteneur (docker exec ... front/cron.php) chaque minute. Ainsi la planification survit aux recréations et les notifications et escalades de SLA tournent à nouveau.

Besoin d'aide ?