Running GLPI Agent in a Docker Container: Community Images and Setup Guide

ByPriya Nair

Yes, GLPI Agent can run in a container — but you’ll need to build or borrow one

There is no single official GLPI Agent container image from the GLPI project team. The official Docker effort targets the GLPI server application itself. For the agent, you’re working with community-built images — and several already exist and are actively maintained.

Community images worth knowing about

Three options come up consistently:

  • gzoratti/glpi-agent-docker on GitHub — built on a minimal Debian base and ships with a docker-compose example. Easiest entry point if you just want something running.
  • ersinesen/glpi-agent-docker — another agent-only image on GitHub with a similar approach.
  • rdrit/glpi-agent — available directly on Docker Hub for those who prefer pulling without touching GitHub.

Before committing to any of them, check the last commit date and open issues. Community images can fall behind when upstream cuts a new release, and GLPI Agent has been releasing frequently.

The host access problem — this is the real catch

GLPI Agent collects hardware inventory: CPU, RAM, disks, network interfaces, installed packages. Inside a container, none of that is visible by default. You get the container’s limited view of the system, which is mostly useless for IT asset management.

To get meaningful inventory data, the container needs access to the host’s namespaces. That typically means three things:

  • Running with network_mode: host so the agent sees the real network stack
  • Mounting /proc and /sys from the host as read-only volumes
  • Mounting /etc if you want software inventory pulled from the host’s package manager

A docker-compose snippet covering the basics:

services:
  glpi-agent:
    image: gzoratti/glpi-agent:latest
    network_mode: host
    volumes:
      - /proc:/proc:ro
      - /sys:/sys:ro
      - /etc:/host/etc:ro
    environment:
      - GLPI_SERVER=https://your-glpi-server/
      - GLPI_TOKEN=your-agent-token
    restart: unless-stopped

Exact environment variable names depend on the image — always check the README of whichever image you choose before deploying this.

Building your own image

If you want a pinned agent version, custom Perl modules, or a specific cron schedule baked in, building from scratch is not complicated. The GLPI Agent Linux installer is a Perl script, so the Dockerfile stays short:

FROM debian:bookworm-slim
RUN apt-get update && apt-get install -y perl curl \
    && rm -rf /var/lib/apt/lists/*
ADD https://github.com/glpi-project/glpi-agent/releases/download/1.16/glpi-agent-1.16-linux-installer.pl /tmp/installer.pl
RUN perl /tmp/installer.pl --install --no-service --server=https://your-glpi/
CMD ["glpi-agent", "--daemon", "--no-fork"]

The --no-service flag skips the systemd unit setup, which does not exist inside a container. Handle scheduling with cron or a simple loop in your entrypoint script instead. Pin the installer URL to a specific release version so your image does not break silently on a re-build.

AppImage as a lighter alternative

Not every deployment actually needs Docker. The official GLPI Agent AppImage runs on essentially any Linux distro without touching system packages, and the portable mode lets you run it straight from a USB key or a network share. It creates its own etc/ and var/ subdirectories alongside the script — nothing lands on the host filesystem. Simpler than a container for one-off or roaming deployments where spinning up Docker is overkill.

The server-side container story is different

The GLPI project does maintain official Docker images for the GLPI server, hosted at ghcr.io/glpi-project/glpi. Every release triggers an automatic image build, including the GLPI 11 beta. If you want to containerize both the server and the agent, start with the official server image and run a community agent container alongside it on the same host, sharing network_mode: host on the agent side.

Sources

Similar Posts