NexTool Solutions

O Docker é a forma mais rápida e reproduzível de arrancar o GLPI 11. Em menos de 10 minutos tem MariaDB, volumes persistentes e um ambiente pronto para produção. Mas a diferença entre um laboratório que se deita fora e um GLPI que sobrevive a um docker compose up -d --force-recreate resume-se a uma coisa: que dados persistiu. Na sustentação, é sempre isso que separa "recriei o contentor" 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 a apontar para o servidor (necessário para o SSL).

1. Os cinco volumes que decidem tudo

Antes do compose, perceba o que precisa de sobreviver ao ciclo de vida do contentor. Estes são os pontos que persistimos em cada GLPI em Docker que pomos de pé:

Crie a estrutura de diretórios:

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

2. Segredos em .env, nunca no compose

Uma palavra-passe fixada no docker-compose.yml acaba versionada nalgum git um dia. Isole os segredos num .env ao lado do compose e não versione esse ficheiro:

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

3. docker-compose.yml

Repare em dois cuidados: a tag do MariaDB está fixada (nunca latest, que pode saltar de major e quebrar) e as palavras-passe 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 inverso, não o contentor.

4. Arrancar e instalar por consola

Arranque os serviços e aguarde a base inicializar:

docker compose up -d
docker compose logs -f glpi

Em vez do assistente web, instale pela CLI - é reproduzível e elimina 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_PT --no-interaction

De 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 contentor

Aqui mora a armadilha que mais vemos no terreno. É comum a instrução "corra crontab dentro do contentor", 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 comandos. A forma que se sustenta é agendar no anfitrião, chamando o contentor:

# crontab do anfitriao - 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 anfitrião, o agendamento sobrevive às recriações do contentor. O sintoma de quem se esquece disto é clássico: notificações que não saem, SLA que não escala e uma fila "presa" sem motivo aparente - tudo porque as tarefas automáticas nunca correm.

6. Proxy inverso com SSL

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

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 palavras-passe predefinidas

Aceda a https://glpi.suaempresa.com e entre com as contas predefinidas: glpi/glpi (admin), tech/tech, normal/normal e post-only/postonly. Altere ou desative todas de imediato - estas credenciais são do conhecimento público e um scanner do primeiro dia já as testa.

A armadilha que mais derruba o GLPI em Docker

Na sustentação, o incidente número um com GLPI em Docker não é a base de dados: é recriar o contentor sem persistir o /etc/glpi. Quando isso acontece, o GLPI perde o config_db.php e volta ao ecrã de instalação como se fosse a primeira vez - com a base intacta ao lado. O utilizador jura que "o Docker apagou o GLPI"; na verdade o contentor apenas já não sabe onde está a base. Por isso, antes de qualquer up -d --force-recreate, a nossa lista de verificação confirma que os cinco volumes da tabela estão montados. É um minuto que evita um domingo de recuperação.

Boas práticas para produção

• Cópia de segurança automática de /opt/glpi/db e /opt/glpi/data (a base e os anexos).
• Fixe as tags das imagens (base e GLPI); atualize de forma consciente, nunca por latest.
• Configure o SMTP para as notificações e confirme que o cron do anfitrião está a correr.
• 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 isto todos os dias, fale com a equipa.

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