Introduction to the Harbor Architecture of the Enterprise Container Registry Open Source Project

Introduction to the Harbor Architecture of the Enterprise Container Registry Open Source Project

Author: Jiang Tan Zhang Haining

(The author of this article is a core member of the Harbor project team, updated on September 5, 2016.)

1. Harbor Project

VMware recently open sourced the enterprise-level Registry project Harbor, which was developed by the VMware China R&D team. The Harbor project is to help users quickly build an enterprise-level registry service. Based on Docker's open source registry, it provides management UI, role-based access control (Role Based Access Control), mirror remote replication (synchronization), AD/LDAP integration, and audit logging (Audit logging) and other enterprise user requirements It also supports Chinese language, which is good news for the majority of 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  )

2. Architecture introduction

1)    Main components

Harbor is mainly composed of 6 components in architecture:

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

Registry : Responsible for      storing Docker images and handling docker push/pull commands. Since we need to control user access, that is, different users have different read and write permissions for Docker images, the Registry will point to a token service, forcing users to carry a valid token for each docker pull/push request, and the Registry will pass The public key decrypts and verifies the token.

Core services: This is the core function of      Harbor, which mainly provides the following services:

o UI: Provides a graphical interface to help users manage images on the registry and authorize users.

o webhook: In order to obtain the status change of the image on the registry in time, configure the webhook on the Registry and pass the status change to the UI module.

o Token service: responsible for issuing tokens for each docker push/pull command according to user permissions. The request from the Docker client to the Regiøstry service, if it does not contain a token, will be redirected here, and then re-request to the Registry after obtaining the token .

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

       Job Services: Provides the mirror remote replication function, which can synchronize local mirrors to other Harbor instances.

·      Log collector : In order to help monitor the operation of Harbor, it is responsible for collecting logs of other components for future analysis.

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

2)    Realize

Every component of Harbor is built as a Docker container, so naturally we use Docker Compose to deploy it.

In the source code ( https://github.com/vmware/harbor ), the Docker Compose template for deploying Harbor is located at /Deployer/docker-compose.yml. Open this template file and you will find that Harbor consists of 5 containers:

proxy: A      reverse proxy composed of Nginx servers.

registry : A      container instance consisting of Docker's official open source registry image.

ui : the core services in the architecture ,      the code that constitutes this container is the main body of the Harbor project.

mysql : The database container composed of the official MySql image .     

       job services: The remote mirror replication function is realized through the state machine mechanism, including mirror deletion, which can also be synchronized to the remote Harbor instance.

log : The      container running rsyslogd collects logs from other containers in the form of log-driver.

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

3. How it works

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

  1.  docker login

Suppose we deploy Harbor on a virtual machine whose IP is 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 hits enter, the Docker client will make an HTTP GET request to the address "192.168.1.10/v2/". Each container in Harbor is processed through the following steps:

(a) First, the request will be received by the proxy container listening on port 80. According to the preset matching rules, Nginx in the container will forward the request to the registry container in the backend;

(b) On the registry container side, since token-based authentication is configured, the registry will return error code 401, prompting the Docker client to access the URL bound to the token service. In Harbor, this URL points to Core Services;

(c) After the Docker client receives this error code, it will send a request to the URL of the token service, and combine and encode the username and password according to the Basic Authentication specification of the HTTP protocol, and put it in the request header (header);

(d) Similarly, after the request is sent to the proxy container through port 80, Nginx will forward the request to the ui container according to the rules. After the handler of the ui container listening to the token service URL receives the request, it will decode the request header to get the user name, password;

(e) After obtaining the username and password, the code in the ui container will query the database and compare the username and password with the data in the mysql container (Note: the ui container also supports LDAP authentication, in that case The next ui will try to communicate with the external LDAP service and verify the username/password). If the comparison is successful, the ui container will return a status code indicating success, generate a token with the key, and return it to the Docker client in the response body.

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

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

2.   docker push

After the user logs in successfully, use 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 will repeat the login process, first send the request to the registry, and then get 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 for the push operation on the image library/hello-world;

(c) After the token service gets the request forwarded by Nginx, it will access 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, generate a token and return it to the Docker client;

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

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

4. Reference materials

  • This article does not involve the configuration and deployment of the Harbor project itself. For this, please refer to Harbor's documentation on github: https://github.com/vmware/harbor

related articles: 

The principle of remote mirror replication of Harbor Registry open source project

Users are welcome to use the Harbor project and give feedback and suggestions, and welcome to join us to contribute code. If you are a Harbor user or developer, you can apply to join the Harbor open source project WeChat group to facilitate communication. Please scan the QR code below to follow the " Henry Notes " official account, and send the " Join Group " message  in the background of the official account.

 

Guess you like

Origin http://43.154.161.224:23101/article/api/json?id=324441039&siteId=291194637