Docker: support volumes for configuration

[benbarkay]

Placing config.inc.php in the same directory as config.inc.local.php prevents use of docker volumes to provide this configuration.

It require usage of a path in the host system, thus tightly coupling the host to the container.

In my use-case, we back up our docker volumes, container configurations etc, but not images or the host system. This means that the container will break when restoring the backup to a different host.

To support volumes, instead of requiring -v file:file, you should allow -v dir:dir to be used.

Thank you for the awesome work :)

[coudot]

Maybe you can just use this as config.inc.local.php:

<?php
include_once("/path/to/volume/config.inc.local.php");
?>

And mount you real config.inc.local.php in the volume.

But I don't really se the need to backup the volume which contains only configuration, there are no data to save.

[benbarkay]

Imagine a host with dozens of containers.

If none of these require any special attention, and the configuration is contained within, then you can mobilize the entire thing to a new host, or recover from backup quickly, without understanding what's running. It can be automated in a simple manner, too.

In contrast, if each of these containers required a special chore, mobilizing the containers becomes a delicate thing, prone to human error, and recovery time increases significantly.

I suppose it's not a big deal if you want to keep this little wart, it can be overcome by inheriting from your image and installing the snippet you've mentioned in your previous comment (although making it more difficult to upgrade).

[coudot]

I understand your point and we will keep this issue open to see how to solve it for the official docker image.

Note that in FusionIAM project, we choose to configure LTB products trough env vars. See for example: https://gitlab.ow2.org/fusioniam/fusioniam/-/blob/master/build/rockylinux9/white-pages/ansible/templates/config.inc.local.php.j2

But I agree this could not work for the official image where we need to be able to modify all the configuration parameters

[davidcoutadeur]

Placing config.inc.php in the same directory as config.inc.local.php prevents use of docker volumes to provide this configuration.

It require usage of a path in the host system, thus tightly coupling the host to the container.

In my use-case, we back up our docker volumes, container configurations etc, but not images or the host system. This means that the container will break when restoring the backup to a different host.

To support volumes, instead of requiring -v file:file, you should allow -v dir:dir to be used.

Thank you for the awesome work :)

I am not sure to fully understand your need.

Indeed, you can already mount configuration directory as a volume. It's just that if you do so, it's up to you to create and maintain configuration files (config.inc.php and config.inc.local.php) in this directory.

config.inc.php being a default configuration file, it may be simpler if we deploy it from main package at each run of the container. I have made a PR for that: #870 @benbarkay could you tell me if it fits your needs?

[benbarkay]

I am not sure to fully understand your need.

I need docker self-containment. I want to only bind volumes created with docker volume create (you can't create a single-file volume, hence the problem).
The benefit of this constraint is that /var/lib/docker is the entire system -- Complete with configuration, data, networking, etc. This makes it easy to:

• Backup everything with no specific host dependencies by backing up /var/lib/docker.
• Spin up snapshots of the system elsewhere, mostly automatically.
• Simplify disaster recovery.

Indeed, you can already mount configuration directory as a volume. It's just that if you do so, it's up to you to create and maintain configuration files (config.inc.php and config.inc.local.php) in this directory.

This would work, however that creates a trap for when the container is upgraded. Since config.inc.php has the defaults (which may change from version to version), as well as logic in it, it is essentially part of the implementation of the software and overriding it with an older version may break things.

config.inc.php being a default configuration file, it may be simpler if we deploy it from main package at each run of the container. I have made a PR for that: #870 @benbarkay could you tell me if it fits your needs?

That solves my issue. Though in my perspective, I think semantically it is a mistake to treat config.inc.php as configuration, and it should be relocated from conf elsewhere along with other sources. It's not decoupled from the rest of the implementation.
(Just my 2c)