Support command hooks via ENV VARS

[pcfreak30]

Right now, you have an assumption that you can control the docker daemon via socket volume binding. I am looking to use akash.network, based on Kubernetes, would require using ENV over labels. This would likely mean I will need to fork and modify for this behavior change.

My need here is to use the archive-pre to run a command to dump from a shared volume, which would create an archive of an archive (gitea dump).

[m90]

I don't know too much about Kubernetes and akash.network, but how would you want to run commands in a container from within another container without having access to the Docker socket?

---

Maybe related to #133

[pcfreak30]

but how would you want to run commands in a container from within another container without having access to the Docker socket? I would not. I created a custom image with the software from the other container and a shared volume.

This means I just need a way to execute and clean up after. This means I could also use this as a dedicated backup process for data outside the container if I mounted a host volume in a normal VPS.

[m90]

Hmm, I never thought about how to make this image extensible by means of using it as a base image. I'm not sure about all of the consequences designing it for this use case would bring though.

How would you design an API for your proposed feature that doesn't get too confusing when it comes to making clear this will only be possible on the backup container itself?

---

On a side note I think https://github.com/futurice/docker-volume-backup supports the feature you are looking for already although it's probably a bit too heavy to use it as a base image for something else.

[pcfreak30]

I would simply support an ENV version of the "labels" taking priority over the label versions. From there, the container does not need to care. It really does not need to be complicated.

[m90]

I'm not sure it will be that simple as it will need to take a
totally different and yet to be created code path that is "self-aware" and runs the command as a subprocess instead of using docker exec. Solving it like this would be a lot of extra code and options for a slightly exotic use case.

I wonder if a. there is another way to model this feature that is also helpful elsewhere and b. if there is some way to make this image run commands in containers that are managed by something that is not Docker but maybe Kubernetes or similar.

[pcfreak30]

I can tell you for Akash, the image would have 0 authority over the supervisor process and no access to the sock file. So it could not manage containers, full stop.

[m90]

If this was to be added, I'd model it like this maybe:

• if the command has access to the Docker daemon in any way, the only way to declare command hooks is using labels
• if the command does not have access to the Docker daemon, you can supply command hooks that will be run in whatever context the command runs in using environment variables. This would also make sense when running the command in the image provided but without wanting to expose the host's Docker socket.

The open question for me still is: is there a nice way to declare all of the options without having to introduce a configuration option for every possible hook, (i.e. not having to define COMMAND_ARCHIVE_PRE and so forth) but come up with a scheme that allows defining everything in a single value and also keeping things easily extensible. Maybe this is possible, maybe not, I am not sure yet.

---

If someone wants to work on this I am happy to provide feedback and merge PRs. Personally, I won't find the time to work on this in the near future though.