Docker a cessé d'être une mode pour devenir la façon standard dont nous livrons et maintenons GLPI pour nos clients. Au lieu d'installer PHP, MariaDB et le serveur web directement sur le système d'exploitation, nous empaquetons GLPI et ses dépendances dans des conteneurs versionnés - ce qui rend l'installation reproductible, le rollback trivial et la maintenance prévisible. Ce guide rassemble les commandes que nous utilisons vraiment au quotidien en support et les pratiques que nous appliquons pour faire tourner le service desk en production en toute sécurité.
Comment nous faisons tourner GLPI sur Docker
L'architecture que nous standardisons est délibérément sobre : un conteneur pour l'application GLPI (PHP-FPM et serveur web), un pour la base de données MariaDB et, quand le volume de tickets le justifie, un Redis pour la session et le cache. Le tout orchestré par un unique docker-compose.yml, derrière un reverse proxy avec TLS. Les données qui doivent survivre à toute recréation de conteneur - base de données, fichiers téléversés et configuration - vivent dans des volumes nommés, jamais à l'intérieur du conteneur. Cette séparation entre le code (l'image, jetable) et l'état (le volume, précieux) est ce qui transforme une montée de version de GLPI en une opération de quelques minutes, et non en une nuit entière.
Artefact : le stack GLPI que nous provisionnons
Voici le squelette du compose que nous montons à chaque déploiement, déjà avec des volumes séparés et sans identifiant en clair dans le fichier :
# docker-compose.yml - stack GLPI de production
services:
glpi:
image: glpi/glpi:11.0 # tag fige, jamais 'latest'
restart: unless-stopped
depends_on:
- glpidb
volumes:
- glpi_files:/var/glpi # fichiers televerses et configuration de 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 # mot de passe via secret, jamais en clair
volumes:
- glpi_db:/var/lib/mysql # la base de donnees vit ici, hors du conteneur
networks: [ internal ]
secrets: [ db_password ]
volumes:
glpi_files:
glpi_db:
networks:
edge: # exposee au reverse proxy
internal: # base de donnees privee, sans route externe
internal: true
secrets:
db_password:
file: ./secrets/db_password.txt # fichier 600, hors git
Les commandes que nous utilisons vraiment en support
Au quotidien, une poignée de commandes résout la plupart des interventions. Voici celles que l'équipe tape presque sans réfléchir :
| Commande | Quand nous l'utilisons pour maintenir GLPI |
|---|---|
docker compose up -d | Monte ou met à jour le stack après un changement dans le compose ou le tag de l'image |
docker compose logs -f glpi | Suit l'erreur d'un ticket en temps réel quand le client signale une panne |
docker compose exec glpi bash | Entre dans le conteneur pour lancer php bin/console (cron, cache, migration) |
docker compose ps | Vérifie que l'application et la base sont en marche avant d'ouvrir un incident |
docker stats | Diagnostique les pics de CPU et de mémoire quand la plainte est la lenteur |
docker compose down (sans -v) | Recrée le stack en conservant les volumes ; le -v effacerait la base |
L'erreur courante - et coûteuse - que nous avons vue chez des opérateurs négligents est de lancer docker compose down -v en croyant que cela ne fait que redémarrer les conteneurs. Le drapeau -v supprime les volumes, et avec eux toute la base de données de GLPI. En support, nous traitons -v comme une commande destructrice : elle n'apparaît dans aucune procédure d'exploitation, et toute sauvegarde de volume est validée avant toute maintenance qui s'en approche.
Bonnes pratiques que nous appliquons en production
- Tag figé, jamais
latest- nous figeons la version de l'image (p. ex.glpi/glpi:11.0,mariadb:11.4) pour qu'unpulln'apporte pas une version inattendue au milieu d'une maintenance. - Non-root et moindre privilège - l'application ne tourne pas en root, et la base reste sur le réseau
internal, sans route externe, accessible seulement par le conteneur GLPI. - Secrets hors du compose - le mot de passe de la base arrive via un Docker secret ou un fichier monté en lecture seule, jamais dans
environment:en clair commité dans git. - Le volume est sacré - base, fichiers et configuration dans des volumes nommés, avec un dump logique quotidien de la base testé par une restauration réelle (une sauvegarde jamais restaurée n'est pas une sauvegarde).
- Images légères et scannées - une base slim et un scan avec Trivy ou Docker Scout pour ne pas emporter une CVE connue en production.
Un détail que seul celui qui maintient GLPI en conteneur connaît : monter la version de GLPI ne se limite pas à changer le tag de l'image. Après le docker compose up -d avec la nouvelle image, il faut lancer la migration de la base depuis la console à l'intérieur du conteneur, sinon l'application démarre en pointant vers un ancien schéma et renvoie une erreur 500 au premier écran. C'est pourquoi notre procédure de mise à jour enchaîne toujours le même ordre : sauvegarde du volume de la base, changement du tag, up -d, migration et seulement ensuite l'ouverture de l'accès aux utilisateurs. Quand le client utilise le plugin NexTool, ce même démarrage recharge les modules de l'écosystème - nous validons donc aussi la santé des intégrations (files de webhooks, synchronisation) avant de déclarer l'environnement stable.
Si votre exploitation de GLPI tourne encore installée directement sur le serveur, sans volumes séparés ni sauvegarde testée, NexTool déploie et maintient cet environnement sur Docker de la bonne manière - avec un stack versionné, des montées de version prévisibles et de l'observabilité à côté du service desk. Parlez-nous du support de GLPI sur conteneurs.
Ce contenu a été produit avec l'aide de l'intelligence artificielle et révisé par l'équipe Nextool Solutions.
