cptactionhank/docker-atlassian-jira

Remove VOLUME tag from Dockerfile

weickmanna opened this issue · 2 comments

weickmanna commented

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 commented

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 commented

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 ...