Working with volumes
An individual Docker container is often very short-lived. Deploying a new version of your application may result in a number of containers being deleted and new ones being spawned. If your application is running in a cloud environment (we will have a look at cloud-based container environments later in this chapter), your container may suffer from a node failure and will be re-scheduled on another cloud instance. This is completely tolerable for stateless applications (in our example, the event service and booking service).
However, this gets difficult for stateful containers (in our example, this would be both the message broker and database containers). After all, if you delete a MongoDB container and create a new one with a similar configuration, the actual data managed by the database will be gone. This is where volumes come into play.
Volumes are Docker's way to make data persist beyond the lifecycle of an individual container. They contain files and exist independently...
