Stephen Turner, a Docker engineer, has just shared a few best practices to help developers understand file sharing between a Docker container and local host and how its performance varies across OSes.
There are two mechanisms within the Docker Desktop. They share part of the local file system with a container, namely, bind mount and named volumes. Users can copy a part of their file system inside the container’s own file system.
Copying files to a container is definitely not a desired way on which you want to share your code. Hence, if you want to share code you need to edit it first. In an InfoQ article, Turner explains that bind mounts are the most flexible solution, but their performance is inferior to shared volumes.
“It’s in the nature of virtualization that there is always an unavoidable small overhead in crossing the host-VM boundary. It’s only tiny, but in a development environment with a huge source tree and lots of reads and writes, it adds up, and can visibly affect performance.”
NOTICE: This issue only exists on macOS and Windows machines running Docker, because Linux has direct access to the bind-mounted file system.
Furthermore, here are several criterias that Turner suggests which help users to understand when to use bind mounts or shared volumes.
Bind mounts are the option when we want to share code that we need to edit. However, that could be a problem for very large repositories where we have to carry through a high number of operations. In these cases, users could try mirroring, using third-party solutions such as Mutagen and docker-sync.
Bind mounts, however, are definitely not the right option for things like databases, dependency trees or libraries, caches and log files. Hence, in all those cases, users will be better off using shared volumes.
Check Turner’s article for more information.