Docker deixou de ser moda e virou a forma padrão como entregamos e sustentamos GLPI para clientes. Em vez de instalar PHP, MariaDB e servidor web direto no sistema operacional, empacotamos o GLPI e suas dependências em contêineres 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 rodar o service desk em produção com segurança.
Como rodamos o GLPI em Docker
A arquitetura que padronizamos é deliberadamente enxuta: um contêiner para a aplicação GLPI (PHP-FPM e servidor web), um para o banco MariaDB e, quando o volume de chamados 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 precisam sobreviver a qualquer recriação de contêiner - banco, arquivos enviados e configuração - vivem em volumes nomeados, nunca dentro do contêiner. 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.
Artefato: a stack GLPI que provisionamos
Este é o esqueleto do compose que sobe em toda implantação, já com volumes separados e sem credencial em texto plano dentro do arquivo:
# 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 # arquivos enviados 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 # senha via secret, nunca em texto plano
volumes:
- glpi_db:/var/lib/mysql # o banco vive aqui, fora do container
networks: [ internal ]
secrets: [ db_password ]
volumes:
glpi_files:
glpi_db:
networks:
edge: # exposta ao reverse proxy
internal: # banco privado, sem rota externa
internal: true
secrets:
db_password:
file: ./secrets/db_password.txt # arquivo 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 equipe digita quase sem pensar:
| Comando | Quando usamos na sustentação do GLPI |
|---|---|
docker compose up -d | Sobe ou atualiza a stack após uma mudança no compose ou na tag da imagem |
docker compose logs -f glpi | Acompanha o erro de um chamado em tempo real quando o cliente relata falha |
docker compose exec glpi bash | Entra no contêiner para rodar php bin/console (cron, cache, migração) |
docker compose ps | Confere se aplicação e banco estão de pé antes de abrir um incidente |
docker stats | Diagnostica pico de CPU e memória quando a queixa é lentidão |
docker compose down (sem -v) | Recria a stack preservando os volumes; o -v apagaria o banco |
O erro comum - e caro - que já vimos em quem opera sem cuidado é rodar docker compose down -v achando que só vai reiniciar os contêineres. A flag -v remove os volumes, e com eles o banco inteiro do GLPI. Na sustentação, tratamos -v como comando destrutivo: ele não aparece em nenhum procedimento operacional, e todo backup de volume é validado antes de qualquer manutenção que chegue perto 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 no meio de uma manutenção. - Não-root e privilégio mínimo - a aplicação não roda como root, e o banco fica na rede
internal, sem rota externa, acessível apenas pelo contêiner do GLPI. - Secrets fora do compose - a senha do banco entra via Docker secret ou arquivo montado somente-leitura, nunca em
environment:em texto plano commitado no git. - O volume é sagrado - banco, arquivos e configuração em volumes nomeados, com dump lógico diário do banco testado com restauração real (backup que nunca foi restaurado não é backup).
- Imagens enxutas e escaneadas - base slim e varredura com Trivy ou Docker Scout para não levar CVE conhecida para produção.
Um detalhe que só quem sustenta GLPI em contêiner 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 rodar a migração de banco pelo console dentro do contêiner, senão a aplicação sobe apontando para um schema antigo e responde erro 500 na primeira tela. Por isso nosso procedimento de atualização sempre encadeia a mesma ordem: backup do volume do banco, troca da tag, up -d, migração e só então liberação do acesso ao usuário. Quando o cliente usa o plugin NexTool, essa mesma subida recarrega os módulos do ecossistema - então 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 roda instalada direto no servidor, sem volumes separados nem backup testado, a NexTool implanta e sustenta esse ambiente em Docker do jeito certo - com stack versionada, atualização previsível e observabilidade ao lado do service desk. Fale com a gente sobre sustentação de GLPI em contêiner.
Este conteúdo foi produzido com auxílio de inteligência artificial e revisado pela equipe Nextool Solutions.
