NexTool Solutions

Docker ha smesso di essere una moda ed è diventato il modo standard con cui consegniamo e manteniamo GLPI per i clienti. Invece di installare PHP, MariaDB e il web server direttamente sul sistema operativo, impacchettiamo GLPI e le sue dipendenze in container versionati - il che rende l'installazione riproducibile, il rollback banale e la manutenzione prevedibile. Questa guida raccoglie i comandi che usiamo davvero ogni giorno nel supporto e le pratiche che applichiamo per far girare il service desk in produzione in sicurezza.

Come facciamo girare GLPI su Docker

L'architettura che standardizziamo è volutamente snella: un container per l'applicazione GLPI (PHP-FPM e web server), uno per il database MariaDB e, quando il volume di ticket lo giustifica, un Redis per sessione e cache. Tutto orchestrato da un unico docker-compose.yml, dietro un reverse proxy con TLS. I dati che devono sopravvivere a qualsiasi ricreazione del container - database, file caricati e configurazione - vivono in volumi con nome, mai dentro il container. Questa separazione tra codice (l'immagine, usa e getta) e stato (il volume, prezioso) è ciò che trasforma un aggiornamento di versione di GLPI in un'operazione di minuti, e non in una notte intera.

Artefatto: lo stack GLPI che provisioniamo

Questo è lo scheletro del compose che avviamo a ogni deployment, già con volumi separati e senza credenziali in chiaro dentro il file:

# docker-compose.yml - stack GLPI di produzione
services:
  glpi:
    image: glpi/glpi:11.0        # tag fisso, mai 'latest'
    restart: unless-stopped
    depends_on:
      - glpidb
    volumes:
      - glpi_files:/var/glpi     # file caricati e configurazione di 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   # password via secret, mai in chiaro
    volumes:
      - glpi_db:/var/lib/mysql   # il database vive qui, fuori dal container
    networks: [ internal ]
    secrets: [ db_password ]

volumes:
  glpi_files:
  glpi_db:

networks:
  edge:      # esposta al reverse proxy
  internal:  # database privato, senza rotta esterna
    internal: true

secrets:
  db_password:
    file: ./secrets/db_password.txt   # file 600, fuori da git

I comandi che usiamo davvero nel supporto

Nel quotidiano, pochi comandi risolvono la maggior parte degli interventi. Questi sono quelli che il team digita quasi senza pensarci:

L'errore comune - e costoso - che abbiamo visto in operatori distratti è eseguire docker compose down -v pensando che riavvii solo i container. Il flag -v rimuove i volumi, e con essi l'intero database di GLPI. Nel supporto trattiamo -v come un comando distruttivo: non compare in nessuna procedura operativa, e ogni backup di volume viene validato prima di qualsiasi manutenzione che gli si avvicini.

Buone pratiche che applichiamo in produzione

• Tag fisso, mai latest - fissiamo la versione dell'immagine (es. glpi/glpi:11.0, mariadb:11.4) affinché un pull non porti una versione inattesa nel mezzo di una manutenzione.
• Non-root e privilegio minimo - l'applicazione non gira come root, e il database resta sulla rete internal, senza rotta esterna, raggiungibile solo dal container GLPI.
• Secret fuori dal compose - la password del database entra tramite un Docker secret o un file montato in sola lettura, mai in environment: in chiaro committato su git.
• Il volume è sacro - database, file e configurazione in volumi con nome, con un dump logico giornaliero del database testato con un ripristino reale (un backup mai ripristinato non è un backup).
• Immagini snelle e scansionate - una base slim e la scansione con Trivy o Docker Scout per non portare una CVE nota in produzione.

Un dettaglio che conosce solo chi mantiene GLPI in container: aggiornare la versione di GLPI non è solo cambiare il tag dell'immagine. Dopo il docker compose up -d con l'immagine nuova, bisogna eseguire la migrazione del database dalla console dentro il container, altrimenti l'applicazione parte puntando a uno schema vecchio e restituisce un errore 500 alla prima schermata. Per questo la nostra procedura di aggiornamento concatena sempre lo stesso ordine: backup del volume del database, cambio del tag, up -d, migrazione e solo allora l'apertura dell'accesso all'utente. Quando il cliente usa il plugin NexTool, questo stesso avvio ricarica i moduli dell'ecosistema - quindi validiamo anche la salute delle integrazioni (code di webhook, sincronizzazione) prima di dichiarare l'ambiente stabile.

Se la tua operatività su GLPI gira ancora installata direttamente sul server, senza volumi separati né backup testato, NexTool implementa e mantiene quell'ambiente su Docker nel modo giusto - con uno stack versionato, aggiornamenti prevedibili e osservabilità accanto al service desk. Parla con noi del supporto di GLPI su container.

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