NexTool Solutions

Mettre à jour GLPI sur Docker paraît trivial - changer le tag de l'image et relancer le conteneur - mais c'est justement cette apparente simplicité qui génère des interruptions non planifiées. En maintenance d'environnements clients, la plupart des incidents de mise à jour ne viennent pas de la migration de la base elle-même, mais de plugins incompatibles, du PHP embarqué dans la nouvelle image, ou d'un volume mal mappé qui fait perdre à GLPI sa configuration de base de données. Ce guide consolide la procédure que nous appliquons en production, avec les points où les choses cassent réellement.

Avant de toucher au moindre conteneur : l'inventaire de compatibilité

Une mise à jour de GLPI, ce n'est pas seulement l'image. Ce sont trois couches qui doivent monter ensemble : le cœur, les plugins et le schéma de la base. L'erreur classique est de mettre à jour l'image et de découvrir, le site en panne, qu'un plugin critique (l'inventaire natif, un SSO, un champ personnalisé) n'a pas de version pour le nouveau cœur. Vérifiez ceci d'abord :

• Versions exactes de départ et de cible - un saut mineur (10.0.15 vers 10.0.18) est sûr ; un saut majeur (10.x vers 11.x) change le prérequis PHP et peut retirer des plugins.
• Matrice des plugins - pour chaque plugin installé, confirmer qu'une version compatible avec la cible existe. Un plugin sans version compatible est une décision métier (désactiver, remplacer ou reporter la mise à jour), jamais une surprise à 2h du matin.
• PHP embarqué dans l'image - l'image officielle embarque le bon PHP, mais si vous utilisez votre propre image (Alpine + php-fpm), GLPI 11 exige PHP 8.2+. Un cœur récent sur un PHP ancien donne une page blanche sans log clair.
• Espace disque - le dump et le tar des volumes peuvent temporairement doubler l'usage. Vérifiez avant, pas pendant.

Matrice de décision : mineur, majeur ou saut de versions

Le type de saut définit la procédure. Voici la matrice que nous utilisons pour dimensionner la fenêtre et le risque :

L'erreur courante ici est de croire que sauter des versions fait gagner du temps. GLPI ne garantit pas la migration de schéma en franchissant un majeur entier ; la routine db:update attend la structure de la version immédiatement précédente. Sauter de 9.5 directement à 11 bloque souvent la migration en cours de route, avec la base dans un état incohérent - et là le rollback cesse d'être optionnel.

Mise à jour pas à pas

1. Sauvegarde cohérente (base + volumes)

Une sauvegarde, ce n'est pas le dump seul. C'est le dump de la base plus le tar des volumes de fichiers (téléversements, documents, cache des plugins). Les deux doivent dater du même instant - c'est pourquoi nous arrêtons l'application d'abord, en laissant seulement la base debout pour le dump :

# Arrête l'app, garde la base debout
docker compose stop glpi-app

# Dump de la base (utilisateur dédié, mot de passe via variable d'environnement)
docker exec glpi-db sh -c 'mysqldump --single-transaction \
  -u glpi -p"${MYSQL_PASSWORD}" glpi' | gzip > /backup/pre-update-$(date +%F).sql.gz

# Tar des volumes de fichiers de GLPI
tar -czf /backup/pre-update-files-$(date +%F).tar.gz \
  /var/lib/docker/volumes/glpi_files/_data

--single-transaction produit un dump cohérent sans verrouiller les tables InnoDB. Et ne mettez jamais le mot de passe en clair sur la ligne de commande : il fuite dans l'historique du shell et dans docker inspect.

2. Figer la version cible dans le compose

N'utilisez jamais le tag latest en production. Il déplace la cible sans prévenir et empêche un rollback déterministe. Figez la version exacte :

# docker-compose.yml
services:
  glpi-app:
    # De :
    image: glpi/glpi:10.0.18
    # Vers (version cible exacte, jamais :latest) :
    image: glpi/glpi:11.0.1
    volumes:
      - glpi_files:/var/glpi/files
      - glpi_config:/var/glpi/config   # config_db.php vit ici - NE PAS le perdre

3. Démarrer la nouvelle image

docker compose pull glpi-app
docker compose up -d glpi-app

4. Lancer la migration de schéma

La commande de migration a été renommée entre les générations de GLPI. Confirmez quel binaire est disponible avant de lancer à l'aveugle :

# GLPI 10/11 (console Symfony) :
docker exec -u www-data glpi-app php bin/console db:update --no-interaction

# GLPI plus ancien (10.0 initial) utilisait :
# docker exec -u www-data glpi-app php bin/console glpi:database:update --no-interaction

Lancez toujours en tant qu'utilisateur du serveur web (www-data ou apache), jamais en root. Lancer la migration en root crée des fichiers de cache avec le mauvais propriétaire, et GLPI se met ensuite à renvoyer des erreurs de permission - un faux « la mise à jour l'a cassé » qui n'est qu'un problème de propriété de fichiers.

5. Vider le cache et valider

docker exec -u www-data glpi-app php bin/console cache:clear

• Accédez à l'interface et vérifiez la version dans Configuration > Général.
• Lancez le diagnostic interne dans Configuration > Vérifications (PHP, extensions et permissions).
• Confirmez que les plugins critiques apparaissent comme actifs, pas comme « à mettre à jour ».
• Testez un flux réel : ouvrir un ticket, joindre un document, déclencher une notification.

Ce que nous avons appris en opérant cela pour des clients

En maintenance, l'incident qui revient le plus n'est pas l'échec de la migration - c'est la migration qui semble avoir réussi tandis que GLPI démarre avec la base par défaut vide. La cause est presque toujours la même : le volume qui contient config/config_db.php n'a pas été mappé, ou l'a été vers un chemin différent dans la nouvelle version. GLPI ne trouve pas la configuration de base, suppose une installation vierge et affiche l'assistant d'installation. Quelqu'un de pressé clique sur « installer » et crée une nouvelle base par-dessus - désormais, en plus de l'interruption, il y a un risque de perte de données. C'est pourquoi, dans notre checklist, la première validation après démarrage n'est pas la version : c'est que docker exec glpi-app cat /var/glpi/config/config_db.php renvoie la vraie configuration du client. Si l'assistant apparaît, nous arrêtons tout avant le moindre clic et revoyons le mappage du volume - nous ne passons jamais par l'interface.

Le second schéma est l'OPcache qui sert l'ancien code après la mise à jour. L'image a changé, le code sur disque est neuf, mais php-fpm a encore l'ancienne version compilée en mémoire. Symptôme : erreurs de méthode inexistante ou version du cœur qui ne correspond pas à l'image. Recréer le conteneur (et pas seulement le redémarrer) résout le problème, car le processus php-fpm est réinitialisé de zéro.

Plan de rollback (répété, pas improvisé)

Un rollback n'est fiable que s'il a été pensé à l'avance. Avec le dump et le tar de l'étape 1, le retour est déterministe :

# Détruit la nouvelle version
docker compose down

# Restaure la base depuis le dump
gunzip < /backup/pre-update-2026-07-02.sql.gz \
  | docker exec -i glpi-db sh -c 'mysql -u glpi -p"${MYSQL_PASSWORD}" glpi'

# Revenir au tag de l'image précédente dans docker-compose.yml
# (ex. : glpi/glpi:11.0.1 vers glpi/glpi:10.0.18)

docker compose up -d

Point critique du rollback : le schéma. Une fois que db:update a modifié la structure, la base n'est plus compatible avec l'ancienne image. C'est pourquoi le rollback doit restaurer le dump - revenir au tag ne suffit pas. Ne restaurer que l'image, avec le schéma déjà migré, laisse l'ancien GLPI lire des tables d'une structure future, ce qui produit des erreurs silencieuses et difficiles à tracer.

Le faire sans interruption non planifiée

Si l'environnement est critique, la fenêtre doit être répétée en recette avec un clone de la base de production. C'est là que l'on découvre, sans pression, si un plugin casse ou si la migration dure plus longtemps que la fenêtre convenue. Mettre à jour directement en production sans cette répétition, c'est parier la disponibilité du client sur la chance.

Si votre équipe n'a pas de fenêtre pour répéter chaque mise à jour, ou a déjà été échaudée par une mise à jour qui a viré à la nuit blanche, NexTool prend en charge la maintenance et les mises à jour de votre GLPI avec un rollback répété et une fenêtre convenue. Parlons de support et maintenance GLPI.

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