Edition 0 Updated to asp. Net core 0

Data 
Volume Containers
and make it easy to share data between containers. Volumes also support 
volume drivers that allow you to store data on remote hosts, among other options. 
Bind mounts
are available since a long time ago and allow the mapping of any folder to a mount 
point in a container. Bind mounts have more limitations than volumes and some important security 
issues, so volumes are the recommended option. 

---

24 
CHAPTER 3 | Architecting container and microservice-based applications 
tmpfs mounts
are basically virtual folders that live only in the host’s memory and are never written to 
the filesystem. They are fast and secure but use memory and are only meant for temporary, non-
persistent data. 
As shown in Figure 4-5, regular Docker volumes can be stored outside of the containers themselves 
but within the physical boundaries of the host server or VM. However, Docker containers can’t access 
a volume from one host server or VM to another. In other words, wi
th these volumes, it isn’t possible 
to manage data shared between containers that run on different Docker hosts, although it could be 
achieved with a volume driver that supports remote hosts. 
Figure 4-5. Volumes and external data sources for container-based applications 
Volumes can be shared between containers, but only in the same host, unless you use a remote driver 
that supports remote hosts. In addition, when Docker containers are managed by an orchestrator, 
containers might “move” between hosts, depe
nding on the optimizations performed by the cluster. 
Therefore, it isn’t recommended that you use data volumes for business data. But they’re a good 
mechanism to work with trace files, temporal files, or similar that will not impact business data 
consistency.