Shulou(Shulou.com)06/01 Report--

This article shows you why the Docker image repository should be divided into different databases and permissions. The content is concise and easy to understand, which will definitely brighten your eyes. I hope you can get something through the detailed introduction of this article.

Let's start with an accident case:

Scenario: a large Internet e-commerce company uses an image warehouse to manage all Docker images. The image created by the developer is uploaded to the only image library. After the test is passed, the Kubernetes of the operation and maintenance environment directly pulls the image from this library, and everyone has CRUD permission to the image library.

Accident: due to the large storage capacity of the image, the developer intends to clean up the image of the Snapshot. During the image cleaning, the image of the production environment is deleted by mistake, resulting in problems in the launch. The essence is that the mirror image lacks the differentiated management of maturity.

Solution: to upgrade the image of a project, put it in 3 image repositories, development library, test library, and production library. Different mirror libraries correspond to manage mirrors of different maturity.

As can be seen from the picture above, Michael Huttermann demonstrated the concept of pipeline quality barrier in 2012. The figure above means that each pipeline must have a certain quality level, especially in the test environment, that is, Docker images that have not been tested automatically cannot be run in the online environment. In order to distinguish products of different maturity, it is necessary to establish different product warehouses for products of different maturity stages, that is, development library, test library and production library.

According to the principle of distinguishing the maturity of images, I recommend the image storage method in the image above. We provide developers with a mirror development library so that they can Push the finished image to the development library, push it to the image library, and start the developer's self-verification feature. After the self-verification is passed, the image repository will copy (also known as Promote upgrade) to the test database, and then call the Jenkins pipeline of the test environment to execute the automated test case. When the test is completed, record the key information of the test result to the metadata of the image. At the same time, inform the tester to do the UAT test, and after all the tests (manual + automation) are completed, upgrade the image to the release library, also known as the production library.

Now that we have set up three image repositories for each project, you might ask, do I need to configure three image repository addresses? Here we recommend the following working model of the image warehouse.

Take a look at how the above model works:

First, you need a virtual warehouse (Virtual Repository) to aggregate three local repositories (Local) and remote repositories (Remote). At present, JFrog Artifactory supports virtual repositories to provide the R & D team with a unique access address for Docker image centers, without the need to switch between multiple image centers.

Developers use remote repositories to proxy and cache the official mirror source of DockerHub.

The image is upgraded between the three local repositories through the Jenkins pipeline.

End users, such as the Docker client of the production environment, access the virtual warehouse of the Docker production environment, which provides external services.

Well, after understanding the concept of image upgrade and virtual repositories, you may ask, how to configure the permissions of these repositories?

I have drawn the following table to help you understand what basic permissions different teams should have on image repositories of different maturity.

The developer only has CRUD permission to the development library, but no permission to the production library, so that the misoperation of the development to the production library can be avoided. The test team only accepts images that are upgraded to the test library through development self-testing, thus reducing the invalid test rate of the test team. The operation and maintenance staff has the authority of CRUD to the production library. So you may have noticed here that the CI server has permissions for all three repositories, that is, the cross-warehouse replication and tagging of the image is done automatically through the CI server.

Through the separation of development, testing and production repositories to store Docker images of different maturity, it is convenient to clean up the image repository and only clean up the images of the development repository. At the same time, only the CI server can upload the production repository, and the operation and maintenance staff can only accept the images in the production repository, scan for image vulnerabilities and deploy them to the production environment. Yes

The above is why Docker image repositories are divided into different databases and permissions. Have you learned any knowledge or skills? If you want to learn more skills or enrich your knowledge reserve, you are welcome to follow the industry information channel.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.