NexTool Solutions

Docker è il modo più rapido e riproducibile per avviare GLPI 11. In meno di 10 minuti hai MariaDB, volumi persistenti e un ambiente pronto per la produzione. Ma la differenza tra un laboratorio da buttare e un GLPI che sopravvive a un docker compose up -d --force-recreate si riduce a una cosa: quali dati hai reso persistenti. In manutenzione, è sempre ciò che separa "ho ricreato il container" da "ho perso GLPI".

Prerequisiti

• Server Linux (Debian 12, Ubuntu 22.04+ o AlmaLinux 9).
• Docker Engine 24+ e Docker Compose v2.
• Minimo 2 GB di RAM e 20 GB di disco.
• Dominio puntato al server (necessario per l'SSL).

1. I cinque volumi che decidono tutto

Prima del compose, capisci cosa deve sopravvivere al ciclo di vita del container. Questi sono i percorsi che rendiamo persistenti in ogni GLPI in Docker che mettiamo in piedi:

Crea la struttura di directory:

mkdir -p /opt/glpi/{data,config,plugins,marketplace,db}

2. Segreti in .env, mai nel compose

Una password scritta a mano nel docker-compose.yml finisce versionata in qualche git un giorno. Isola i segreti in un .env accanto al compose e non versionare quel file:

# .env - sta accanto al compose e NON va su git
MARIADB_ROOT_PASSWORD=sostituisci-con-una-password-forte
MARIADB_PASSWORD=sostituisci-con-un-altra-password-forte

3. docker-compose.yml

Nota due accortezze: il tag di MariaDB è fissato (mai latest, che può saltare un major e rompere) e le password vengono dal .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

Nota che la porta è pubblicata su 127.0.0.1:8080, non su 0.0.0.0: chi parla con Internet è il reverse proxy, non il container.

4. Avviare e installare da console

Avvia i servizi e attendi l'inizializzazione del database:

docker compose up -d
docker compose logs -f glpi

Invece del wizard web, installa dalla CLI - è riproducibile ed elimina il passo manuale del browser:

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=it_IT --no-interaction

Poi rimuovi l'installer per sicurezza:

docker exec -it glpi-app rm -f /var/www/glpi/install/install.php

5. Il cron: l'errore del crontab dentro il container

Qui vive la trappola che vediamo di più sul campo. Un'istruzione comune è "esegui crontab dentro il container", ma l'immagine GLPI è effimera: un crontab scritto lì dentro muore al prossimo up -d. E GLPI 11 non ne dipende nemmeno - l'attivazione automatica avviene chiamando il cron da riga di comando. Il modo che regge è pianificare sull'host, chiamando il container:

# crontab dell'host - attiva il cron di GLPI ogni minuto
* * * * * docker exec -u www-data glpi-app php /var/www/glpi/front/cron.php >/dev/null 2>&1

Con il cron sull'host, la pianificazione sopravvive alle ricreazioni del container. Il sintomo di chi lo dimentica è classico: notifiche che non partono, SLA che non escala e una coda "bloccata" senza motivo apparente - tutto perché le attività automatiche non girano mai.

6. Reverse proxy con SSL

In produzione, non esporre mai GLPI direttamente sulla porta 80. Metti davanti un reverse proxy (Nginx Proxy Manager, Traefik o Nginx manuale) con certificato valido:

server {
    listen 443 ssl;
    http2 on;
    server_name glpi.tuaazienda.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. Primo accesso e password predefinite

Apri https://glpi.tuaazienda.com ed entra con gli account predefiniti: glpi/glpi (admin), tech/tech, normal/normal e post-only/postonly. Cambiali o disattivali tutti immediatamente - queste credenziali sono di dominio pubblico e uno scanner del primo giorno le prova già.

La trappola che fa cadere più spesso GLPI in Docker

In manutenzione, l'incidente numero uno con GLPI in Docker non è il database: è ricreare il container senza rendere persistente /etc/glpi. Quando succede, GLPI perde il config_db.php e torna alla schermata di installazione come se fosse la prima volta - con il database intatto a fianco. L'utente giura che "Docker ha cancellato GLPI"; in realtà il container semplicemente non sa più dov'è il database. Per questo, prima di ogni up -d --force-recreate, la nostra checklist verifica che i cinque volumi della tabella siano montati. È un minuto che risparmia una domenica di recupero.

Buone pratiche per la produzione

• Backup automatico di /opt/glpi/db e /opt/glpi/data (il database e gli allegati).
• Fissa i tag delle immagini (database e GLPI); aggiorna consapevolmente, mai tramite latest.
• Configura l'SMTP per le notifiche e conferma che il cron dell'host stia girando.
• Installa i plugin via Marketplace (Configurazione > Plugin) e conferma che finiscano nel volume persistito.

Prossimo passo

Con GLPI online, configura SLA e OLA, costruisci il catalogo dei servizi e valuta i moduli NexTool. Se preferisci affidarne la manutenzione a chi lo fa ogni giorno, parla con il team.

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