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

What is the reason why Docker image repositories need to be divided into libraries and permissions? In response to this problem, today's small editor summarizes this article about Docker mirroring, hoping to help more friends who want to solve this problem find a simpler and easier way.

Let's start with an accident:

Scenario: A large Internet e-commerce company uses an image repository to manage all Docker images. The image created by the developer is uploaded to the only image library. After the test passes, Kubernetes in the operation and maintenance environment pulls the image directly from this library. Everyone has CRUD permissions on the image library.

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

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

As you can see from the image above, Michael Huttermann demonstrated the concept of pipeline quality checkpoints in 2012. The above figure means that each pipeline must have a certain quality barrier, especially in the test environment, that is, Docker images that are not automatically tested cannot be put into 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 libraries, test libraries, and production libraries.

According to the principle of mirror maturity differentiation, I recommend the mirror storage method shown above. We provide developers with mirror libraries for them to push the mirror to the development library. After pushing to the mirror library, the developer self-verification function starts. After self-validation, the mirror repository is copied (also known as Promote upgrade) to the test repository, and then the Jenkins pipeline of the test environment is invoked to execute the automated test case. When the test is completed, the key information of the test results is recorded on the metadata of the mirror. At the same time, notify the tester to perform UAT testing. After all the testing (manual + automation) is completed, upgrade the image to the release library, also known as the production library.

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

Let's see how the above model works:

First you need a Virtual Repository to aggregate three Local and Remote repositories. JFrog Artifactory now supports virtual repositories, providing R & D teams with a unique Docker mirror center access address without the need to switch between multiple mirror centers.

·Official image source for DockerHub used by developers via remote repositories for proxy and caching.

Mirrors are upgraded between three local repositories via the Jenkins pipeline.

End users, such as Docker clients for production environments, access virtual repositories for Docker production environments that provide services to the outside world.

Okay, now that you understand the concept of mirror upgrades, virtual repositories, you might ask, how do you configure permissions for these repositories?

I've drawn the following table to help you understand the basic permissions that different teams should have on mirror repositories at different maturity levels.

Developers only have CRUD permissions on development libraries and no permissions on production libraries, so that developers can avoid mishandling production libraries. The test team will only accept images that are upgraded to the test library through development self-tests, thus reducing the test team's invalid test rate. Operations has CRUD permissions on production libraries. So here you may notice that the CI server has access to all three repositories, which should be mirrored across repositories, tagged, and automated by the CI server.

After reading the above content, do you roughly understand the reasons why Docker image repositories need to be divided into libraries and permissions? If you want to know more about related articles, welcome to pay attention to the industry information channel, thank you for reading!

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.