This note organizes and introduces what mirroring is, as well as mirroring management, mirroring creation, storage, modification, sharing and other aspects.
Mirror image (Image)
What is mirroring?
The image is composed of multiple file systems superimposed:
In Docker, these file systems are called mirrors.
One mirror can be placed on top of another mirror. The mirror below becomes the parent mirror, and the bottom mirror is called the basic mirror. When the container is started from the image, Docker will load a read-write file system at the top of the image, and the programs we run are executed in this read-write file system. 
In Docker, a copy-on-write mechanism is used. At initialization, the read-write layer is empty. When the file system is modified, all changes exist in the read-write layer. For example, if a file is modified, the file will be copied from the read-only layer to the read-write layer, and be modified at the read-write layer. However, the read-only version of the file still exists, but it is hidden by the file in the read-write layer, precisely because of the use of joint mounting technology. The above layers together constitute a mirror image.
#02 Mirror-List
Use the docker images command to view the image.
When executing docker run , if the image does not exist, it will be automatically pulled from the warehouse. The images are stored in /var/lib/docker/, and each image is stored under the storage driver directory used by Docker, such as aufs or devicemapper. And /var/lib/docker/containers/ stores all the containers.
IMAGE -> REPOSITORY -> REGISTRY
REGISTRY, open source, can run its own private Registry, Docker company provides a commercial version of Docker Hub (Docker Trusted Registry), a product that can run inside the firewall, previously known as Docker Enterprise Hub.
The image is stored in the warehouse, which can be compared to the Git warehouse, which contains the image, layer, and image metadata.
Use the docker pull command to pull the image: docker pull ubuntu:12.04
In the output of docker images , the image is listed in units of TAG, that is, "if there is a TAG, there is a record". Each TAG marks some mirror layers that make up a specific mirror, so that a warehouse can contain multiple mirrors. Use the form of "colon plus TAG" to specify a specific mirror in a warehouse.
A mirror can create multiple TAGs, and the mirror IDs are used to distinguish between mirrors, which means "There can be multiple mirrors with different TAGs but the same mirror ID, but in fact they are all the same mirror". Using TAG is a good habit.
In Docker Hub, there are two types of warehouses: user warehouses; top-level warehouses. User warehouse, created by users. The top-level warehouse is managed by Docker insiders.
User warehouse naming is divided into two parts: user name and warehouse name. Such as jamtur01/puppet . These warehouses are created by the users themselves, and they are not confirmed by Docker. You need to bear the corresponding risks when using them.
The top-level warehouse has only the warehouse name part. These images are provided by high-quality manufacturers, and users can build their own images based on these images.
After Docker 1.8, the function of signing images has been added. Used for the security management of the image content.
#03 Mirror-Pull
Use the docker pull command to pull the image.
When the docker run command is executed , if the image does not exist, the TAG will be first pulled as the latest image. You can use the docker pull command to pull the image first to reduce the time it takes to start the image.
#04 Mirror-Find
Use the docker search command to search for images on Docker Hub.
#!/bin/sh docker search puppet
The returned information includes: warehouse name, image description, user evaluation, whether it is official, whether it is built automatically (whether it was created by the automatic build process of Docker Hub).
Then, you can use the docker pull command to pull the image: docker pull puppet/puppetserver
Finally, you can run the container: docker run -i -t puppet/puppetserver /bin/bash
#05 Mirror-Build
#01 Create Docker Hub account
Go to Docker Hub to register an account, use the docker login command to log in, and use docker logout to log out.
Personal authentication information is stored in $HOME/.dockercfg . Starting from Docker 1.7.0, it is stored in $HOME/.docker/config.json .
#06 Mirror-Push to Docker Hub
Use the docker push command to push the image to the remote Docker Hub for others to use. You can also create a private image, but this is a paid feature.
When pushing to a remote warehouse, you need to specify a user name: docker push your_user/your_image
Visit Docker Hub Quickstart | Docker Documentation to view the documentation.
! ! ! Docker Hub supports automatic builds, which need to be associated with GitHub or BitBuket warehouses. It will automatically read the Dockerfile file, then build, and view the build log and output. I won’t expand here, but I don’t know if the open source Docker Registry also supports this feature. :-)
Related Miscellaneous
# About the parent image and parent image layer
Is docker inspect -f'{
{.Parent}}' a safe way to get the base image ID?
command docker image inspect b7b28af77ffe --format'{
{.Parent}} 'The output is indeed The parent image, but this "parent image" is the "parent image layer", not the image layer referenced by FROM in the Dockerfile (unless there is only one FROM instruction in your Dockerfile ).
Build Context
What is the build context?
Docker is a Client/Server architecture, and the build command docker build is actually executed by Docker Server, while Docker Clinet is only responsible for sending requests.
Therefore, the files involved in the construction need to be sent to Docker Server so that Docker Server can build. These files are the Build Context.
You need to specify the Build Context information on the command line, that is, the file to participate in the build. Then Docker Client will package these files and send them to Docker Server for building. You can directly specify directories, archive files, and Git warehouses. If you use a Git repository, Docker Client will first pull the code, then package it and upload it.
potential problems
#1 The build time is too long and the memory and network resources take up too much.
If the content in the Build Context takes up a lot of space, such as a lot of temporary files generated by the build, uploading all to Docker Server will increase the network transmission time and consume bandwidth memory Resources
#2 The image size increases, which affects the startup speed. When
some images are being built, they directly copy the contents of the Build Context (although it should be taken care of by the Dockerfile, but can be avoided through .dockerignore), this will increase the image size and occupy more disk space. And it will also affect the startup speed.
#3 Exposing sensitive information
Some content is sensitive information, such as plain text information before being compiled or encrypted, and should not be copied directly to the image. These directories should always be excluded.
#4 Build cache invalidation (potential problem)
If some non-essential files are frequently changed, such as temporary build output, when copied to Docker Server, then the last build cache cannot be used during the build.
Solution
These problems can be solved by controlling the content sent to Docker Server. This can be solved by the .dockerignore file.
Related links
references
- WikiNotes/Mirror and Repository
- Do not ignore .dockerignore (it’s expensive and potentially dangerous)