Improve the note regarding the external volume for /tmp in the Dockerfile

[philippgille]

The guide currently contains the note:

We added a VOLUME pointing to "/tmp" because that is where a Spring Boot application creates working directories for Tomcat by default. The effect is to create a temporary file on your host under "/var/lib/docker" and link it to the container under "/tmp". This step is optional for the simple app that we wrote here, but can be necessary for other Spring Boot applications if they need to actually write in the filesystem.

Regarding the last part: "can be necessary for other Spring Boot applications if they need to actually write in the filesystem".
When can this be necessary? You can write files in Docker containers just fine without any external volume.

Some reasons might be:

• Maybe the file I/O performance is better when the files are on the actual host's /var/lib/docker instead of the container's file system
• When you stop and remove a container without an external volume, all of its data that was written during the container's runtime is gone as well. External volume's aren't removed with the container, at least not by default. So you can start a completely new container with docker run and use the volume from the previous container. This also enables easier backup of data, like docker run --rm --volumes-from dbstore -v $(pwd):/backup ubuntu tar cvf /backup/backup.tar /dbdata (example from the official Docker documentation).
• It's easier for humans to just browse to /var/lib/docker/volumes/... and look at the files instead of having to docker exec -it <runningContainer> bash and then browse.

None of these mean it's necessary and only the first one would be an actual reason to always have that external volume, the other's are nice to have. And I'm not sure if it's true that file I/O is faster on external volumes.

Am I missing other possible reasons?

I'd love to see one the following:

• Add an example of an actual reason to the note or
• if it's just for the convenience reasons above maybe remove the VOLUME and just mention in a note that using a volume has some convenience benefits (including an example).

[mvilrokx]

And I'm not sure if it's true that file I/O is faster on external volumes.

According to the Docker documentation:

• Avoid storing application data in your container’s writable layer using storage drivers. This increases the size of your container and is less efficient from an I/O perspective than using volumes or bind mounts.
• Instead, store data using volumes.

I've been looking for the exact same type of explanation like @philippgille and couldn't find one anywhere so I think this would be a great addition to the documentation.

[dsyer]

I think we'll just remove that VOLUME instruction. I can't see that it adds any value, and I don't know what the explanation is, other than it only worked that way once - perhaps in an older version of docker.

[philippgille]

I think @mvilrokx point was good:

storing application data in your container’s writable layer [...] is less efficient from an I/O perspective than using volumes or bind mounts

My initial question was regarding the word "necessary" in this note in the Spring Boot Docker guide:

This step is optional for the simple app that we wrote here, but can be necessary for other Spring Boot applications if they need to actually write in the filesystem.

It seems it's not necessary, but useful. So one option would be to go with the more production-ready version, i.e. keep the VOLUME, but change the guide.

[dsyer]

IMO this is not a level of detail that we need at all in a "getting started" guide, but I appreciate the discussion might be interesting, if indeed it could be shown to have any impact at runtime. My guess is that it's unlikely to be of any significance that the I/O is more or less efficient with a volume (at least for this sample app, and indeed for the vast majority of vanilla Spring Boot apps). It probably also depends where the container is running and how the volume is mounted, but without some concrete data it's hard to say for sure.