GLPI em Docker: o compose do GLPI 11 e as decisões que separam laboratório de produção

Autor: Pedro Tebaldi PM do KeepGreen

Publicado ago/2026

Um GLPI em container sobe em menos de dois minutos. O comando é curto, a imagem é oficial e a tela de login aparece antes do café ficar pronto.

O problema chega três semanas depois. Alguém roda um docker compose down -v para liberar espaço. O container volta limpo, o GLPI pede instalação de novo e o inventário de 400 ativos some. Nenhum tutorial avisou porque quase todos param no primeiro login.

Este guia cobre o caminho em container do GLPI, a plataforma open source de ITSM. Além do compose comentado linha a linha, ele trata do que decide se a instância sobrevive: persistência, cron, fuso e o limite do modelo.

Por que colocar o GLPI em container

Antes de tudo, o ganho não é velocidade de instalação. Em container, a pilha PHP some do seu escopo. A versão do interpretador, as extensões e as permissões de diretório viajam dentro da imagem, testadas pelo projeto. Portanto, o que sobrava de trabalho na instalação tradicional vira responsabilidade de quem publica a imagem.

Ao mesmo tempo, o modelo muda a natureza do upgrade. Subir do 11.0.7 para o 11.0.8 não é mais uma sequência de comandos no servidor. Agora, é a troca de uma linha no arquivo de composição.

Inclusive, o modelo já é padrão na maioria das equipes de infraestrutura. Na pesquisa anual com desenvolvedores publicada em 2025, 71,1% dos respondentes declararam usar containers no dia a dia.

Se você já opera containers e a diferença deles para máquinas virtuais, o GLPI não adiciona nenhuma peça nova ao seu ambiente.

A imagem oficial já faz três coisas por você

A imagem oficial é a glpi/glpi, publicada pelo próprio projeto a partir do repositório glpi-project/docker-images. No entanto, metade dos tutoriais em circulação usa imagens de terceiros sem avisar o leitor. Isso importa: uma imagem comunitária pode atrasar meses em relação a uma correção de segurança.

Antes de escrever qualquer linha de configuração, entenda três comportamentos que a imagem traz ligados por padrão. Ou seja, eles mudam o procedimento inteiro em relação ao caminho tradicional.

Instalação automática. Com as variáveis de banco preenchidas, a imagem cria o esquema sozinha. Você não vê assistente nenhum: a primeira tela é o login. Para forçar o assistente clássico, use GLPI_SKIP_AUTOINSTALL=true.

Atualização automática. Quando a imagem sobe com uma versão maior que a do banco, ela roda a migração sem perguntar. O controle está em GLPI_SKIP_AUTOUPDATE=true.

Cron embutido. A imagem traz um worker que executa as tarefas agendadas a cada minuto, controlado por GLPI_CRONTAB_ENABLED (valor padrão 1).

Esse último ponto merece destaque, porque é a instrução mais repetida e mais errada sobre o tema. Muitos guias mandam criar um crontab dentro do container ou agendar um docker exec no host. Com a imagem oficial, nada disso é necessário: o worker já roda. Como resultado, duplicar o agendamento faz a mesma tarefa disputar consigo mesma.

A ficha de uma ação automática mostra o worker em funcionamento: frequência de um minuto e última execução registrada no minuto anterior, sem nenhum agendamento criado por você.

O docker-compose.yml do GLPI 11, linha a linha

O arquivo abaixo sobe dois serviços: o GLPI e o MariaDB. Ele fixa a versão em vez de usar latest. Além disso, publica em porta alta para não colidir com nada. Por fim, declara os dois volumes que precisam sobreviver a qualquer recriação de container.

services:
  glpi:
    # Tag fixa: 'latest' migra o banco sem voce pedir
    image: glpi/glpi:11.0.8
    restart: unless-stopped
    environment:
      GLPI_DB_HOST: db
      GLPI_DB_PORT: 3306
      GLPI_DB_NAME: glpi
      GLPI_DB_USER: glpi
      GLPI_DB_PASSWORD: ${GLPI_DB_PASSWORD}
    volumes:
      # Config, arquivos e marketplace: tudo mora aqui
      - glpi_data:/var/glpi
    ports:
      - "8300:80"
    depends_on:
      - db

  db:
    image: mariadb:11
    restart: unless-stopped
    environment:
      MARIADB_ROOT_PASSWORD: ${MARIADB_ROOT_PASSWORD}
      MARIADB_DATABASE: glpi
      MARIADB_USER: glpi
      MARIADB_PASSWORD: ${GLPI_DB_PASSWORD}
    volumes:
      - db_data:/var/lib/mysql

volumes:
  glpi_data:
  db_data:

Três decisões desse arquivo merecem justificativa, porque são exatamente as que a maioria dos guias inverte.

A tag fixa não é preciosismo. Com a atualização automática ligada, latest significa que um docker compose pull de rotina pode migrar o esquema do banco sem você ter planejado janela.

A tag 11.0.8 é a série estável atual. Ademais, a série 11 tem imagem publicada desde outubro de 2025, conforme a lista de tags do registro oficial.

A senha sai do arquivo. A variável ${GLPI_DB_PASSWORD} vem de um .env ao lado do compose, que fica fora do controle de versão. Em resumo, o compose você versiona, o segredo não.

São duas senhas, não uma. O GLPI usa o usuário glpi no dia a dia, mas o root ainda aparece em dois momentos: carregar as tabelas de fuso e conceder permissão. Por isso o .env guarda as duas. Nenhum comando de rotina precisa da senha administrativa.

Subir a pilha e chegar ao primeiro login

Com o arquivo salvo, a subida é um comando. Em seguida, vale acompanhar o log até a instalação automática terminar, porque o container responde na porta antes do esquema estar pronto.

# Sobe os dois serviços em segundo plano
docker compose up -d

# Acompanha a instalação automática até o fim
docker compose logs -f glpi

# Confere se os dois containers estão de pé
docker compose ps

Depois disso, o acesso fica em http://localhost:8300. Como as variáveis de banco estão preenchidas, você não encontra assistente de instalação: a primeira tela já é o login do GLPI 11.

Com as variáveis de banco preenchidas, a primeira tela é o login em vez do assistente de instalação.

As credenciais iniciais são glpi e glpi. Por isso, trate-as como temporárias e leia a próxima seção antes de cadastrar qualquer ativo real.

Os volumes que decidem se você perde tudo

Container é descartável por definição, mas o dado do GLPI não é. A tabela abaixo mostra o que mora em cada caminho persistente e o que acontece quando ele desaparece.

O compose acima resolve os quatro com dois volumes nomeados, porque config, files e marketplace ficam todos dentro de /var/glpi. Por isso, montar apenas o banco é insuficiente. É a causa do sintoma mais reportado no tema: o GLPI que volta à tela de instalação depois de recriar o container.

Vale um alerta para quem usa plugins e customizações do GLPI. O diretório do marketplace só persiste quando está dentro do volume declarado. Portanto, confira esse caminho antes de instalar qualquer extensão em instância com dado real.

Fuso horário: o ajuste que quebra o cálculo de SLA

Este passo não aparece em quase nenhum guia, apesar de afetar todo indicador de atendimento. Sem suporte a fuso no banco, o MariaDB não conhece America/Sao_Paulo. Assim, o GLPI calcula prazo de SLA, horário de abertura e relatório gerencial com a hora errada.

A correção tem dois comandos: carregar as tabelas de fuso no banco, depois habilitar o recurso no GLPI.

# 1. Carrega as tabelas de fuso no MariaDB (root vem do .env)
docker compose exec db sh -c \
  'mariadb-tzinfo-to-sql /usr/share/zoneinfo | mariadb -u root -p"$MARIADB_ROOT_PASSWORD" mysql'

# 2. Dá permissão de leitura ao usuário da aplicação
echo "GRANT SELECT ON mysql.time_zone_name TO 'glpi'@'%';" \
  | docker compose exec -T db sh -c \
      'mariadb -u root -p"$MARIADB_ROOT_PASSWORD" mysql'

# 3. Habilita o suporte a fuso no GLPI
docker compose exec glpi php bin/console database:enable_timezones

Depois disso, cada usuário escolhe o próprio fuso nas preferências. O cálculo de prazo passa então a bater com o relógio da operação.

Depois dos três comandos, o campo de fuso passa a existir nas preferências do usuário com a lista completa de zonas.

Os primeiros ajustes depois que a instância sobe

O GLPI recém-instalado chega com quatro contas de demonstração conhecidas publicamente: glpi, tech, normal e post-only. Além disso, todas usam a senha igual ao nome de usuário. Enquanto elas continuarem assim, a própria interface exibe um alerta vermelho de segurança.

Na lista de usuários, as três contas de demonstração aparecem com a coluna Ativo em Não, enquanto a conta administrativa continua ativa.

Comece por elas, portanto. Troque a senha da conta glpi, depois desative as outras três em vez de apagá-las. Assim, a desativação preserva o histórico caso alguma já tenha sido usada em teste.

Em seguida, ainda antes de cadastrar ativo real, resolva três pontos que ficam pendentes por padrão.

Entidade e regras de negócio. Definir a árvore de entidades depois que existem milhares de chamados custa muito mais caro do que defini-la agora.

Modo de demonstração do painel. A instalação limpa exibe números fictícios no dashboard inicial. Desligue antes de mostrar a tela para qualquer pessoa, senão a primeira impressão vem de dado inventado.

Acesso da API. Se você pretende integrar inventário ou monitoramento, habilite e restrinja o acesso por IP desde já, seguindo o funcionamento da API REST do GLPI.

Com a demonstração desligada, o painel central passa a somar o inventário real da instância.

Atualizar: troque a tag, não o servidor

Aqui está o ganho mais concreto do modelo em container. A atualização não envolve pacote, dependência nem arquivo copiado à mão. Você edita uma linha, recria o container e deixa a imagem migrar o esquema sozinha.

# 1. Backup ANTES de qualquer troca de tag
docker compose exec -T db sh -c \
  'mariadb-dump -u glpi -p"$MARIADB_PASSWORD" --single-transaction glpi' > glpi-antes.sql

# 2. Edite a tag no compose, depois recrie só o GLPI
docker compose pull glpi
docker compose up -d glpi

# 3. Acompanhe a migração do esquema no log
docker compose logs -f glpi

O backup do passo 1 não é opcional. A migração de esquema é irreversível: voltar para a tag anterior deixa a imagem antiga diante de um banco novo, o que não funciona. Sem o dump, o caminho de volta não existe.

Salto de série maior, como sair da linha 10 para a 11, exige mais do que trocar a tag. Nesse caso vale conferir o que muda entre as versões e o checklist de compatibilidade de plugins. Plugin desatualizado é o item que mais interrompe upgrade.

O canal da OpServices tem um panorama do que mudou no GLPI 11 para quem ainda está decidindo o momento da migração.

Backup de um GLPI que mora em container

Backup em container tem duas partes. Esquecer a segunda é comum. O dump do banco resolve chamados, ativos e configuração; os anexos vivem no volume de arquivos, fora do banco.

# Parte 1: o banco
docker compose exec -T db sh -c \
  'mariadb-dump -u glpi -p"$MARIADB_PASSWORD" --single-transaction glpi' \
  | gzip > glpi-$(date +%F).sql.gz

# Parte 2: os arquivos (anexos, config e marketplace)
docker run --rm -v glpi_data:/dados -v $(pwd):/saida busybox \
  tar czf /saida/glpi-arquivos-$(date +%F).tar.gz -C /dados .

Portanto, agende as duas partes juntas e teste a restauração pelo menos uma vez. Um dump que nunca foi restaurado é uma hipótese, não um backup.

Quando o container não é a resposta

Container resolve empacotamento, não arquitetura. Existem três situações em que o caminho tradicional continua sendo a escolha mais honesta.

A primeira é a equipe sem rotina de containers. Se ninguém no time opera Docker no dia a dia, a troca sai cara. Você abandona um problema conhecido, manter uma pilha PHP, por um desconhecido. Diagnosticar rede, volume e permissão de container no meio de um incidente custa mais.

A segunda é a exigência de banco gerenciado ou de armazenamento compartilhado por política interna. Nesse caso a topologia muda. Assim, o compose simples deste artigo deixa de descrever seu ambiente.

Por fim, a terceira aparece na hora de vigiar o que subiu. Uma instância em container precisa de monitoramento de containers com métricas de recurso e ciclo de vida. Afinal, um container reiniciando em laço não gera alerta nenhum quando você só observa a porta HTTP respondendo.

Quando o GLPI vira a ferramenta de chamado de toda a empresa, a operação em volta dele passa a valer mais que a instalação. É aí que a implementação assistida de GLPI costuma pagar o próprio custo.

Subir é rápido, sustentar é o projeto

O compose deste guia coloca o GLPI 11 no ar em dois minutos. No entanto, o resultado dos meses seguintes vem de quatro escolhas feitas nos primeiros trinta. São elas: a tag fixada, os volumes completos, o fuso carregado antes do primeiro chamado e as contas de demonstração desativadas.

Nenhuma delas aparece na tela de login. Todas aparecem depois, em forma de dado perdido, prazo de SLA errado ou upgrade que não volta atrás. Por isso, vale tratar a subida em container como o começo do projeto, não como o fim dele.

Se o GLPI vai virar a porta de entrada dos chamados da sua operação, a conversa muda. Ela sai da instalação para o desenho de processo, a integração com o monitoramento e a definição de SLA. Fale com um especialista da OpServices para avaliar como estruturar essa etapa no seu ambiente.