One of the exciting complexities about docker, is that a docker container is mostly a readonly device. I say mostly, because you create a container by piling up a few layers of images into one bigger image. Once you launch that image, it will be converted into a container that has a read/write layer.
To get around the read-only characteristics of a docker container you could add volumes. These volumes are directories or spaces that sit’s outside a Docker container.
But what does read-only mean?
The example that comes to mind is a simple website. The Clerical Editor contains a web site and a database server. The Website is read-only, that is every file on that website could be set read-only and it will function normally. It does it’s writing to a database – which has to have the read/write characteristics.
An Employee Editor could contain functions that allow the timesheet administrator to upload data which then displays on the timesheet. For example, a leave balance upload command. The timesheet administrator will upload a file, and once that file is uploaded, it will be opened and then read, and the data within that file will then get posted to a database on a different server. The operating environment does not allow a web server to read a file contained on someone else’s computer. So, you copy files to a server and read it from there. In this case, the website needs to capture the file and move that file to a specific location before the data in that file is opened for reading. (they call that a safety feature, I call it another 100 lines of code :^)
In the case of the upload leave balances function, we need a place to hold leave balance files. This will be done by creating a Volume and modifying the application to upload to that location.
So, we have 2 types of volumes that come to mind (a volume holding a database, and another volume holding files being uploaded.) While these are 2 types of volumes the thing to remember is Docker just considers those as volumes.