NexTool Solutions

Aggiornare GLPI su Docker sembra banale - cambiare il tag dell'immagine e riavviare il contenitore - ma è proprio questa apparente semplicità a generare fermi non pianificati. Nella manutenzione di ambienti dei clienti, la maggior parte degli incidenti di aggiornamento non deriva dalla migrazione del database in sé, ma da plugin incompatibili, dal PHP incorporato nella nuova immagine o da un volume mappato male che fa perdere a GLPI la configurazione del database. Questa guida consolida la procedura che applichiamo in produzione, con i punti in cui le cose si rompono davvero.

Prima di toccare qualsiasi contenitore: l'inventario di compatibilità

Un aggiornamento di GLPI non è solo l'immagine. Sono tre livelli che devono salire insieme: il core, i plugin e lo schema del database. L'errore classico è aggiornare l'immagine e scoprire, con il sito giù, che un plugin critico (per esempio l'inventario nativo, un SSO o un campo personalizzato) non ha una versione per il nuovo core. Verifica questo per primo:

• Versioni esatte di origine e destinazione - un salto minore (10.0.15 a 10.0.18) è sicuro; un salto maggiore (10.x a 11.x) cambia il requisito PHP e può ritirare plugin.
• Matrice dei plugin - per ogni plugin installato, confermare che esista una versione compatibile con la destinazione. Un plugin senza versione compatibile è una decisione di business (disattivare, sostituire o rinviare l'aggiornamento), mai una sorpresa alle 2 di notte.
• PHP incorporato nell'immagine - l'immagine ufficiale porta già il PHP corretto, ma se usi un'immagine propria (Alpine + php-fpm), GLPI 11 richiede PHP 8.2+. Un core nuovo su PHP vecchio dà una pagina bianca senza log chiaro.
• Spazio su disco - il dump e il tar dei volumi possono temporaneamente raddoppiare l'uso. Verifica prima, non durante.

Matrice di decisione: minore, maggiore o saltare versioni

Il tipo di salto definisce la procedura. Questa è la matrice che usiamo per dimensionare finestra e rischio:

L'errore comune qui è credere che saltare versioni faccia risparmiare tempo. GLPI non garantisce la migrazione di schema attraversando un intero maggiore; la routine db:update si aspetta la struttura della versione immediatamente precedente. Saltare da 9.5 direttamente a 11 di solito blocca la migrazione a metà, con il database in uno stato incoerente - e a quel punto il rollback smette di essere opzionale.

Aggiornamento passo dopo passo

1. Backup coerente (database + volumi)

Un backup non è il solo dump. È il dump del database più il tar dei volumi di file (caricamenti, documenti, cache dei plugin). Entrambi devono essere dello stesso istante - per questo fermiamo l'applicazione prima, tenendo su solo il database per il dump:

# Ferma l'app, tiene su il database
docker compose stop glpi-app

# Dump del database (utente dedicato, password via variabile d'ambiente)
docker exec glpi-db sh -c 'mysqldump --single-transaction \
  -u glpi -p"${MYSQL_PASSWORD}" glpi' | gzip > /backup/pre-update-$(date +%F).sql.gz

# Tar dei volumi di file di GLPI
tar -czf /backup/pre-update-files-$(date +%F).tar.gz \
  /var/lib/docker/volumes/glpi_files/_data

--single-transaction produce un dump coerente senza bloccare le tabelle InnoDB. E non mettere mai la password in chiaro sulla riga di comando: trapela nella cronologia della shell e in docker inspect.

2. Fissare la versione di destinazione nel compose

Non usare mai il tag latest in produzione. Sposta l'obiettivo senza preavviso e impedisce un rollback deterministico. Fissa la versione esatta:

# docker-compose.yml
services:
  glpi-app:
    # Da:
    image: glpi/glpi:10.0.18
    # A (versione di destinazione esatta, mai :latest):
    image: glpi/glpi:11.0.1
    volumes:
      - glpi_files:/var/glpi/files
      - glpi_config:/var/glpi/config   # config_db.php vive qui - NON perderlo

3. Avviare la nuova immagine

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

4. Eseguire la migrazione di schema

Il comando di migrazione è stato rinominato tra le generazioni di GLPI. Conferma quale binario è disponibile prima di eseguire alla cieca:

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

# GLPI più vecchio (10.0 iniziale) usava:
# docker exec -u www-data glpi-app php bin/console glpi:database:update --no-interaction

Esegui sempre come utente del web server (www-data o apache), mai come root. Eseguire la migrazione come root crea file di cache con il proprietario sbagliato, e GLPI inizia poi a dare errori di permesso - un falso "si è rotto nell'aggiornamento" che è solo proprietà dei file.

5. Svuotare la cache e validare

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

• Accedi all'interfaccia e verifica la versione in Configurazione > Generale.
• Esegui la diagnostica interna in Configurazione > Verifiche (PHP, estensioni e permessi).
• Conferma che i plugin critici appaiano come attivi, non come "da aggiornare".
• Prova un flusso reale: aprire un ticket, allegare un documento, scatenare una notifica.

Cosa abbiamo imparato gestendo questo per i clienti

In manutenzione, l'incidente che si ripete di più non è il fallimento della migrazione - è la migrazione che sembra riuscita mentre GLPI si avvia con il database predefinito vuoto. La causa è quasi sempre la stessa: il volume che contiene config/config_db.php non è stato mappato, o è stato mappato su un percorso diverso nella nuova versione. GLPI non trova la configurazione del database, assume un'installazione pulita e mostra la procedura guidata di installazione. Chi ha fretta clicca su "installa" e crea un nuovo database sopra - ora, oltre al fermo, c'è rischio di perdita di dati. Per questo, nella nostra checklist, la prima validazione post-avvio non è la versione: è che docker exec glpi-app cat /var/glpi/config/config_db.php restituisca la configurazione reale del cliente. Se appare la procedura guidata, fermiamo tutto prima di qualsiasi clic e rivediamo la mappatura del volume - non procediamo mai dall'interfaccia.

Il secondo schema è l'OPcache che serve codice vecchio dopo l'aggiornamento. L'immagine è cambiata, il codice su disco è nuovo, ma php-fpm ha ancora la versione vecchia compilata in memoria. Sintomo: errori di metodo inesistente o versione del core che non corrisponde all'immagine. Ricreare il contenitore (e non solo riavviarlo) risolve, perché il processo php-fpm viene reinizializzato da zero.

Piano di rollback (provato, non improvvisato)

Un rollback è affidabile solo se è stato pensato prima. Con il dump e il tar del passo 1, il ritorno è deterministico:

# Abbatte la nuova versione
docker compose down

# Ripristina il database dal dump
gunzip < /backup/pre-update-2026-07-02.sql.gz \
  | docker exec -i glpi-db sh -c 'mysql -u glpi -p"${MYSQL_PASSWORD}" glpi'

# Riporta il tag dell'immagine in docker-compose.yml alla versione precedente
# (es.: glpi/glpi:11.0.1 di nuovo a glpi/glpi:10.0.18)

docker compose up -d

Punto critico del rollback: lo schema. Dopo che db:update ha alterato la struttura, il database non è più compatibile con l'immagine vecchia. Per questo il rollback deve ripristinare il dump - riportare il tag non basta. Ripristinare solo l'immagine, con lo schema già migrato, lascia il vecchio GLPI a leggere tabelle di una struttura futura, il che produce errori silenziosi e difficili da tracciare.

Farlo senza fermi non pianificati

Se l'ambiente è critico, la finestra deve essere provata in collaudo con un clone del database di produzione. È lì che si scopre, senza pressione, se un plugin si rompe o se la migrazione dura più della finestra concordata. Aggiornare direttamente in produzione senza quella prova significa scommettere la disponibilità del cliente sulla fortuna.

Se il tuo team non ha una finestra per provare ogni aggiornamento, o è già stato scottato da un aggiornamento finito in nottata, NexTool si occupa della manutenzione e degli aggiornamenti del tuo GLPI con rollback provato e finestra concordata. Parliamo di supporto e manutenzione GLPI.

Questo contenuto è stato prodotto con l'ausilio dell'intelligenza artificiale e revisionato dal team Nextool Solutions.