Como Instalar o GLPI 11 no Docker: Guia Definitivo

Tutorial de instalação do GLPI 11 com Docker Compose: os cinco volumes que precisam ser persistidos, segredos em .env, instalação via console, proxy reverso com SSL e a correção do erro clássico do cron dentro do container. Com a armadilha que mais derruba GLPI em Docker: recriar o container sem persistir o /etc/glpi.

Docker é a forma mais rápida e reproduzível de subir o GLPI 11. Em menos de 10 minutos você tem MariaDB, volumes persistentes e um ambiente pronto para produção. Mas a diferença entre um laboratório que você joga fora e um GLPI que sobrevive a um docker compose up -d --force-recreate está em uma coisa só: quais dados você persistiu. Na sustentação, é sempre isso que separa "recriei o container" de "perdi o GLPI".

Pré-requisitos

  • Servidor Linux (Debian 12, Ubuntu 22.04+ ou AlmaLinux 9).
  • Docker Engine 24+ e Docker Compose v2.
  • Mínimo de 2 GB de RAM e 20 GB de disco.
  • Domínio apontando para o servidor (necessário para o SSL).

1. Os cinco volumes que decidem tudo

Antes do compose, entenda o que precisa sobreviver ao ciclo de vida do container. Estes são os pontos que persistimos em todo GLPI em Docker que colocamos de pé:

Volume (host - container)O que guardaPerder significa
/opt/glpi/db - /var/lib/mysqlBanco de dados inteiroPerder todos os chamados e ativos
/opt/glpi/config - /etc/glpiconfig_db.php, chave de criptografia, local_defineO GLPI volta pedindo reinstalação
/opt/glpi/data - /var/lib/glpiArquivos, dumps, sessões, uploadsPerder anexos e sessões ativas
/opt/glpi/plugins - .../pluginsPlugins instalados manualmenteReinstalar plugin a plugin
/opt/glpi/marketplace - .../marketplacePlugins baixados do MarketplaceRebaixar tudo do Marketplace

Crie a estrutura de diretórios:

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

2. Segredos em .env, nunca no compose

Senha hardcoded no docker-compose.yml acaba versionada em algum git um dia. Isole os segredos num .env ao lado do compose e não versione esse arquivo:

# .env - fica ao lado do compose e NAO vai para o git
MARIADB_ROOT_PASSWORD=troque-por-uma-senha-forte
MARIADB_PASSWORD=troque-por-outra-senha-forte

3. docker-compose.yml

Note dois cuidados: a tag do MariaDB é fixada (nunca latest, que pode saltar de major e quebrar) e as senhas vêm do .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

Repare que a porta é publicada em 127.0.0.1:8080, não em 0.0.0.0: quem fala com a internet é o proxy reverso, não o container.

4. Subir e instalar via console

Suba os serviços e aguarde o banco inicializar:

docker compose up -d
docker compose logs -f glpi

Em vez do wizard web, instale pela CLI - é reproduzível e some com o passo manual do 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=pt_BR --no-interaction

Em seguida, remova o instalador por segurança:

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

5. O cron: o erro do crontab dentro do container

Aqui mora a armadilha que mais vimos em campo. É comum a instrução "rode crontab dentro do container", mas a imagem do GLPI é efêmera: um crontab escrito lá dentro morre no próximo up -d. E o GLPI 11 nem depende disso - o disparo automático é feito chamando o cron pela linha de comando. O jeito que sustenta é agendar no host, chamando o container:

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

Com o cron no host, o agendamento sobrevive a recriações do container. O sintoma de quem esquece isso é clássico: notificações que não saem, SLA que não escala e a fila "travada" sem motivo aparente - tudo porque as tarefas automáticas nunca rodam.

6. Proxy reverso com SSL

Em produção, nunca exponha o GLPI direto na porta 80. Coloque um proxy reverso (Nginx Proxy Manager, Traefik ou Nginx manual) com certificado válido na frente:

server {
    listen 443 ssl;
    http2 on;
    server_name glpi.suaempresa.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. Primeiro acesso e senhas padrão

Acesse https://glpi.suaempresa.com e entre com as contas padrão: glpi/glpi (admin), tech/tech, normal/normal e post-only/postonly. Troque ou desative todas imediatamente - essas credenciais são de conhecimento público e o scanner do primeiro dia já as testa.

A armadilha que mais derruba GLPI em Docker

Na sustentação, o incidente número um com GLPI em Docker não é o banco: é recriar o container sem persistir o /etc/glpi. Quando isso acontece, o GLPI perde o config_db.php e volta na tela de instalação, como se fosse a primeira vez - com o banco intacto do lado. O usuário jura que "o Docker apagou o GLPI"; na verdade o container só não sabe mais onde está o banco. Por isso, antes de qualquer up -d --force-recreate, nosso checklist confere se os cinco volumes da tabela estão montados. É um minuto que evita um domingo de recuperação.

Boas práticas para produção

  • Backup automático de /opt/glpi/db e /opt/glpi/data (o banco e os anexos).
  • Fixe a tag das imagens (banco e GLPI); atualize de forma consciente, nunca por latest.
  • Configure SMTP para as notificações e valide que o cron do host está rodando.
  • Instale plugins via Marketplace (Configuração > Plugins) e confirme que caem no volume persistido.

Próximo passo

Com o GLPI no ar, configure SLA e OLA, monte o catálogo de serviços e avalie os módulos do NexTool. Se preferir a operação sustentada por quem faz isso todo dia, fale com a equipe.


Este conteúdo foi produzido com auxílio de inteligência artificial e revisado pela equipe Nextool Solutions.

Perguntas Frequentes

Sim. Há imagens oficiais no Docker Hub baseadas em AlmaLinux, com suporte a GLPI 10 e 11. Fixe uma tag específica (por exemplo 11.0) em vez de latest para não pegar um salto de versão sem querer.

Sim, e é a forma recomendada: facilita atualização, backup e reprodutibilidade. Os requisitos são volumes persistentes para banco, arquivos e configuração, SSL via proxy reverso e o cron agendado no host, não dentro do container.

O GLPI 11 exige uma versão recente do PHP (série 8.x). A imagem Docker oficial já traz a versão correta, então você não precisa instalar nem manter o PHP no host - é uma das vantagens de usar container.

Quase sempre porque o diretório de configuração (/etc/glpi, que guarda o config_db.php) não foi persistido em volume. Ao recriar o container, o GLPI perde a referência do banco e cai na tela de instalação, mesmo com o banco intacto. Persista os cinco volumes e o problema some.

Não escreva o crontab dentro do container, que é efêmero. Agende no host uma linha que chama o cron do GLPI no container (docker exec ... front/cron.php) a cada minuto. Assim o agendamento sobrevive a recriações e as notificações e escalonamentos de SLA voltam a rodar.

Precisa de ajuda?