Skip to content

Consider removing VOLUME directive in Dockerfiles #128

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

Closed
dstearnsadobe opened this issue Oct 23, 2019 · 4 comments
Closed

Consider removing VOLUME directive in Dockerfiles #128

dstearnsadobe opened this issue Oct 23, 2019 · 4 comments

Comments

@dstearnsadobe
Copy link

The recent fix for #124 added a VOLUME directive to the Dockerfiles, which causes Docker to create a managed volume when the container is run. By default, Docker doesn't remove this volume when you remove the container. One must use docker rm --volumes ... or docker volume prune to clean up that volume, which is easy to forget.

Using the VOLUME directive in the Dockerfile also removes the ability for those running the container to choose whether a managed volume is created or not. One can always map the /var/run/openresty container directory to a Docker managed volume, or a specific host directory, using the -v flag when running the container. But if you put the VOLUME directive in the Dockerfile, that choice is removed and the volume is always created.

And unfortunately for us, our container runtime infrastructure also specifically prohibits containers that create volumes like this, so we now can't upgrade past your 1.15.8.2-2 version.

The comments in #124 imply that this directive was added to ensure that the /var/run/openresty directory is created within the container, but that could be done with a simple RUN mkdir -p /var/run/openresty instead. Would you be willing to remove the VOLUME directive and just use mkdir -p to ensure that this directory exists within the container? That way those running the container can choose whether to map that directory to a volume or not.

Thanks for considering this!

@neomantra
Copy link
Member

I see your points here, thanks for raising them. I'll work the changes this weekend and you can test master images.

@neomantra
Copy link
Member

neomantra commented Nov 15, 2019

Sorry this took me so long, especially considering the simplicity of the change. I've put a commit up and the un-release-tagged images are built. Can you give it a spin? If it works, I'll tag it as 1.15.8.2-5.

So relevant images to test are among alpine, buster, centos-rpm, stretch, xenial. Thanks!

@dstearnsadobe
Copy link
Author

@neomantra I cloned, built the alpine image, and ran it. All worked perfectly for me, and no volumes were created!

@neomantra
Copy link
Member

Great, I've tagged it as 1.15.8.2-5 and pushed. Should be on Docker Hub after Travis does its thing. Thanks for the feedback.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants