preface
By default, the data generated by the application in the container is unique to the container itself. If the container is deleted, the corresponding data files will disappear. From an isolation perspective, data should live and die with the container. However, in practical scenarios, data needs to be persisted, that is, when the container is deleted, the data should also exist normally. There are also many scenarios where you need to share data between containers. How do you do that? Let’s talk about container data volumes.
The body of the
1. Manually save the data
There are usually two ways to manually copy a container by command, or to submit the container as an image. Next run the demo by pulling the centos image
-
By command
Data can be copied between hosts and containers using commands, that is, data can be copied before the container is deleted, as follows:
Command description: docker run it –name=”mycentos” centos /bin/bash, directly start the container based on the image centos in interactive mode. The container name is mycentos. Run the /bin/bash command inside the container to go to the terminal. Specific commands in the Docker small white to actual combat command demonstration, easy to understand this article has been detailed; Here’s a quick review of the process of starting a container from an image, as shown below:
Description of the above figure: When Docker executes the startup command, it will first search for the image locally. If there is no image, it will search for and pull the host from the remote warehouse. Then the host can start the container according to the image. If the remote repository also does not find the mirror, an error is reported.
Okay, back to today’s topic, copying data;
Now start a container (Linux) with the centos image and create some files on it to test as follows:
Now, if you delete the container, the corresponding data in the container will also be deleted, so you need to copy the corresponding data to the host as follows:
Docker cp bfb96a6afdbc: / usr/TestData/usr/TestDataHost command parsing:
- Syntax: docker cp SRC_PATH DEST_PATH
- Bfb96a6afdbc: / usr/TestData corresponding is SRC_PATH, said the source, namely the need to copy the directory or file. Bfb96a6afdbc this is the container ID, which in this way qualifies the data files in a container;
- DEST_PATH /usr/TestDataHost DEST_PATH /usr/TestDataHost DEST_PATH
DEST_PATH = SRC_PATH = DEST_PATH = DEST_PATH = SRC_PATH = DEST_PATH
-
How to submit a container as an image
This is only a backup, but the container is committed to the image by the docker commit command.
But you can obviously feel the inflexibility, the data is still in the container. The docker commit command was mentioned last time, so I won’t repeat the screenshots here.
The above two ways are not a good choice, first of all, in time can not be backed up in time, in addition, through manual operation is obviously not high efficiency, but also prone to error; More important is the bitter partners, so it must be arranged automatically; Use it manually and occasionally depending on the situation.
2. Container data volume
2.1 Understanding Container Data Volumes
Data volumes can be regarded as directories or files and are designed for data persistence and sharing.
The container for attaching data volumes is called a data volume container. Data volumes are independent of the container life cycle. Therefore, when a container is deleted, the attached data volumes will not be deleted.
By mounting the directory in the container to the host, the data can be synchronized in real time, whether the host changes or changes in the container.
2.2 Practical operation demonstration
This will be demonstrated using commands, which will be covered in a later section.
The **-v** option in the docker run command was not mentioned last time, which is deliberately left here to share separately; Mount directly when the container is started; There are several types of syntax:
Docker run -v docker run -v docker run -v docker run -v Docker run -v volume name docker run -v volume name docker run -v volume nameCopy the code
-
Anonymous mount: If you do not specify a name when mounting, a name will be generated automatically
Specifying a host directory
Command parsing is as follows:
# docker run-it --name=" container name "-v Host absolute path: container absolute path image name docker run-it --name="TestVolumeCentos" -v /usr/TestDataHost/DataVolumeTest:/usr/TestVolumeData centosCopy the code
Now that you have mounted the directory inside the container to the host, let’s get a feel for data synchronization:
As you can see from the illustration above, whether the data is modified on the host or in the container, it can be updated in a timely manner. After the container is stopped, the host updates data, and the container is restarted. The modified data is synchronized to the container. The container is deleted, the mounted data is not deleted, it’s still in the host, that’s what we want.
You can use the Docker Inspect command to view the details of the container, which contains the details of the volume mounted, as shown in the following screenshot:
No host directory is specified
Most of the time, we don’t like to specify the host directory ourselves, instead Docker automatically specifies the host directory, so usually we only specify the container directory, as follows:
Docker inspect container ID: Docker inspect container ID:
See if the file data from the container is synchronized:
By default, Docker assigns the mounted host directory to the directory shown above.
You can use the Docker volume LS command to view information about the data volumes attached to the host as follows:
As you can see from the figure above, the name is not intuitive, so more often than not, you will specify a name for the mount, that is, named mount.
-
Named mount: Specify a name when mounting.
Here except when the mount is specified name mount, after the operation and effect are the same, here will not repeat screenshots; Note that this is very similar to the command to specify a host, in the form of the specified path, the colon before the path, as follows:
2.3 Data transfer between containers
Data volumes can also be mounted through container inheritance to share data between containers as follows:
Key command parsing:
-
To start a named mount container TestVolumesFromCentos, run the following command:
docker run -it --name="TestVolumesFromCentos" -v testVolumesFrom:/usr/TestVolumeData centos Copy the code
-
On starting another container, TestVolumesFromCentos2, mount the volume from TestVolumesFromCentos as follows:
docker run -it --name="TestVolumesFromCentos2" --volumes-from TestVolumesFromCentos centos Copy the code
–volumes-from specifies which container to inherit from.
Data changes in any container are now synchronized to other containers in real time, enabling shared and real-time synchronization of container data.
The mount details of the two containers are the same according to docker Inspect container ID. Cut one of the containers as follows:
In fact, you can also limit the operation permissions of the container when specifying the mount directory. For example, you can limit the read-only or read-write permissions of the container in the mount directory as follows:
Ro: read-only.
Rw: read and write;
Ok, so much for the container data volume. If it sounds fancy, it’s actually an operation on a file or directory.
2.4 Redis installation actual combat
As for Redis installation in Docker, it is easy to execute the command directly. Since the image of Redis has been pulled before, the container will be directly started. If there is no local image, it will be pulled from the remote warehouse.
As you can see in the figure above, by default the redis image mounts the /data directory in the container to the host, which is the directory where redis data is stored, thus making Redis persistent.
For Redis, there are many times when you need to modify the configuration file. You cannot change the configuration file in the container every time you modify it. You can place the configuration file in the mounted directory and specify start, or you can mount another configuration file as follows:
Execute the command before the need to advance the configuration files on the host of the/usr/TestDataHost/redisconf directory.
docker run -d -v /usr/TestDataHost/redisconf:/usr/local/etc/redis --name myredisconfigtest redis redis-server /usr/local/etc/redis/redis.conf
Copy the code
Check the mount situation through docker Inspect container, as follows:
After mounting, you only need to modify the configuration file on the host.
conclusion
So much for the container data volume, for the container does not feel very powerful, both isolated and shared, to meet various scenarios. Next, let’s talk about Dockerfile, make your own image, pay attention to “Code Variety circle”, learn with me;