NexTool Solutions

Docker — самый быстрый и воспроизводимый способ развернуть GLPI 11. Менее чем за 10 минут вы получаете MariaDB, постоянные тома и среду, готовую к продуктиву. Но разница между лабораторией, которую вы выбросите, и GLPI, который переживёт docker compose up -d --force-recreate, заключается в одном: какие данные вы сохранили. В сопровождении именно это всегда отделяет «я пересоздал контейнер» от «я потерял GLPI».

Предварительные требования

• Сервер Linux (Debian 12, Ubuntu 22.04+ или AlmaLinux 9).
• Docker Engine 24+ и Docker Compose v2.
• Минимум 2 ГБ ОЗУ и 20 ГБ диска.
• Домен, указывающий на сервер (нужен для SSL).

1. Пять томов, от которых зависит всё

Перед compose разберитесь, что должно пережить жизненный цикл контейнера. Вот что мы сохраняем в каждом GLPI в Docker, который разворачиваем:

Создайте структуру каталогов:

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

2. Секреты в .env, никогда в compose

Пароль, жёстко прописанный в docker-compose.yml, однажды окажется в каком-нибудь git. Вынесите секреты в .env рядом с compose и не добавляйте этот файл в систему контроля версий:

# .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

Обратите внимание на два момента: тег MariaDB зафиксирован (никогда latest, который может перепрыгнуть мажорную версию и всё сломать), а пароли берутся из .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

Заметьте, что порт публикуется на 127.0.0.1:8080, а не на 0.0.0.0: с интернетом общается обратный прокси, а не контейнер.

4. Запуск и установка через консоль

Запустите службы и дождитесь инициализации базы данных:

docker compose up -d
docker compose logs -f glpi

Вместо веб-мастера устанавливайте через CLI — это воспроизводимо и избавляет от ручного шага в браузере:

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

Затем удалите установщик в целях безопасности:

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

5. Cron: ошибка с crontab внутри контейнера

Здесь кроется ловушка, которую мы чаще всего видим на практике. Распространена инструкция «запустите crontab внутри контейнера», но образ GLPI эфемерен: crontab, записанный внутри, исчезнет при следующем up -d. И GLPI 11 от этого даже не зависит — автоматический запуск выполняется вызовом cron из командной строки. Надёжный способ — планировать на хосте, вызывая контейнер:

# 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

С cron на хосте расписание переживает пересоздания контейнера. Симптом у тех, кто об этом забывает, классический: уведомления не уходят, SLA не эскалируется, а очередь «зависает» без видимой причины — всё потому, что автоматические задачи никогда не запускаются.

6. Обратный прокси с SSL

В продуктиве никогда не публикуйте GLPI напрямую на порту 80. Поставьте перед ним обратный прокси (Nginx Proxy Manager, Traefik или Nginx вручную) с действительным сертификатом:

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. Первый вход и пароли по умолчанию

Откройте https://glpi.suaempresa.com и войдите с учётными записями по умолчанию: glpi/glpi (администратор), tech/tech, normal/normal и post-only/postonly. Немедленно смените или отключите их все — эти учётные данные общеизвестны, и сканеры проверяют их уже в первый день.

Ловушка, которая чаще всего роняет GLPI в Docker

В сопровождении инцидент номер один с GLPI в Docker связан не с базой данных, а с пересозданием контейнера без сохранения /etc/glpi. Когда это происходит, GLPI теряет config_db.php и возвращается на экран установки, как в первый раз, — при этом база данных рядом цела. Пользователь клянётся, что «Docker удалил GLPI»; на самом деле контейнер просто больше не знает, где находится база. Поэтому перед любым up -d --force-recreate наш чек-лист проверяет, смонтированы ли все пять томов из таблицы. Это минута, которая избавляет от воскресенья, потраченного на восстановление.

Рекомендации для продуктива

• Автоматическое резервное копирование /opt/glpi/db и /opt/glpi/data (база данных и вложения).
• Фиксируйте теги образов (базы данных и GLPI); обновляйтесь осознанно, никогда через latest.
• Настройте SMTP для уведомлений и убедитесь, что cron на хосте работает.
• Устанавливайте плагины через Marketplace (Настройки > Плагины) и проверяйте, что они попадают в сохраняемый том.

Следующий шаг

Когда GLPI запущен, настройте SLA и OLA, соберите каталог услуг и оцените модули NexTool. Если предпочитаете, чтобы эксплуатацию сопровождали те, кто делает это каждый день, свяжитесь с командой.

Проверено командой NexTool Solutions.