Let me talk a accident cases:
Scene : a large Internet company electricity supplier, using a mirror repository to manage all Docker image. Developers play mirrored uploaded to a unique image library, the test passes, Kubernetes operation and maintenance of the environment take the mirror pulled directly from the library, image library has permissions for all of the CRUD.
Accident : As the mirrored storage capacity is too large, the developer intends to clean up Snapshot of mirroring, the mirror clean-up time, mistakenly production mirror environment were deleted, resulting in on-line problems. Essentially mirroring the lack of distinction between management maturity,
solution : to pass a mirror image by upgrading project, placed in three mirrors warehouse, library development, test library, production library. Different image corresponding to the image library manage different maturity.
You can see from the chart, Michael Huttermann concept in 2012 to show the quality level of the pipeline. The figure meant that each line must have a certain level of quality, especially in a test environment, that is, without automated testing Docker mirror, can not be placed online environment to run. In order to distinguish between products of different maturity, the need for different products for different maturity stages warehouse of products, that is, development libraries, test library, production library.
According to the principle of distinction mirrors the maturity, I recommend mirrored storage on the map. We offer mirrored development libraries for developers, for they will lay mirrored Push to development library, then pushed to the image library, developers began to self-validation. The key information self-validation through, mirroring warehouse copies (also called Promote upgrade) to test the library, and then calls Jenkins pipeline test environment, the implementation of automated test cases, when the test is completed, recording of test results to the metadata of the mirror . Notify testers UAT testing until after all the testing (manual + automatic) is completed, the side mirror to upgrade to the release repository, also known as the production library.
Now we have established three mirrors warehouse for each project, you might ask, do I need to configure three mirrors warehouse address? Here we recommend the following image warehouse model.
Take a look at the above model works:
• First, the need for a virtual warehouse (Virtual Repository) to aggregate three local warehouse (Local) and remote repository (Remote). Currently JFrog Artifactory support virtual warehouse, provide a unique address for accessing the center of the mirror Docker R & D team, without the need to switch between multiple mirror center.
• developers through a remote repository for official proxy and cache mirroring source of DockerHub.
• Mirror, upgrade between three local repository by Jenkins pipeline.
• end users, such as Docker client production environment, access Docker production environment virtual warehouse, the warehouse provides external services.
Well, to understand the image upgrade, after the concept of virtual warehouse, you might ask, how do these rights warehouse configuration?
I drew the following table to help you understand what kind of authority should be substantially different teams with different maturity mirroring warehouse.
Developed only for development library CRUD rights, no rights to the production database, so as to avoid misuse of the development of the production library. The test team only accepted through the development of self-test, test upgrade to the mirror database, which reduces the rate of invalid test test team. Operation and maintenance of production have permission CRUD library. So here you may have noticed that there are three warehouses on the CI server permission, it is mirrored across the warehouse should be copied, playing tag, it is done through automation CI server.
to sum up
Through the development, testing, production of the three libraries are provided separately, to hold Docker mirror different maturity, so easy to do clean-up mirror warehouse, only to clean up image development libraries, while the production library only CI server can upload, operation and maintenance only accept Curry production of mirror, mirror vulnerability scanning, deployed into production. What is the problem discussed welcome message.