Volumes should not be defined in base images

[huggla]

Base images should avoid setting VOLUME since it is currently impossible to unset in child images:
moby/moby#3465

[tianon]

Setting PGDATA is a trivial way to adjust which directory PostgreSQL saves data to (which is also noted in the image description). See also #375 for another discussion of this same topic.

[huggla]

Yes, but a pointless volume is still created.

[jannemann]

@huggla is right. This is maybe ok if you use docker run and just have a few volumes. But if you use docker-compose or maybe even swarm than there are unaccounted volumes on your docker host, which are connected to the container and thus could not be removed. And even worse is that these containers are not named, they have a random id.

Just to show you. I run an application deployed with docker-compose.

$docker volume ls

DRIVER VOLUME NAME
local f91eefad9a2e564e27d6fd204e94990b39206d641cb0bfaca1cb3dd36cee2b9f
local portus_certificates
local portus_postgres
local portus_registry
local portus_static

There are two volumes for the postgres container, as you can validate with docker inspect

$docker inspect --format="{{.Mounts}}" portus_db_1
[{volume portus_postgres /var/lib/docker/volumes/portus_postgres/_data /var/lib/postgres/data local rw true } {volume f91eefad9a2e564e27d6fd204e94990b39206d641cb0bfaca1cb3dd36cee2b9f /var/lib/docker/volumes/f91eefad9a2e564e27d6fd204e94990b39206d641cb0bfaca1cb3dd36cee2b9f/_data /var/lib/postgresql/data local true }]

[cantino]

I ran into the same problem and spent a few hours trying to understand why random volumes were being created in docker-compose even though I'd set one for /var/lib/postgresql/data myself. I think the docs should be clearer about this.

[hKaspy]

I can add another view why not to use the VOLUME:

We use automated tests with Postgres Image pre-filled with data during build time. This way the image starts a lot faster which saves computing time. Now imagine running these tests on every commit and pull request.

You make hundreds of empty volumes with that process. Currently we use our own Dockerfile, copy-pasted from official repo, only with the VOLUME line commented out.

[ms4720]

This is also causing me issues on kubernetes, the behavior you use is forbidden in kubernetes for production, https://kubernetes.io/docs/concepts/storage/persistent-volumes/ :

HostPath (Single node testing only – local storage is not supported in any way and WILL NOT WORK in a multi-node cluster)

[ta32]

I can add another view why not to use the VOLUME:

We use automated tests with Postgres Image pre-filled with data during build time. This way the image starts a lot faster which saves computing time. Now imagine running these tests on every commit and pull request.

You make hundreds of empty volumes with that process. Currently we use our own Dockerfile, copy-pasted from official repo, only with the VOLUME line commented out.

2018-12-05 23:46:19 (39.5 MB/s) - '/usr/local/bin/gosu.asc' saved [543/543]

• mktemp -d
• export GNUPGHOME=/tmp/tmp.Ii0f14Usol
• gpg --keyserver ha.pool.sks-keyservers.net --recv-keys B42F6819007F00F88E364FD4036A9C25BF357DD4
  gpg: keybox '/tmp/tmp.Ii0f14Usol/pubring.kbx' created
  gpg: keyserver receive failed: Cannot assign requested address

how did you get it to build i always run into the same issue?

[ms4720]

@ta32

gpg: keyserver receive failed: Cannot assign requested address

usbarmory/usbarmory-debian-base_image#9

[workmaster2n]

I'm not trying to argue for or against the VOLUME in the Dockerfile, but could someone explain the benefits of the VOLUME or intended use case? I'm just curious to learn best practices around Docker.

[mindreader]

Without the volume call, if you are using it for testing purposes it will write data into the container and that data will be lost upon container deletion. But even with the volume, every time you create a container it just spawns a new anonymous volume, so you get the exact same behavior, but you leave volumes all over the place.

And the workaround is horrendous. Manually forking every version of postgres and changing one line.

[ms4720]

It would be great if the project maintained current behavior and a no volume branch while deprecating over a few version the current behavior.