Docker dejó de ser una moda y se convirtió en la forma estándar en que entregamos y damos soporte a GLPI para clientes. En lugar de instalar PHP, MariaDB y el servidor web directamente en el sistema operativo, empaquetamos GLPI y sus dependencias en contenedores versionados - lo que hace que la instalación sea reproducible, el rollback trivial y el mantenimiento predecible. Esta guía reúne los comandos que realmente usamos en el día a día del soporte y las prácticas que aplicamos para ejecutar el service desk en producción con seguridad.
Cómo ejecutamos GLPI en Docker
La arquitectura que estandarizamos es deliberadamente austera: un contenedor para la aplicación GLPI (PHP-FPM y servidor web), uno para la base de datos MariaDB y, cuando el volumen de tickets lo justifica, un Redis para sesión y caché. Todo orquestado por un único docker-compose.yml, detrás de un reverse proxy con TLS. Los datos que deben sobrevivir a cualquier recreación del contenedor - base de datos, archivos subidos y configuración - viven en volúmenes con nombre, nunca dentro del contenedor. Esa separación entre código (la imagen, descartable) y estado (el volumen, valioso) es lo que convierte una actualización de versión de GLPI en una operación de minutos, y no en una noche entera.
Artefacto: el stack de GLPI que aprovisionamos
Este es el esqueleto del compose que levantamos en cada despliegue, ya con volúmenes separados y sin credencial en texto plano dentro del archivo:
# docker-compose.yml - stack de GLPI en produccion
services:
glpi:
image: glpi/glpi:11.0 # tag fijo, nunca 'latest'
restart: unless-stopped
depends_on:
- glpidb
volumes:
- glpi_files:/var/glpi # archivos subidos y configuracion de 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 # contrasena via secret, nunca en texto plano
volumes:
- glpi_db:/var/lib/mysql # la base de datos vive aqui, fuera del contenedor
networks: [ internal ]
secrets: [ db_password ]
volumes:
glpi_files:
glpi_db:
networks:
edge: # expuesta al reverse proxy
internal: # base de datos privada, sin ruta externa
internal: true
secrets:
db_password:
file: ./secrets/db_password.txt # archivo 600, fuera de git
Los comandos que realmente usamos en el soporte
En el día a día, unos pocos comandos resuelven la mayoría de las intervenciones. Estos son los que el equipo escribe casi sin pensar:
| Comando | Cuándo lo usamos dando soporte a GLPI |
|---|---|
docker compose up -d | Levanta o actualiza el stack tras un cambio en el compose o en el tag de la imagen |
docker compose logs -f glpi | Sigue el error de un ticket en tiempo real cuando el cliente reporta un fallo |
docker compose exec glpi bash | Entra al contenedor para ejecutar php bin/console (cron, caché, migración) |
docker compose ps | Verifica que aplicación y base de datos estén arriba antes de abrir un incidente |
docker stats | Diagnostica picos de CPU y memoria cuando la queja es lentitud |
docker compose down (sin -v) | Recrea el stack conservando los volúmenes; el -v borraría la base de datos |
El error común - y caro - que hemos visto en operadores descuidados es ejecutar docker compose down -v creyendo que solo reinicia los contenedores. La bandera -v elimina los volúmenes, y con ellos toda la base de datos de GLPI. En el soporte tratamos -v como un comando destructivo: no aparece en ningún procedimiento operativo, y todo backup de volumen se valida antes de cualquier mantenimiento que se acerque a él.
Buenas prácticas que aplicamos en producción
- Tag fijo, nunca
latest- fijamos la versión de la imagen (p. ej.glpi/glpi:11.0,mariadb:11.4) para que unpullno traiga una versión inesperada en mitad de un mantenimiento. - No-root y privilegio mínimo - la aplicación no se ejecuta como root, y la base de datos queda en la red
internal, sin ruta externa, accesible solo por el contenedor de GLPI. - Secrets fuera del compose - la contraseña de la base de datos entra vía Docker secret o un archivo montado en solo lectura, nunca en
environment:como texto plano commiteado en git. - El volumen es sagrado - base de datos, archivos y configuración en volúmenes con nombre, con un dump lógico diario de la base probado con una restauración real (un backup que nunca se restauró no es un backup).
- Imágenes ligeras y escaneadas - base slim y escaneo con Trivy o Docker Scout para no llevar una CVE conocida a producción.
Un detalle que solo conoce quien da soporte a GLPI en contenedor: actualizar la versión de GLPI no es solo cambiar el tag de la imagen. Tras el docker compose up -d con la imagen nueva, hay que ejecutar la migración de la base de datos desde la consola dentro del contenedor, de lo contrario la aplicación arranca apuntando a un esquema antiguo y devuelve un error 500 en la primera pantalla. Por eso nuestro procedimiento de actualización siempre encadena el mismo orden: backup del volumen de la base, cambio del tag, up -d, migración y solo entonces la liberación del acceso al usuario. Cuando el cliente usa el plugin NexTool, ese mismo arranque recarga los módulos del ecosistema - así que también validamos la salud de las integraciones (colas de webhook, sincronización) antes de dar el entorno por estable.
Si tu operación de GLPI todavía corre instalada directamente en el servidor, sin volúmenes separados ni backup probado, NexTool implanta y da soporte a ese entorno en Docker de la forma correcta - con un stack versionado, actualizaciones predecibles y observabilidad junto al service desk. Habla con nosotros sobre soporte de GLPI en contenedores.
Este contenido fue producido con ayuda de inteligencia artificial y revisado por el equipo de Nextool Solutions.
