Official GLPI Release Image

[cconard96]

This is still a work in progress.

Example .env:

COMPOSE_PROFILES=full
DB_ROOT_PASSWORD=glpi
DB_USER=glpi
DB_PASSWORD=glpi
WEB_PORT=8067
DB_PORT=9906
GLPI_RELEASE=https://github.com/glpi-project/glpi/releases/download/10.0.0/glpi-10.0.0.tgz
IMAGE_TAG=10.0.0
GLPI_LANG=en_US

When building an image, it will automatically download the archive specified by GLPI_RELEASE and tag the image based on IMAGE_TAG. When starting the containers, it checks if GLPI is already installed and if it isn't, it will automatically start the install so the user lands on the login page and not the install.

[cedric-anne]

1. We already provide nightly build images, and, IMHO, we should rely on existing logic. The only difference is that released versions of GLPI are already built, so we can directly use the build archive.
   See Nightly docker image of GLPI #24.

2. Providing a docker-compose.yml file will add complexity, and may require more work for us. Thus, people may want to use a docker image on an existing environment which already contains database services and defined networks.
   I would prefer to add some documentation in which we provide an example of docker-compose.yml file.

3. Definition of user/group ID does not seems usefull to me. Indeed, in a production environment, files should not be used in both container and host contexts, so there should not have any files ownership issues.

[cconard96]

The goal, as far as I read it, was to provide a production-ready GLPI environment with performance and security in mind. To me that means at least an optional database, redis server, etc.

The user/group ID are left over from the reference docker files. I believe the other docker config used mounted volumes instead of named ones.

[cedric-anne]

IMHO, the GLPI files should be directly included in images. It would permit to tag images according to contained GLPI version.
For instance, we could use following images names/tags :

• GLPI 10.0.0 -> glpi:10.0.0, glpi:10.0 (latest tag of 10.0 intermediate release), glpi:10 (latest tag of 10 major release), glpi:latest
• GLPI 9.5.7 -> glpi:9.5.7, glpi:9.5 (latest tag of 9.5 major release) glpi:9 (cannot consider that 9.1 and 9.5 are intermediate versions of a same major release)
• GLPI 9.5.6 -> glpi:9.5.6

So, people using glpi or glpi:latest will always get the latest stable release when using a pull command, but people using glpi:10.0 would ensure to only get bugfixes versions of GLPI 10.0.

Also, if we let people choose the release to use in this image, we will have to maintain images that are compatible with multiple GLPI versions, which can be a pain.

[cedric-anne]

Unless I am wrong, this will not work.

Indeed, a container stops as long as the startup script is exiting. This is why we use apache2-foreground here, as it is a foreground process that is not exiting (unless on failure). So to be sure that this if/else block is executed, you have to move it prior to apache2-foreground execution.

[cedric-anne]

These scripts should exit as long as an error occurred.

Suggested change

	#!/bin/bash
	#!/bin/bash -e

[cconard96]

I think this will need split up since it has mixed concerns.
The first part is the tooling needed to build an official GLPI image while the second is providing a sample docker compose file for building an environment with the official image.