NexTool Solutions

Docker es la forma más rápida y reproducible de levantar GLPI 11. En menos de 10 minutos tienes MariaDB, volúmenes persistentes y un entorno listo para producción. Pero la diferencia entre un laboratorio que tiras y un GLPI que sobrevive a un docker compose up -d --force-recreate se reduce a una cosa: qué datos persististe. En el soporte, eso es lo que siempre separa "recreé el contenedor" de "perdí GLPI".

Requisitos previos

• Servidor Linux (Debian 12, Ubuntu 22.04+ o AlmaLinux 9).
• Docker Engine 24+ y Docker Compose v2.
• Mínimo 2 GB de RAM y 20 GB de disco.
• Dominio apuntando al servidor (necesario para el SSL).

1. Los cinco volúmenes que lo deciden todo

Antes del compose, entiende qué debe sobrevivir al ciclo de vida del contenedor. Estos son los puntos que persistimos en cada GLPI en Docker que ponemos en pie:

Crea la estructura de directorios:

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

2. Secretos en .env, nunca en el compose

Una contraseña incrustada en docker-compose.yml acaba versionada en algún git un día. Aísla los secretos en un .env junto al compose y no versiones ese archivo:

# .env - va junto al compose y NO se sube a git
MARIADB_ROOT_PASSWORD=cambia-por-una-contrasena-fuerte
MARIADB_PASSWORD=cambia-por-otra-contrasena-fuerte

3. docker-compose.yml

Fíjate en dos cuidados: la etiqueta de MariaDB está fijada (nunca latest, que puede saltar de major y romper) y las contraseñas vienen del .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

Observa que el puerto se publica en 127.0.0.1:8080, no en 0.0.0.0: quien habla con internet es el proxy inverso, no el contenedor.

4. Levantar e instalar por consola

Arranca los servicios y espera a que la base inicialice:

docker compose up -d
docker compose logs -f glpi

En lugar del asistente web, instala desde la CLI - es reproducible y elimina el paso manual del navegador:

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

Luego elimina el instalador por seguridad:

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

5. El cron: el error del crontab dentro del contenedor

Aquí vive la trampa que más vemos en campo. Es común la instrucción "ejecuta crontab dentro del contenedor", pero la imagen de GLPI es efímera: un crontab escrito ahí muere en el próximo up -d. Y GLPI 11 ni siquiera depende de eso - el disparo automático se hace llamando al cron desde la línea de comandos. La forma que se sostiene es programar en el host, llamando al contenedor:

# crontab del host - dispara el cron de GLPI cada minuto
* * * * * docker exec -u www-data glpi-app php /var/www/glpi/front/cron.php >/dev/null 2>&1

Con el cron en el host, la programación sobrevive a las recreaciones del contenedor. El síntoma de quien lo olvida es clásico: notificaciones que no salen, SLA que no escala y una cola "atascada" sin motivo aparente - todo porque las tareas automáticas nunca corren.

6. Proxy inverso con SSL

En producción, nunca expongas GLPI directo en el puerto 80. Pon delante un proxy inverso (Nginx Proxy Manager, Traefik o Nginx manual) con certificado válido:

server {
    listen 443 ssl;
    http2 on;
    server_name glpi.tuempresa.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. Primer acceso y contraseñas por defecto

Accede a https://glpi.tuempresa.com y entra con las cuentas por defecto: glpi/glpi (admin), tech/tech, normal/normal y post-only/postonly. Cámbialas o desactívalas todas de inmediato - esas credenciales son de dominio público y un escáner del primer día ya las prueba.

La trampa que más tumba GLPI en Docker

En soporte, el incidente número uno con GLPI en Docker no es la base: es recrear el contenedor sin persistir /etc/glpi. Cuando eso pasa, GLPI pierde el config_db.php y vuelve a la pantalla de instalación como si fuera la primera vez - con la base intacta al lado. El usuario jura que "Docker borró GLPI"; en realidad el contenedor solo ya no sabe dónde está la base. Por eso, antes de cualquier up -d --force-recreate, nuestra checklist verifica que los cinco volúmenes de la tabla estén montados. Es un minuto que ahorra un domingo de recuperación.

Buenas prácticas para producción

• Backup automático de /opt/glpi/db y /opt/glpi/data (la base y los adjuntos).
• Fija las etiquetas de las imágenes (base y GLPI); actualiza de forma consciente, nunca por latest.
• Configura SMTP para las notificaciones y confirma que el cron del host está corriendo.
• Instala plugins vía Marketplace (Configuración > Plugins) y confirma que caen en el volumen persistido.

Próximo paso

Con GLPI en línea, configura SLA y OLA, arma el catálogo de servicios y evalúa los módulos de NexTool. Si prefieres tenerlo sostenido por quien hace esto a diario, habla con el equipo.

Este contenido fue producido con ayuda de inteligencia artificial y revisado por el equipo de Nextool Solutions.