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

This article introduces the knowledge of "what is Harbor architecture". In the operation of actual cases, many people will encounter such a dilemma. Then let the editor lead you to learn how to deal with these situations. I hope you can read it carefully and be able to achieve something!

Introduction to Harbor

Harbor is an enterprise-class Registry server for storing and distributing Docker images.

As an enterprise-class private Registry server, Harbor provides better performance and security. Improve the efficiency of users using Registry to build and run the environment to transfer images. Harbor supports replication of image resources installed on multiple Registry nodes, and all images are stored in private Registry to ensure that data and intellectual property rights are controlled in the company's internal network. In addition, Harbor also provides advanced security features, such as user management, access control and activity auditing.

Role-based access control: users and Docker image repositories are organized and managed through a "project". A user can have different permissions for multiple image repositories in the same namespace (project).

Mirror replication: mirrors can be replicated (synchronized) in multiple Registry instances. It is especially suitable for load balancing, high availability, hybrid cloud and cloudy scenarios.

Graphical user interface: users can browse through the browser, retrieve the current Docker image repository, and manage projects and namespaces.

AD/LDAP support: Harbor can integrate the existing AD/LDAP within the enterprise for authentication and authentication management.

Audit management: all operations against the image warehouse can be recorded and traced for audit management.

Internationalization: there are localized versions in English, Chinese, German, Japanese and Russian. More languages will be added.

RESTful API:RESTful API provides administrators with more control over Harbor, making it easier to integrate with other management software.

Easy to deploy: provide both online and offline installation tools, or install to virtual devices on the vSphere platform (OVA mode).

Harbor architecture 1. Master-slave synchronous architecture

Harbor officially provides a master-slave replication solution to solve the image synchronization problem by default. By means of replication, you can synchronize the images of the test environment harbor repository to the production environment harbor in real time, similar to the following process:

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 one-master and multi-slave image publishing mode, which can solve the problem of large-scale image publishing:

As long as it is released to one Harbor, the image will be synchronized to multiple Registry like "Fairy scattered Flowers", efficient and reliable.

If it is a cluster with a wide geographical distribution, you can also adopt a hierarchical release method, such as synchronizing from the computer room of the group headquarters to the first computer room of the branch, and then from the first computer room of the branch to the second computer room of the branch:

However, master-slave synchronization alone can not solve the single point problem of harbor master node. Move on to the following Harbor architecture.

2. Instructions for dual-master replication

In fact, double master replication is to realize two-way synchronization between two harbor nodes by multiplexing master-slave synchronization to ensure data consistency, and then a load balancer on top of the two harbor front ends diverts the incoming requests to different instances. As long as there is a new mirror in one instance, it automatically replicates synchronously to another instance, thus realizing load balancing and avoiding single point of failure. The high availability of Harbor is achieved to some extent:

One problem with this scenario is that the data in the two Harbor instances may be inconsistent. Suppose that if an instance A dies and a new mirror comes in at this time, the new image will be in another instance B. even if the failed An instance is restored, Harbor instance B will not automatically synchronize the mirror. In this way, you can only manually turn off the replication policy of Harbor instance B, and then enable the replication policy, so that the data of instance B can be synchronized and the data of the two instances are consistent.

In addition, there is one more complaint here: in the actual production and use, master-slave replication is very unreliable! Therefore, the architecture scheme described below is recommended here.

3. Multiple instances share back-end storage

Sharing backend storage is a standard solution, that is, multiple Harbor instances share the same backend storage, and any instance persisted to the stored image can be read by other instances. Requests coming in from the front LB can be diverted to different instances for processing, thus achieving load balancing and avoiding a single point of failure.

If there are many servers in the final production environment cluster and the Harbor that relies on the finished LB cannot fully meet the demand, you can use the following architecture to deploy subordinate Harbor nodes to synchronize the images from the master node, and then distribute them to the production servers.

There are three issues to consider when this scenario is deployed in a real production environment:

1. The selection of shared storage. Harbor's back-end storage currently supports AWS S3, Openstack Swift, Ceph and so on. In the next section, we will explain how to deploy this highly available architecture. Aliyun's fast NAS is used for back-end storage.

2. Session is shared on different instances, which is no longer a problem. In the latest harbor, the default session is stored in redis, so you only need to separate redis. The availability of redis can be ensured by means of redis sentinel or redis cluster. However, a single Redis is fine, but the Redis is not highly available.

3. Harbor multi-instance database problem, which only needs to be disassembled and deployed independently of the database in harbor. Let multiple instances share an external database, and the high availability of the database can also be guaranteed by the high availability scheme of the database.

That's all for "what is the Harbor Architecture?" Thank you for reading. If you want to know more about the industry, you can follow the website, the editor will output more high-quality practical articles for you!

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.