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

This article is about how to use Harbor to implement the management and operation and maintenance of container image warehouse. The editor thinks it is very practical, so I hope you can learn something after reading this article. Let's take a look at it with the editor.

This paper mainly describes the method of managing container images in development, operation and maintenance. In order to illustrate the principle, Harbor is often used as an example.

The main contents include:

1) permission control of image warehouse in development and production environment

2) the principle of mirror remote synchronization (replication)

3) large-scale application image publishing method

4) Image deletion and space reclamation

5) Registry high availability design.

Let's start with a brief introduction to the Harbor project. Harbor is an open source enterprise-level Registry developed by the VMware China R & D team, which can help users quickly build enterprise-level registry services. Since its launch more than 5 months ago, the project has been very popular with users, winning nearly 1000 likes and more than 200 forks on GitHub. Interested friends can use: https://github.com/vmware/harbor

The use of container applications is becoming more and more common, and the biggest advantage of containers is the integration of development, operation and maintenance. Through container image packaging applications, the development, testing and release all have the same running environment, which brings great convenience. So what is the position of the mirror image in the actual operation and maintenance?

Let's take a look at the following lifecycle diagram of the classic Docker container:

As you can see from the figure, the container image has the most associated arrows. It goes without saying that the image technology is the core of the container. In a nutshell, the container consists of two parts: a static image (images) and a dynamically running containers. Accordingly, the development, operation and maintenance of the container mainly involves two parts: image management and Runtime management. This article mainly shares with you the part of container image management.

1) permission control of image warehouse in development and production environment

In an enterprise, there are usually different development teams responsible for different application projects, and like source code sub-project management, images need to be stored and managed according to the project. Because there are different members of the team, such as project managers, product managers, developers, tests, and operations and maintenance personnel, each has different needs to use the image, so permissions can be assigned according to the role.

For example, testers usually only need read access to the image (pull), developers need read and write access (push/pull), and project managers can add and delete project members and set their roles in addition to developer permissions.

In Harbor Registry, each project can have three roles: project administrator (project admin), developer (developer), and guest (guest). Some items, such as public images placed in library, can be accessed anonymously, that is, users can also access different docker login, which makes it easy to use. In the whole system, there is also a system administrator, which has the rights of maintaining mirror synchronization policy, adding and deleting users and so on.

It should be pointed out that the roles of a member can be different in different environments. For example, in registry in a development environment, operators generally do not need permissions (or read-only permissions), while in Registry in production environments, operators need read and write permissions. The following figure shows the rights management interface of Harbor:

Registry of the development environment: mainly used by developers, the image changes frequently. 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: mainly used by testers, the image remains the same. When the test passes, synchronize to the Registry of the quasi-production environment

Registry for quasi-production environment: it is mainly used by testing and operation and maintenance personnel, and the image remains unchanged. After the trial operation of the quasi-production environment, finally synchronize the Registry of the production environment

Registry of the production environment: release mirrors to the production environment to run.

The Build-Ship-Run process of container image is realized from development to production. Harbor can provide automatic mirror synchronization and replication between Registry, which simplifies management.

3) large-scale application image publishing method

In the actual production operation and maintenance, it is often necessary to publish the image to dozens or hundreds of cluster nodes. At this time, a single Registry can no longer meet the download needs of a large number of nodes, so it is necessary to configure multiple registry instances for load balancing. Manually maintaining images on multiple registry instances will be a tedious task. Harbor can support the one-master and multi-slave image publishing mode, which can solve the problem of large-scale image publishing.

"during synchronization, if the source mirror has been deleted, Harbor automatically synchronously deletes the remote mirror." During the process of mirror synchronous replication, Harbor monitors the entire replication process and automatically retries when network errors occur.

This is the monitoring screen of synchronous replication:

A more standard solution is that multiple Registry instances share the same backend storage, and any instance persisted to the stored image can be read in other instances. Requests coming in from the LB can be diverted to different instances to achieve load balancing and avoid a single point of failure.

It should be pointed out that the problems to be considered in practice are much more complex than the above model. For example, the selection of shared storage, user session sharing on different instances, and so on. Users can design different schemes according to their own business requirements. Harbor will introduce distributed storage based on swift, as well as a shared session solution (using redis) to meet the needs of users.

If there is no shared storage, another option is to adopt a dual-master replication strategy between the two nodes to replicate the mirror image of each other. Even if one instance fails, another instance can still provide services, which can meet the needs of HA to some extent.

When a node fails, vSphere automatically switches to a good node, and the mirror data is not lost.

The above is how to use Harbor to realize the management and operation and maintenance of container image warehouse. The editor believes that there are some knowledge points that we may see or use in our daily work. I hope you can learn more from this article. For more details, please 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.