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 contient | Le perdre signifie |
|---|---|---|
| /opt/glpi/db - /var/lib/mysql | Toute la base de données | Perdre tous les tickets et actifs |
| /opt/glpi/config - /etc/glpi | config_db.php, clé de chiffrement, local_define | GLPI revient en demandant une réinstallation |
| /opt/glpi/data - /var/lib/glpi | Fichiers, dumps, sessions, dépôts | Perdre pièces jointes et sessions actives |
| /opt/glpi/plugins - .../plugins | Plugins installés manuellement | Réinstaller plugin par plugin |
| /opt/glpi/marketplace - .../marketplace | Plugins téléchargés du Marketplace | Reté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/dbet/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.