feat: parameterize Docker images in docker-compose-local.yml

[inDane]

What

Adds DOCKER_*_IMAGE and DOCKER_*_TAG environment variables so the DB and app images in docker-compose-local.yml can be overridden without modifying the compose file.

Why

• Pin specific image versions for reproducibility
• Swap registries or use local builds without touching YAML
• Keep the defaults for drop-in compatibility

Variables

Variable	Example-Value
DOCKER_DB_IMAGE	my.registry.example.com/hub.docker.com/linuxserver/mariadb
DOCKER_DB_TAG	10.6.13
DOCKER_APP_IMAGE	my.registry.example.com/hub.docker.com/librebooking/librebooking
DOCKER_APP_TAG	5.1.0
DOCKER_PROXY_IMAGE	my.registry.example.com/hub.docker.com/nginxproxy/nginx-proxy
DOCKER_PROXY_TAG	latest
DOCKER_ACME_IMAGE	my.registry.example.com/hub.docker.com/nginxproxy/acme-companion
DOCKER_ACME_TAG	latest

Backward compatible

• Defaults match the previous hardcoded values — no behavior change for existing users.

[inDane]

forgot to add the env variables to docker-compose-public.yml.

[colisee]

Hi @inDane , thank you very much for your PR.

Although your suggestion only applies to docker-compose.yml files, I like it. I just made a test on Windows 11, for I was unsure how it would handle the variable substitutions, and it worked nonetheless.

To approve the PR, you will need to change the name of the variables, so that they don't start with LB_. Variables starting with LB_ belong to the upstream project. I would suggest something like: CONTAINER_DB_IMAGE, CONTAINER_DB_TAG, ...

[inDane]

Hi @inDane , thank you very much for your PR.

Although your suggestion only applies to docker-compose.yml files, I like it. I just made a test on Windows 11, for I was unsure how it would handle the variable substitutions, and it worked nonetheless.

To approve the PR, you will need to change the name of the variables, so that they don't start with LB_. Variables starting with LB_ belong to the upstream project. I would suggest something like: CONTAINER_DB_IMAGE, CONTAINER_DB_TAG, ...

Hi @colisee,
absolutely reasonable. I've refactored the env vars.

Best

[colisee]

Sorry to bother you one last time, but since your env variables start with CONTAINER, it becomes useless to mention DOCKER...

[inDane]

Sorry to bother you one last time, but since your env variables start with CONTAINER, it becomes useless to mention DOCKER...

OK, i think

DOCKER_APP_IMAGE=librebooking/librebooking
DOCKER_APP_TAG=5.2.0
DOCKER_DB_IMAGE=linuxserver/mariadb
DOCKER_DB_TAG:10.6.13

DOCKER_PROXY_IMAGE=nginxproxy/nginx-proxy
DOCKER_PROXY_TAG:latest
DOCKER_ACME_IMAGE=nginxproxy/acme-companion
DOCKER_ACME_TAG:latest

would be the best variant. OK with you?

[colisee]

Fine with me.

The only reason I used CONTAINER_ instead of DOCKER_ was to be free from the underlying container tool (docker, podman, lilipod, containerd...)

[inDane]

i see, but if someone was to build LXC or any other container variant for this, it wouldnt be precise. But honestly I dont have hard feelings for any naming scheme. If you want CONTAINER, i put CONTAINER ;D

[colisee]

Don't worry: please proceed with your naming scheme DOCKER_APP_IMAGE ... I will approve the PR