O Docker deixou de ser moda e passou a ser a forma padrão como entregamos e mantemos o GLPI para clientes. Em vez de instalar PHP, MariaDB e servidor web diretamente no sistema operativo, empacotamos o GLPI e as suas dependências em contentores versionados - o que torna a instalação reproduzível, o rollback trivial e a manutenção previsível. Este guia reúne os comandos que realmente usamos no dia a dia da sustentação e as práticas que aplicamos para correr o service desk em produção com segurança.
Como corremos o GLPI em Docker
A arquitetura que padronizamos é deliberadamente sóbria: um contentor para a aplicação GLPI (PHP-FPM e servidor web), um para a base de dados MariaDB e, quando o volume de chamados o justifica, um Redis para sessão e cache. Tudo orquestrado por um único docker-compose.yml, atrás de um reverse proxy com TLS. Os dados que têm de sobreviver a qualquer recriação de contentor - base de dados, ficheiros carregados e configuração - vivem em volumes nomeados, nunca dentro do contentor. Essa separação entre código (a imagem, descartável) e estado (o volume, precioso) é o que transforma uma atualização de versão do GLPI numa operação de minutos, e não numa madrugada inteira.
Artefacto: a stack GLPI que aprovisionamos
Este é o esqueleto do compose que colocamos em cada implementação, já com volumes separados e sem credencial em texto simples dentro do ficheiro:
# docker-compose.yml - stack GLPI de producao
services:
glpi:
image: glpi/glpi:11.0 # tag fixa, nunca 'latest'
restart: unless-stopped
depends_on:
- glpidb
volumes:
- glpi_files:/var/glpi # ficheiros carregados e configuracao do 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 # palavra-passe via secret, nunca em texto simples
volumes:
- glpi_db:/var/lib/mysql # a base de dados vive aqui, fora do contentor
networks: [ internal ]
secrets: [ db_password ]
volumes:
glpi_files:
glpi_db:
networks:
edge: # exposta ao reverse proxy
internal: # base de dados privada, sem rota externa
internal: true
secrets:
db_password:
file: ./secrets/db_password.txt # ficheiro 600, fora do git
Os comandos que realmente usamos na sustentação
No dia a dia de suporte, poucos comandos resolvem a maioria das intervenções. Estes são os que a equipa escreve quase sem pensar:
| Comando | Quando o usamos na sustentação do GLPI |
|---|---|
docker compose up -d | Sobe ou atualiza a stack após uma alteração no compose ou na tag da imagem |
docker compose logs -f glpi | Acompanha o erro de um chamado em tempo real quando o cliente reporta uma falha |
docker compose exec glpi bash | Entra no contentor para correr php bin/console (cron, cache, migração) |
docker compose ps | Confirma se aplicação e base de dados estão de pé antes de abrir um incidente |
docker stats | Diagnostica picos de CPU e memória quando a queixa é lentidão |
docker compose down (sem -v) | Recria a stack preservando os volumes; o -v apagaria a base de dados |
O erro comum - e caro - que já vimos em quem opera sem cuidado é correr docker compose down -v a achar que só reinicia os contentores. A flag -v remove os volumes, e com eles a base de dados inteira do GLPI. Na sustentação, tratamos o -v como comando destrutivo: não aparece em nenhum procedimento operacional, e todo o backup de volume é validado antes de qualquer manutenção que se aproxime dele.
Boas práticas que aplicamos em produção
- Tag fixa, nunca
latest- fixamos a versão da imagem (ex.:glpi/glpi:11.0,mariadb:11.4) para que umpullnão traga uma versão inesperada a meio de uma manutenção. - Não-root e privilégio mínimo - a aplicação não corre como root, e a base de dados fica na rede
internal, sem rota externa, acessível apenas pelo contentor do GLPI. - Secrets fora do compose - a palavra-passe da base de dados entra via Docker secret ou ficheiro montado só de leitura, nunca em
environment:em texto simples submetido ao git. - O volume é sagrado - base de dados, ficheiros e configuração em volumes nomeados, com dump lógico diário da base testado com restauro real (um backup que nunca foi restaurado não é um backup).
- Imagens leves e analisadas - base slim e análise com Trivy ou Docker Scout para não levar uma CVE conhecida para produção.
Um detalhe que só quem sustenta GLPI em contentor conhece: atualizar a versão do GLPI não é apenas trocar a tag da imagem. Depois do docker compose up -d com a imagem nova, é preciso correr a migração da base de dados pela consola dentro do contentor, senão a aplicação arranca a apontar para um esquema antigo e responde erro 500 no primeiro ecrã. Por isso o nosso procedimento de atualização encadeia sempre a mesma ordem: backup do volume da base, troca da tag, up -d, migração e só então a abertura do acesso ao utilizador. Quando o cliente usa o plugin NexTool, esse mesmo arranque recarrega os módulos do ecossistema - por isso validamos também a saúde das integrações (filas de webhook, sincronização) antes de dar o ambiente por estável.
Se a sua operação de GLPI ainda corre instalada diretamente no servidor, sem volumes separados nem backup testado, a NexTool implementa e mantém esse ambiente em Docker da forma certa - com stack versionada, atualização previsível e observabilidade ao lado do service desk. Fale connosco sobre sustentação de GLPI em contentor.
Este conteúdo foi produzido com o auxílio de inteligência artificial e revisto pela equipa Nextool Solutions.
