<p>I'm coming from the old world of monolithic applications that write their data to a database, or sometimes use some files. Usually when using files, they are stored in a sub directory of the app directory like app/data.</p>

<p>Now with Docker there is the concept of volumes.</p>

<p>I'm trying to understand:</p>

<ol>
<li>When should I use volumes?</li>
<li>Why storing my files in a volume rather than in a sub directory of the app directory like app/data?</li>
<li>Do I need to change the app code in order to write to the volume instead of app/data, or once the app is hosted by Docker then all the relative paths files will be saved in the mounted volume automatically?</li>
</ol>

Alon
<p>You <a href="https://docs.docker.com/storage/volumes/" rel="nofollow noreferrer">mount a volume into a container</a> when you start it up.  The program inside the container has no idea it's using a volume or not.  Anything you read or write from the volume path automatically uses the volume.</p>

<p>If it's an option, you should avoid storing data in volumes at all; prefer databases if you can.  If all of your data is outside the container then it's very easy to run multiple copies of a container on multiple hosts.  If you're storing some data in volumes then as you scale up your application you need to worry about preserving, replicating, and moving that data.</p>

<p>Good uses for volumes include storing local persistent data that needs to be kept across container restarts.  Host bind mounts are extremely similar (IMHO they are easier to manage, but there are permission and performance problems on some platforms) and also can fill this use case; host bind mounts are also good for injecting config files into applications and reading log files back out.</p>

<p>(For non-Docker reasons it can be convenient to store data outside your application's directory, <em>e.g.</em> <code>/var/lib/myapp</code>.  This is less relevant in Docker where you update your code by building a new image, starting a new container, and then mounting the volume over the filesystem somewhere.  It doesn't really matter if your data is under your app directory or not.)</p>

<hr>

<p>Also you tagged this with "Kubernetes".  All of the above applies here (when I say "scale up" I'm pretty specifically thinking of Kubernetes).  Kubernetes persistent volumes can be slightly trickier to use than Docker named volumes; avoid <code>hostPath</code> type volumes (they won't be consistent across multiple nodes).  You may need to use StatefulSets instead of Deployments to give each Pod its own PersistentVolume.  Getting direct access to PV contents is even harder than it is in Docker.  Conversely, there are other mechanisms like ConfigMaps for some tasks like injecting config files.  Stay far far away from developer-oriented patterns that try to bind-mount application code into containers, it is much harder than just rebuilding your image when you need to.</p>
