Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support command hooks via ENV VARS #157

Open
pcfreak30 opened this issue Sep 24, 2022 · 7 comments
Open

Support command hooks via ENV VARS #157

pcfreak30 opened this issue Sep 24, 2022 · 7 comments
Labels
enhancement New feature or request pr welcome

Comments

@pcfreak30
Copy link

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
Copy link
Member

m90 commented Sep 24, 2022

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

@m90 m90 added the support Support Requests label Sep 24, 2022
@pcfreak30
Copy link
Author

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
Copy link
Member

m90 commented Sep 25, 2022

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
Copy link
Author

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
Copy link
Member

m90 commented Sep 26, 2022

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
Copy link
Author

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
Copy link
Member

m90 commented Sep 27, 2022

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.

@m90 m90 added enhancement New feature or request help wanted Extra attention is needed pr welcome and removed support Support Requests help wanted Extra attention is needed labels Sep 27, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request pr welcome
Projects
None yet
Development

No branches or pull requests

2 participants