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

Remove VOLUME tag from Dockerfile #101

Open
weickmanna opened this issue Sep 16, 2019 · 2 comments
Open

Remove VOLUME tag from Dockerfile #101

weickmanna opened this issue Sep 16, 2019 · 2 comments

Comments

@weickmanna
Copy link

weickmanna commented Sep 16, 2019

Our use case:
Prepare Jira image with data so it can be used for integration testing.

  • Derived images have no chance to remove the VOLUME line
  • VOLUME line does not do anything besides documentation (users still have to bind the volume or nothing happens)
  • VOLUME line prevents application data from being stored in the image
  • Managing the data volume separately makes the integration-test pipeline much more complicated

We now opted to copy the entire Dockerfile, as well as docker-entrypoint.sh into our own repository. Since we anyway need to store our own images with the data, it's not a huge problem for us. But it would be unnecessary and others might run into the same problem ...

@Achimh3011
Copy link

Why don't you wrap docker-compose around docker?

  • Separate DB in a separate container
  • Handling of volumes (e.g., tieing to host paths, persisting named volumes)
  • Possibility to define port mappings, environment variables to be valid inside container
  • Application data should not reside in the container

@weickmanna
Copy link
Author

weickmanna commented Oct 7, 2019

Hi @Achimh3011

we use the docker image to perform manual tests as well as integration tests for our software. "Fully loaded" images are intended to be shared within the team, so that everyone can quickly and easily setup a test environment. The same image is also used in the automated integration test pipeline.

We can do with volumes as well, but this requires us to manage the data (which changes infrequently over time) separately with the volume. Then we need to solve following things:

  • Clarify where to store the volume such that everybody can reach it
  • Provide a script for fetching the volume zip from the running container and to upload it somewhere
  • Provide a script for downloading and extracting the volume zip
  • Provide a script for starting the container with the volume installed
  • Version the volume somehow
  • Make that all work not only on the dev machines, but also in the cloud build env

It's all possible, but it seems a lot of unnecessary work ...

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