Volume 3 types of Docker Compose considered from the purpose


In order to eliminate the following experiences and selfish beliefs I wrote it from the perspective that it was easy to understand if I thought about it this way.

――What is .:! The initial confusion --All volume is for mounting the host side --anonymous volume is degraded named volume?

Why Docker needs volume

There are the following mechanisms of Docker, and I think that the mechanism to solve each is volume. --Normally, when the container is stopped, the data in the container is not retained. --Host-Container is treated as an independent environment and files cannot be shared --Containers-Containers are treated as independent environments and data cannot be shared.

3 types of volume

--host volume? (I don't know the exact name) --anonymous volume (I often see the description anonymous volume? Anonymous volume) --named volume

Let's start with the cases where each is needed

Docker volume from the point of view

Persist the data in the container => Possible for all volumes

Normally, when the container is stopped, the data in the container is not retained (= not persisted) The mechanism to make this persistent is volume Example) For everything that should not be lost each time, including DB data

Synchronize between the host (local side) and the container => host volume is possible

While Docker treats the host-container as an independent environment, it is possible to mount a specific directory on the host side and synchronize data between the host and container. Example) When the file edited on the host is reflected in the container at any time, such as in the development environment.

Share volume with multiple containers => possible with named volume

Normally, containers are treated as independent environments, and files are not shared. Easy container-to-container file sharing by using named volume Example) When sharing with static content between Web server (container) and application server (container)

that? What about anonymous volume? ??

I think this is enough for cases where you only want to ensure persistence, do not need to synchronize with the host, and do not need to share with other containers. Also, as part of a persistent, shared volume, I feel that it is effective in cases where you dare to maintain independence between containers. For example, some directories under the volume on which the host is mounted can be separated as anonymous volume, and the path specified by anonymous volume can ensure independence between containers.

Setting example --Docker volume 3 types

host mount: <host_path>:<container_path> Mount the host directory and synchronize with the path in the container

  - .:/myapp # .(Current directory)Mount and inside the container/Sync with myapp

named volume: <volume_name>:<container_path> It is easy to share with other containers because it is named, which treats the path in the container as volume and makes it persistent. ** Even under the host mounted path, the named volume is treated as another volume and separated from the host side **

  - node_modules:/myapp/node_modules #Persist path in the container as volume, node_Manage with the name modules

anonymous volume: <container_path> The difference from named volume is that it is anonymous, it has no name (but it is assigned a random hash), and it should be fine if you just want to make it persistent without assuming it to be shared with other containers.

  - /myapp/node_modules #Describe only the path in the container and make it persistent as volume

(Scheduled to be updated at any time)


Frequent options you should know to become "Docker Compose, I understand" --Compose file version 3 (3.8) reference --- Qiita

Recommended Posts

Volume 3 types of Docker Compose considered from the purpose
Docker monitoring-explaining the basics of basics-
Understand the basics of docker
[Summary of technical books] Summary of reading "Learn Docker from the basics"
Comparison of nullable, non-nullable, non-nullable and safe types from the perspective of null safety
From Java9, the constructor of the class corresponding to primitive types is deprecated.
[Challenge CircleCI from 0] Learn the basics of CircleCI
Investigate the replacement from Docker to Podman.
The story of updating SonarQube's Docker Container
[Challenge Docker from 0] Overview and terms of Docker
The story of RxJava suffering from NoSuchElementException
Ruby from the perspective of other languages
Find the difference from a multiple of 10
Volume of optimizing Hyper-v to eliminate the tightness of disk capacity (engineer using Docker)
Has the content of useBodyEncodingForURI changed from Tomcat8?
[Docker] Introduction to docker compose Basic summary of docker-compose.yml
Improve the performance of your Docker development environment
Change the location folder of Docker image & container