Sitemap
DevOps Dudes

A collection of stories that have anything and everything to do with DevOps from horror stories to success stories. If it's about Gitlab, Jenkins, Chef, Ansible, AWS, Azure, Kubernetes, Software Engineer then it belongs here.

Docker Volumes and Bind Mounts

Storing persistent data in containers needs special storage. There are two options — volumes or bind mounts.

4 min readApr 30, 2020

--

Press enter or click to view image in full size
Source: https://evodify.com/assets/posts/2019-06-23-change-docker-storage-location/change-docker-storage-location_thumbnail.jpeg

By default, all files created inside a container are stored on a writable container layer. This means that:

  • The data doesn’t persist when that container no longer exists, and it can be difficult to get the data out of the container if another process needs it.
  • A container’s writable layer is tightly coupled to the host machine where the container is running. You can’t easily move the data somewhere else.
  • Writing into a container’s writable layer requires a storage driver to manage the filesystem. The storage driver provides a union filesystem, using the Linux kernel. This extra abstraction reduces performance as compared to using data volumes, which write directly to the host filesystem.

Docker has two options for containers to store files in the host machine, so that the files are persisted even after the container stops: volumes, and bind mounts. If you’re running Docker on Linux you can also use a tmpfs mount. If you’re running Docker on Windows you can also use a named pipe.

Volume vs. Bind Mounts

--

--

DevOps Dudes
DevOps Dudes

Published in DevOps Dudes

A collection of stories that have anything and everything to do with DevOps from horror stories to success stories. If it's about Gitlab, Jenkins, Chef, Ansible, AWS, Azure, Kubernetes, Software Engineer then it belongs here.

Tj Blogumas
Tj Blogumas

Written by Tj Blogumas

Director of IT Operations at a KC based FinTech. Technology and Automation enthusiast.

Responses (1)