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

This article will explain in detail how to understand the Harbor architecture of the enterprise container Registry open source project. The content of the article is of high quality, so the editor shares it for you as a reference. I hope you will have some understanding of the relevant knowledge after reading this article.

1. Harbor project

VMware recently opened up the enterprise Registry project Harbor, which is developed by a team developed by VMware China. The Harbor project is to help users quickly build an enterprise-level registry service. Based on Docker's open source registry, it provides the functions of managing UI, role-based access control (Role Based Access Control), remote image replication (synchronization), AD/LDAP integration, and audit log (Audit logging), as well as native support for Chinese, which is good news for Chinese users. This article will introduce the main components of the Harbor project and explain how Harbor works.

(source code address: https://github.com/vmware/harbor)

two。 Architecture introduction

1) main components

Harbor is architecturally composed of six components:

Proxy:Harbor 's registry, UI, token and other services receive requests from browsers and Docker clients through a front-end reverse proxy, and forward the requests to different back-end services.

Registry: responsible for storing Docker images and processing docker push/pull commands. Since we need to control the access of users, that is, different users have different read and write permissions to Docker image, Registry will point to a token service, forcing users to carry a valid token for each docker pull/push request, and Registry will decrypt and verify the token through the public key.

Core services: this is the core function of Harbor and mainly provides the following services:

O UI: provides a graphical interface to help users manage image on registry and authorize users.

O webhook: in order to get the image state changes on registry in time, configure webhook on Registry and pass the state changes to the UI module.

O token service: responsible for issuing token for each docker push/pull command according to user permissions. Requests made by Docker clients to the Regi ø stry service, if they do not include token, will be redirected here and redirected to Registry after obtaining the token.

Database: provides database services for core services, which is responsible for storing data such as user permissions, audit logs, Docker image grouping information, etc.

Job Services: remote replication of images is provided to synchronize local mirrors to other Harbor instances.

Log collector: to help monitor the operation of Harbor, collect the log of other components for later analysis.

The relationship between the components is shown in the following figure:

2) implementation

Each component of Harbor is built in the form of a Docker container, so it's natural to deploy it using Docker Compose.

In the source code (the Docker Compose template that https://github.com/vmware/harbor), uses to deploy Harbor is located in / Deployer/docker-compose.yml. When you open this template file, you will find that Harbor consists of five containers:

Proxy: a reverse proxy made up of Nginx servers.

Registry: a container instance made up of Docker's official open source registry image.

Ui: the core services in the architecture, and the code that makes up this container is the body of the Harbor project.

Mysql: a database container made up of official MySql images.

Job services: remote mirror replication is implemented through the state machine mechanism, including image deletion and synchronization to remote Harbor instances.

Log: a container that runs rsyslogd and collects logs from other containers in the form of log-driver.

These containers are connected together in the form of Docker link so that they can access each other by container name. For end users, only the service port of proxy (that is, Nginx) needs to be exposed.

3. working principle

Let's take two Docker commands as an example to show how the main components work together.

Docker login

Suppose we deploy Harbor on a virtual machine with an IP of 192.168.1.10. The user initiates a login request to the Harbor service through the docker login command:

# docker login 192.168.1.10

When the user enters the required information and clicks enter, the Docker client sends a HTTP GET request to the address "192.168.1.10/v2/". Each container of Harbor is handled by the following steps:

(a) first, the request will be received by the proxy container listening on port 80. According to the pre-set matching rules, the Nginx in the container forwards the request to the backend registry container

(B) on the side of the registry container, because token-based authentication is configured, registry returns error code 401, prompting the Docker client to access the URL bound by the token service. In Harbor, this URL points to Core Services

(C) after receiving this error code, the Docker client will send a request to the URL of the token service, and according to the Basic Authentication specification of the HTTP protocol, the user name and password will be combined and encoded, and placed in the request header (header).

(d) similarly, after the request is sent to the proxy container through port 80, the Nginx forwards the request to the ui container according to the rules. The ui container listens for the token service URL and decodes the request header to get the user name and password after receiving the request.

(e) after obtaining the user name and password, the code in the ui container will query the database and compare the user name and password with the data in the mysql container (Note: the ui container also supports LDAP authentication, in which case ui will try to communicate with the external LDAP service and verify the user name / password). When the comparison is successful, the ui container returns a status code indicating success, generates a token with the key, and returns it to the Docker client in the response body.

The interaction between components in this process is shown in the following figure:

At this point, a docker login is successfully completed, and the Docker client saves the user name and password encoded in step (c) in a local hidden file.

2. Docker push

After a successful login, the user uses the docker push command to push a Docker image to Harbor:

# docker push 192.168.1.10/library/hello-world

(a) first, the docker client repeats the login process by sending the request to registry and then getting the address of the token service

(B) after that, the Docker client will provide additional information when accessing the token service on the ui container, indicating that it wants to apply for a token to push the image library/hello-world

(C) after the request is forwarded by Nginx, the token service accesses the database to verify whether the current user has permission to push the image. If it has permission, it will encode the image information and the push action, sign it with the private key, and generate token to return to the Docker client.

(d) after getting the token, the Docker client will put the token in the request header and send a request to the registry in an attempt to start pushing the image. After receiving the request, Registry will decode the token with the public key and check it. When everything is successful, the transmission of the image will begin.

We omit the step of proxy forwarding. The following figure depicts the communication process of each component in this process:

On how to understand the enterprise container Registry open source project Harbor architecture to share here, I hope the above content can be of some help to you, can learn more knowledge. If you think the article is good, you can share it for more people to see.

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.