Volumes are documented but do not seem to be implemented?
thenewguy opened this issue · comments
https://tox-docker.readthedocs.io/en/stable/ shows how to use dockervolumes but https://github.com/tox-dev/tox-docker/blob/master/tox_docker.py#L168 doesn't seem to parse that variable or pass any volumes to docker run
This would be a really nice feature to have. One example use case: I want to use an initialization script with the official Postgres image which would involve putting a file in the right place in the container. I can probably hack a solution by adding a custom healthcheck command that does my initialization but it would be a lot nicer if I could just pass in the volume.
@thenewguy can you talk about what use cases you have for volumes? I'm leaning against this (tox-docker is not meant to be comprehensiv -- many cases where you might want a volume seem likely better served by baking a new image with whatever contents you want), but would like to learn more.
many cases where you might want a volume seem likely better served by baking a new image with whatever contents you want
The problem with that approach is that you then first have to create the image. I think this would be a workable solution if tox-docker could build the images from a Dockerfile for you though (which as far as I can tell is not supported at the moment).
Do you typically run or have available a docker registry to use? I don't want to add too much to tox-docker, but if this is a real need that's not well served, then I would consider adding build support. Need to think about how to model that in tox.ini, open to suggestions if you have ideas
@dcrosta Yes registries are available but are slightly cumbersome for local testing... especially running by hand unless you configure a fancy way to handle versioning or user specific registries automatically
I have only considered this from the standpoint of running services required by the project - like a database or another api integration tests will interact with. Not for building a Dockerfile that is intended to run the project.
I feel like volumes are probably a smoother approach for a lot of cases because it enables ease of testing between local and ci. It also lets you effectively document the settings you are testing with. And it works for branches.
That being said, I have no idea how much trouble either approach will be... so =)
I think there are cases where building an image makes sense for sure, but also volumes. When you are building your application image or something that you maintain then 100% it makes sense to keep them versioned on a registry. If you are building those types of images with tox-docker it is really going to slow down a CI server where they wouldn't have local build cache (assuming tox-docker isn't pushing/pulling build cache - that wouldn't make sense here imo)
If the simplest approach is to build containers before running them, I envisioned something like /path/in/project/to/TestingDockerfileA that is simple like
FROM: some-upstream-project:release
COPY /config /somewherespecial
Or perhaps bundling a local trust chain for testing something that requires pki.
If the image build is slow - maybe compiling some large program from source - I think it is probably a bad fit for this pattern. You wouldn't really have any way or want to restrict how it is used... but I feel like it would be painful when using it.
I would consider adding build support.
@dcrosta build support isn't necessary here, just having a way to attach volumes. That would serve a lot of use cases where you just want to for example include a configuration file into a pre-existing image. If builds are needed that's something that can already be done by using vanilla tox's commands_pre setting.
Great point about commands_pre. Would it suffice for your needs, then, to build there using FROM and COPY as @thenewguy suggested?
@dcrosta I don't think it is possible to link to services or use the newly built container as a service that way is it? Just to be clear, I am in favor of Volumes over building
Pinging @nolte again... would you consider handing over ownership of the tox-docker readthedocs instance so that I can publish up-to-date docs there?
Just came across this issue as well. A lot of images, like postres, rabbitmq, nginx, require you to provide configuration/initialization files. This is usually done with volumes as we are not re-building on top of the official images (to be always up-to-date from vulnerabilities). That's the most common approach when using docker-compose as far as I am aware.
OK, seems like this is a popular request. I've put up #77 which adds this support -- would folks like to take a look and offer any feedback on either the interface or implementation? Also if you can, please try it and let me know if it works for your various use cases...
Latest version of that PR supports read-only or read-write; for most of the cases mentioned here it sounds like read-only is probably a safer & sufficient choice, so I figured I should throw that in as well. Any other mount options or features this ought to expose?
This is now available in PyPI in 2.0.0a3 if anyone wants to try it out and make sure it works for your use cases.
For those following along, https://tox-docker.readthedocs.io/en/latest/ now reflects this project, rather than the fork.