Volumes should not be defined in base images

[mzr-certi]

This is a similar request to docker-library/postgres#404: VOLUMEs should not be declared on the base image (even if "not used" as is in redis).

• It gives you unnamed volumes (with a random id) that cannot be removed

• You cannot override it (yet?), see Reset properties inherited from parent image moby/moby#3465

• VOLUME can easily be declared in a child image/compose/swarm/etc

[mtparet]

First, we are embedding data in our redis container. (it's a choice)
If we are declaring a volume in the base image, it forces the creation of a volume on the host at the deployment step. The issue is on the next deployment, it will use the data in the volume of the host instead of using the data contained in the container...

[nrvnrvn]

Second it!
I had a number of problems with such "hidden" volumes in the past until I ended up with docker system prune --all --volumes --force run regularly on cron timer.

[bdeweygit]

I also see this as an issue, albeit a small one. Every time you run a new redis container it creates a new anonymous volume. The docker and compose CLIs both provide ways of removing anonymous volumes when removing containers, but unless you are aware of these anonymous volumes being created you won't know to clean them up, and so they may continue to grow in number behind the scenes.

[yosifkit]

@MrIceman,
As noted by the creator of redis; it is very easy to "hack" a redis server and change files: http://antirez.com/news/96.

I successfully gained access as the Redis user, with a proper shell, in like five seconds. Courtesy of a Redis instance unprotected being, basically, an on-demand-write-this-file server, and in this case, by ssh not being conservative enough to deny access to a file which is all composed of corrupted keys but for one single entry. However ssh is not the problem here, once you can write files, even with binary garbage inside, it’s a matter of time and you’ll gain access to the system in one way or the other.

We do not build images with malware installed (I did just pull and check them in case there was some sort of exploit of Docker Hub). The affected users are likely exposing their redis to the public internet where it is trivial to "hack".

Edit: previous users with problems by "hackers", #44 (comment), #44 (comment), #44 (comment)

[MrIceman]

@yosifkit you are right, it was my missing knowledge about the security of redis. I learned it the hard way. Sorry for this misinformation

[Grounz]

Hi,

We have exactly the same problem with redis volume, is it planned to delete the instruction volume in redis Dockerfile or not ?

In production have a many anon volume is not really clean for infrastructure exploitation.

[nrvnrvn]

I ended up building my own image. Also see #175

[gt-novelt]

• It gives you unnamed volumes (with a random id) that cannot be removed

You can remove the anonymous volumes by removing the container and its attached anomymous volumes.
docker rm --volumes CONTAINER