The deployment of GLPI (Gestionnaire Libre de Parc Informatique) through Docker represents a paradigm shift in how Asset and IT Management software is provisioned, maintained, and scaled. By leveraging containerization, GLPI transitions from a traditional monolithic installation—often plagued by dependency conflicts and environment-specific configuration errors—into a portable, immutable unit of software. This architectural approach utilizes the Docker Engine to encapsulate the GLPI application, its required PHP environment, and its dependencies into a single image, ensuring that the software behaves identically whether it is running on a developer's local workstation, a staging server, or a large-scale production cluster.
The integration of Docker into the GLPI ecosystem is not merely a convenience for deployment; it is a strategic move toward Infrastructure as Code (IaC). By defining the environment in a docker-compose.yml file, organizations can eliminate the "it works on my machine" syndrome, which occurs when subtle differences in OS versions, PHP extensions, or library paths cause software to fail after migration. This methodology provides a safety net for IT managers and DevOps engineers, allowing for rapid prototyping, effortless version switching, and a significantly reduced time-to-value for new users.
Architectural Advantages of GLPI Containerization
The decision to run GLPI inside Docker containers provides several critical technical and operational advantages that are not present in standard bare-metal or VM-based installations.
Consistency: Docker ensures that the runtime environment is identical across all stages of the deployment pipeline. This is achieved by packaging the OS, the web server, and the PHP runtime into a static image. The impact is a total elimination of environment-specific bugs, as the container does not rely on the host operating system's installed libraries. This connects directly to the reliability required for production-grade IT management.
Flexibility: The containerized nature of GLPI allows administrators to switch between versions (such as moving from version 10 to 11) in a matter of seconds. Instead of performing complex in-place upgrades that risk database corruption or file permission errors, a user can simply pull a new image tag and spin up a parallel instance for testing.
Safety by Default: Docker images for GLPI are pre-configured with the necessary optimizations. This reduces the need for manual tweaks to
php.inior web server configurations, which are common points of failure in manual setups. By centralizing the configuration in environment variables, the risk of human error during the setup phase is minimized.Time-Saving: The reduction in troubleshooting time is substantial. Because the official images are pre-built and tested, the onboarding process for new users is accelerated. IT managers can move from the decision to use GLPI to a fully functioning instance without spending hours on environment debugging.
Targeted User Personas for Docker Deployment
The Docker-based deployment strategy is specifically engineered to meet the needs of various professional roles within the technology sector.
IT Managers: For those tasked with maintaining high availability and repeatability, Docker provides a blueprint for deployment. The ability to use a
docker-compose.ymlfile means that the setup can be documented and replicated across multiple sites without variation.New GLPI Users: The steep learning curve of setting up a LAMP stack (Linux, Apache, MySQL, PHP) is bypassed. New users can experience the core functionality of the Asset and IT Management software almost immediately, lowering the barrier to entry for the software.
Developers and DevOps Engineers: For professionals working with containerized infrastructure, GLPI fits seamlessly into a CI/CD pipeline. Using tools like GitHub Actions (which is used by the GLPI project for automated builds), developers can test plugins or modifications against a clean GLPI instance in a matter of minutes.
System Administrators: Those who have experienced "version drift"—where different servers in a cluster run slightly different versions of the software—benefit from the immutable nature of Docker images.
Official Image Ecosystem and Versioning
GLPI provides a robust image ecosystem available through Docker Hub and the GitHub Container Registry, ensuring that users have access to the most current and stable releases.
Image Availability and Automation
Every new release of GLPI triggers an automatic build process that generates a corresponding Docker image. This automation ensures that as soon as a new version is released to the public, the containerized version is available for deployment.
Version Analysis and Tags
The GLPI image repository utilizes a granular tagging system to allow users to choose the specific stability level they require.
| Tag | Stability Level | Description |
|---|---|---|
latest |
Stable | The most recent stable release of GLPI. |
11 |
Stable (Major) | The current major version 11. |
11.0 |
Stable (Minor) | The 11.0 branch of the software. |
11.0.6 |
Specific | A precise point release for maximum stability. |
10 |
Stable (Major) | The previous major version 10. |
10.0 |
Stable (Minor) | The 10.0 branch of the software. |
10.0.24 |
Specific | A precise point release for version 10. |
11.0-nightly |
Beta/Experimental | Nightly builds for version 11. |
10.0-nightly |
Beta/Experimental | Nightly builds for version 10. |
dev-nightly |
Bleeding Edge | The absolute latest development builds. |
Technical Specifications of Images
The images are optimized for different architectures, ensuring compatibility across a wide range of hardware.
- Linux amd64: These images generally range from approximately 303 MB to 335 MB.
- Linux arm64: These images are slightly smaller, ranging from approximately 296 MB to 328 MB.
It is important to note that GLPI 11 images are currently in beta. This means that while they offer the latest features, some components may be unstable, and they should be deployed with caution in production environments.
Deployment Methodology: The Docker Compose Stack
For a production-ready or reliable local deployment, GLPI recommends the use of a Stack approach via Docker Compose. This method manages the application and its database as a single unit.
Required Configuration Files
To deploy the GLPI and MySQL stack, two primary files must be created in a dedicated directory.
docker-compose.yml: This file defines the services, networks, and volumes. It specifies the image to be used, the ports to be exposed, and how the GLPI container should communicate with the database container..env: This file contains the environment variables that thedocker-compose.ymlfile references. This separation allows users to change database credentials or hostnames without modifying the core orchestration logic.
Essential Environment Variables
The .env file must be configured with the following variables to ensure the database and application synchronize correctly:
- Database host: The network address of the database container.
- Database host port: The port used for database communication (typically 3306).
- GLPI Database name: The specific name of the schema created for GLPI.
- GLPI Database User: The username authorized to access the GLPI database.
- GLPI Database Password: The secure password associated with the database user.
Installation Logic and Automation
GLPI containers feature built-in automation for the installation and update process. By default, the container attempts to handle these processes automatically. However, for advanced users or specific production requirements, this behavior can be disabled using the following environment variables in the .env file:
GLPI_SKIP_AUTOINSTALL=true: When set to true, GLPI will not automatically install itself. The administrator must then manually execute the installation wizard through the web interface or via console commands.GLPI_SKIP_AUTOUPDATE=true: When set to true, the container will not automatically update the software. Manual updates via the wizard or console are required.
If these automatic features are disabled, the administrator must use the credentials defined in the .env file during the manual installation process to establish the database connection.
Alternative Deployment: The docker run Method
While Docker Compose is recommended for production, a quick-start deployment can be achieved using the docker run command. This is particularly useful for rapid testing or for developers who do not require a full orchestration stack.
Basic Quick-Start Implementation
The following commands illustrate a basic setup using the diouxx/glpi image and a MariaDB backend.
First, deploy the database container:
docker run --name mariadb -e MARIADB_ROOT_PASSWORD=diouxx -e MARIADB_DATABASE=glpidb -e MARIADB_USER=glpi_user -e MARIADB_PASSWORD=glpi -d mariadb:10.7
Second, deploy the GLPI application and link it to the database:
docker run --name glpi --link mariadb:mariadb -p 80:80 -d diouxx/glpi
Alternatively, if a pre-existing database is available, the following command can be used:
docker run --name glpi --link yourdatabase:mariadb -p 80:80 -d diouxx/glpi
Production-Grade Persistence with Volumes
A critical failure in basic container deployments is the loss of data upon container deletion. For production environments, data persistence is mandatory. This is achieved by mapping container directories to host volumes.
To deploy a persistent database:
docker run --name mariadb -e MARIADB_ROOT_PASSWORD=diouxx -e MARIADB_DATABASE=glpidb -e MARIADB_USER=glpi_user -e MARIADB_PASSWORD=glpi --volume /var/lib/mysql:/var/lib/mysql -d mariadb:10.7
To deploy a persistent GLPI application instance:
docker run --name glpi --link mariadb:mariadb --volume /var/www/html/glpi:/var/www/html/glpi -p 80:80 -d diouxx/glpi
Default Account Credentials (diouxx/glpi)
When using the diouxx/glpi implementation, the following default credentials are provided for initial access and role testing:
- Admin account:
glpi/glpi - Technical account:
tech/tech - Normal account:
normal/normal - Post-only account:
post-only/postonly
Operational Analysis and Best Practices
Deploying GLPI via Docker requires a strategic approach to ensure long-term stability and security.
Version Selection Strategy
The choice of image tag is the most critical decision for a system administrator. For production environments, it is strongly recommended to avoid the latest tag. Using latest can lead to unexpected updates that might introduce breaking changes or unstable beta features. Instead, administrators should use a specific version tag (e.g., 10.0.24). This ensures that the environment remains static until a planned upgrade is initiated.
Persistent Data Management
The use of volumes is not optional for production. All critical GLPI data, including the database files and the application's configuration and uploaded documents, must be stored in volumes. Without this, any update to the container image (which involves deleting the old container and creating a new one) would result in the total loss of all assets and ticket history.
Troubleshooting and Community Engagement
Since the Docker images are built using public repositories, the GLPI project encourages a collaborative approach to stability. Issues encountered during the containerized deployment should be reported directly to the GitHub repository. Community feedback is cited as an essential component for the improvement of the official images.
Final Technical Analysis
The transition of GLPI to a Docker-native deployment model represents a significant optimization of the IT Asset Management lifecycle. By abstracting the underlying hardware and operating system, GLPI removes the primary friction points of traditional software deployment: dependency hell and environment inconsistency.
The implementation of a dual-layer configuration—utilizing a docker-compose.yml for orchestration and an .env file for sensitive data—aligns GLPI with modern DevOps practices. This allows for the implementation of secrets management and ensures that the infrastructure is reproducible. The availability of multiple architecture images (amd64 and arm64) further extends the reach of GLPI, allowing it to run on a variety of hardware, from high-performance servers to low-power ARM-based edge devices.
Ultimately, whether utilizing the official glpi/glpi images for stability and official support or the diouxx/glpi images for rapid prototyping, the result is a streamlined, secure, and highly flexible deployment. The ability to toggle automatic installations and updates via environment variables gives administrators granular control over the lifecycle of the application, ensuring that GLPI can be integrated into any corporate IT environment with minimal risk and maximum efficiency.