This is a creation in Article, where the information may have evolved or changed.
"Editor's note" This share focuses on managing container mirroring methods in DevOps. In order to explain the principle, more use of harbor as an example.
The main contents include:
- Permission control of Image warehouse in development and production environment;
- The principle of Image remote synchronization (replication);
- Large-scale application of image publishing method;
- Image deletion and space reclamation;
- Registry high Availability design.
Let's start with a brief introduction to the Harbor project. Harbor is an open source enterprise-class registry developed by the VMware China Research and development team to help users quickly build enterprise-class registry services. The project, which has been popular with users for more than 5 months, has gained nearly 1000 likes of stars and more than 200 forks on GitHub. Interested friends can use: Https://github.com/vmware/harbor
Container application is becoming more and more common, the biggest advantage of container is the development of operation and maintenance integration, packaging applications through container mirroring, so that development, testing and publishing have the same operating environment, bringing great convenience. So what is the position of the image in the actual operation?
Let's take a look at the life cycle diagram of this classic Docker container:
As you can see, the associated Arrows for container mirroring are the most, and it goes without saying that mirroring technology is the core of the container. In a nutshell, the container contains a static two-part: a statically stored mirror (images) and a dynamically running containers. Accordingly, the development and operation of the container mainly involves the management of image and runtime (runtime). This article is mainly to share with you is the container image management part.
Permission control for mirrored warehouses in development and production environments
In the enterprise, there are often different development teams responsible for different application projects, and the same as the source code sub-project management, the image also needs to be stored and managed according to the project. Because there are different members of the team, such as project manager, Product Manager, Dev, test, and OPS, each person needs to use the mirror differently, so the appropriate permissions can be assigned according to the role.
For example, testers typically only need read access to the Mirror (pull), developers need read and Write permissions (Push/pull), and project managers can add and remove project members and set their roles in addition to the developer's privileges.
In harbor Registry, there are three roles for each project: Project admin, Developer (developer), and guest (guest). Some projects, such as public images placed in the library, can allow anonymous access, which means that users can access different Docker login, which makes them easy to use. In the whole system, also has the system administrator, has the maintenance mirror synchronization policy, the user addition and deletion and so on permission.
It should be noted that in different environments, a member's role can be different. For example, in the Registry of a development environment, operations personnel generally do not require permissions (or require read-only permissions), whereas in a production environment, operators need to have read and write access to registry. is the harbor Rights Management interface:
The principle of mirroring remote synchronization (replication)
Many users use the same registry in development, Test, and operations, so that the "simple brute" approach is better suited for small teams or simple projects, and it is best to use multiple registry to differentiate between different uses. For example, the container image management reference process.
Registry of the development environment: primarily used by developers, with frequent mirroring changes. When the development is completed, a stable image is generated through the CI system and synchronized to the test registry;
Registry of the test environment: primarily used by testers, the image remains the same. When the test passes, synchronize to the registry of the quasi-production environment;
Registry of quasi-production environment: mainly by the test and operations personnel, the mirror remains the same. When the quasi-production environment is tested, the registry of the production environment is finally synchronized;
Registry of the production environment: publish the image to run in the production environment.
The Build-ship-run process of container mirroring is implemented throughout the process from development to production. Harbor provides the ability to automatically synchronize and replicate images between registry, simplifying management.
Large-scale application of image publishing method
In the actual production operations, it is often necessary to publish the image to dozens of or hundreds of cluster nodes. At this point, a single registry can no longer meet the download requirements of a large number of nodes, so configure multiple registry instances for load balancing. It is tedious to maintain the image on multiple registry instances by hand. Harbor can support a master multi-slave image publishing mode, can solve the problem of large-scale image publishing.
As soon as it is released to a registry, the image is synchronized to multiple registry like "Fairy Blossom" and is efficient and reliable.
If it is a cluster with a wide geographical distribution, you can also use a hierarchical approach, such as synchronizing from the group headquarters to the provincial company, from the provincial company to the city company:
During the synchronization process, if the source image is deleted, Harbor automatically synchronizes the remote mirror deletion. In the process of mirroring synchronous replication, harbor monitors the entire replication process, encounters network errors, and retries automatically.
This is the monitor screen for synchronous replication:
Image deletion and Space reclamation
The Docker command does not provide the registry image removal feature, which, over the years, will generate a lot of useless mirrors that occupy a lot of storage space. To remove a mirror and reclaim space, you need to call the Docker Registry API to do it, which is cumbersome. Harbor provides a visual image removal interface that allows you to logically delete a mirror. The space of the garbage image can be recycled in the maintenance state.
Registry high Availability design.
Registry high Availability (HA) is a concern for most production systems, and the basic requirement is that there is no single point of failure. It is often necessary to determine the technology used, based on the time allowed for service disruption, and the cost and loss that can be sustained. Here are 3 scenarios for HA:
A more standard scenario is that multiple registry instances share the same back-end storage, and any one instance persists to the stored mirror and can be read by other instances. Through the request of the forward lb, it can be divided into different instances to deal with, realize the load balance, and avoid the single point of failure.
It should be pointed out that the problems to be considered in practice are far more complex than the above models. For example, the selection of shared storage, the user session is shared on different instances, and so on. Users can design different solutions according to their own business requirements. Harbor will launch a solution based on Swift distributed storage and shared session (using Redis) to meet the needs of users.
If there is no shared storage, another option is to replicate the image with a two-master replication strategy between two nodes. Even if one instance fails, another instance can still provide services to some extent to meet the needs of HA.
The 3rd scenario is to use an existing HA platform, such as Vsphere ha, with the distributed storage Vsan, to achieve Harbor ha, the specific architecture is as follows:
In the event of a node failure, vsphere automatically switches to a good node and the image data is not lost.
We take open source Harbor as an example, summed up the use of registry and key points, I hope to be helpful to everyone. You are welcome to use harbor and feedback, you can also join Harbor Open Source project group discussion. Harbor's GitHub address: Https://github.com/vmware/harbor.
Q&a
Q:master-slave Mirror Schema, if the image in slave registy is deleted, will it automatically sync automatically from Master reg?
A: If you stop and then restart the replication policy, you can synchronize the deleted image.
Q: For multiple production, multiple warehouses, which way is the high-availability plan? First, can a single point of failure occur with shared storage storage?
A: Shared storage is only suitable for the same data center, and multiple origin delays are too large for shared storage.
How is synchronization implemented between Q:registry?
A:registry API.
Q: In the storage this block consider providing plug-in way can call external modules, such as plug-in support S3 this object storage?
A:harbor supports other storage methods, see Harbor documentation.
The above content is organized according to the August 18, 2016 night group sharing content. Share people
Zhang Haining (Henry Zhang), chief architect of cloud native applications at VMware China Research and Development Center, Harbor Open Source Enterprise Container Registry project leader, Cloud Foundry one of the earliest technical evangelists in the Chinese community. The VMware China Research and Development Center is responsible for technical evangelism and solution promotion in the fields of open source platform cloud Foundry, Big Data virtualization, software defined storage, etc. At present, we focus on the research and development of cloud-native applications, including container, PaaS, IaaS and so on. Dockone Weekly will organize the technology to share, welcome interested students add: Liyingjiesz, into group participation, you want to listen to the topic or want to share the topic can give us a message.
