Docker Harbor private warehouse deployment and management

Harbor is an open source enterprise-level Docker Registry project of VMware, whose goal is to help users quickly build an enterprise-level Docker Registry service.

Based on Docker's open-source Registry, Harbor provides graphical management UI, role-based access control (Role Based Access Control), AD/LDAP integration, and audit logging.

Each component of Harbor is built in the form of a Docker container, and it is deployed using docker-compose. The docker-compose template for deploying Harbor is located at harbor/docker-compose.yml.

Second, the characteristics of Harbor

Role-based control: users and warehouses are organized based on projects, and users can have different permissions in projects
Mirror-based replication strategy: mirrors can be replicated (synchronized) between multiple Harbor instances
Support LDAP/AD: Harbor can integrate the existing AD/LDAP within the enterprise (a table similar to a database) to authenticate and manage existing users
Mirror deletion and garbage collection: mirrors can be deleted, and the space occupied by mirrors can also be reclaimed
Graphical user interface: users can browse through a browser, search mirror warehouses and manage projects
Audit management: All operations on mirror warehouses can be recorded and traced for audit management
Support RESTful API: RESTful API provides administrators with more control over Harbor, making integration with other management software more containerized
The relationship between Harbor Juner docker registry: Harbor is essentially an encapsulation of docker registry, which extends its own business template

3. The composition of Harbor

In terms of architecture, Harbor mainly has six components: Proxy, Registry, Core services, Database (Harbor-db), Log collector (Harbor-log), and Job service.

Proxy: Registry, UI, Token service and other components of Harbor are all behind the nginx reverse proxy. The proxy forwards requests from browsers and docker clients to different backend services
Registry: Responsible for storing Docker images and processing Docker push/pull commands. Due to the 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 legal Token for each Docker pull/push request, and the Registry will pass the public key Decrypt and verify the Token.
Core services: Harbor's core functions, mainly provide the following three services

UI (harnor-ui): Provides a graphical interface to help users manage images on the Registry and authorize users.

WebHook: In order to obtain the status change of the image on the Registry in time, configure a Webhook on the Registry to pass the status change to the UI module.

Token service: Responsible for issuing Tokens for each Docker push/pull command according to user permissions. If the request initiated by the Docker client to the Registry service does not contain a Token, it will be redirected to the Token service, and after obtaining the Token, it will make a new request to the Registry.

Database (harbor-db): 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: Mainly used for image replication, the local image can be synchronized to the remote Harbor instance.
Log collector (harbor-log): Responsible for collecting logs of other components into one place.

Each component of Harbor is built as a Docker container, so it is deployed using Docker Compose.
It is divided into 7 containers to run, and can be viewed by executing the docker-compose ps command in the directory where docker-compose.yml is located. The names are: nginx, harbor-jobservice, harbor-ui, harbor-db, harbor-adminserver, registry , harbor-log.
Among them, harbor-adminserver is mainly used as a back-end configuration data management, and does not have many other functions. All data to be manipulated by harbor-ui is completed through a data configuration management center such as harbor-adminserver.

4. Harbor Deployment

Harbor server 192.168.80.8 docker-ce, docker-compose, harbor-offline
client server 192.168.80.9 docker-ce

1. Deploy Docker-Compose service

Download or upload Docker-Compose

curl -L https://get.daocloud.io/docker/compose/releases/download/1.25.1/docker-compose-`uname -s`-`uname -m` -o /usr/local/bin/docker-compose

chmod +x /usr/local/bin/docker-compose

docker-compose --version

2. Deploy Harbor service

Download or upload the Harbor installer

wget http://harbor.orientsoft.cn/harbor-1.2.2/harbor-offline-installer-v1.2.2.tgz

tar zxvf harbor-offline-installer-v1.2.2.tgz -C /usr/local/

Modify the configuration file installed by Harbor

vim /usr/local/harbor/harbor.cfg

About Harbor.cfg There are two types of parameters in the configuration file: required parameters and optional parameters

hostname: used to access the user interface and register services. It should be the target machine's IP address or a fully qualified domain name (FQDN), such as 192.168.48.10 or hub.kgc.cn. Do not use localhost or 127.0.0.1 as the hostname.
ui_url_protocol: (http or https, default http) the protocol used to access the UI and token/notification services. If notarization is enabled, this parameter must be https.
max_job_workers: mirror copy job threads.
db_password: MySQL database root user password for db_auth.
customize_crt: This attribute can be set to on or off, and it is on by default. When this property is turned on, the prepare script creates a private key and root certificate, which are used to generate/verify registry tokens. Set this property to off when the key and root certificate are provided by an external source.
ssl_cert: path to SSL certificate, only applied when protocol is set to https.
secretkey_path: The secret key path used to encrypt or decrypt the remote register password in the replication policy.

Optional parameters:

These parameters are optional for updates, ie users can leave them as default and update them on the web UI after launching Harbor. If you enter Harbor.cfg, it will only take effect when Harbor is started for the first time, and Harbor.cfg will be ignored for subsequent updates to these parameters.

Note:

If you choose to set these parameters through the UI, make sure to do so immediately after starting Harbor. Specifically, the desired auth_mode must be set before registering or creating any new users in Harbor. When there are users in the system (except the default admin user), auth_mode cannot be changed. The specific parameters are as follows:

Email: Harbor requires this parameter to send "password reset" emails to users, and should only be enabled if this functionality is required. Note that SSL connections are not enabled by default. If the SMTP server requires SSL, but does not support STARTTLS, then SSL should be enabled by setting email_ssl=TRUE.
harbour_admin_password: The initial password of the administrator, which only takes effect when Harbor starts for the first time. Afterwards, this setting will be ignored and the administrator's password should be set in the UI. Note that the default username/password is admin/Harbor12345
auth_mode: The type of authentication used, by default it is db_auth, i.e. the credentials are stored in the database. For LDAP authentication, set this to ldap_auth.
self_registration: enable/disable user registration function. When disabled, new users can only be created by Admin users, and only Admin users can create new users in Harbor. NOTE: When auth_mode is set to ldap_auth, self-registration is always disabled and this flag is ignored.
Token_expiration: The expiration time (in minutes) of the token created by the token service, the default is 30 minutes.
project_creation_restriction: Flag to control which users have permission to create projects. By default, everyone can create a project. If its value is set to "adminonly", only admins can create projects.
verify_remote_cert: On or off, the default is on. This flag determines whether to verify SSL/TLS certificates when Harbor communicates with remote register instances. Setting this property to off will bypass SSL/TLS verification, which is often used when the remote instance has a self-signed or untrusted certificate.

Also, by default, Harbor stores images on the local filesystem. In a production environment, consider using other storage backends instead of local file systems, such as object storage such as S3, Openstack Swift, Ceph, etc. But the common/templates/registry/config.yml file needs to be updated.

3. Start Harbor

cd /usr/local/harbor/
./prepare        #为 harbor 启动的容器生成一些必要的文件（环境）
./install.sh     #启动容器

docker-compose ps

4. Create a new project

Browser access: http://192.168.80.8 Log in to the Harbor interface, the default administrator username and password are admin/Harbor12345

docker login http://127.0.0.1

Download the mirror for testing

docker pull nginx

Tag the image and upload the image to Harbor

docker tag 镜像:标签  仓库IP/项目名称/镜像名:标签
docker tag nginx:latest 127.0.0.1/myproject-uma/nginx:v1

docker push 127.0.0.1/myproject-uma/nginx:v1

You can see this image and related information in the directory myproject-uma on the Harbor interface

5. Upload images on other clients

When other clients log in to Harbor, an error will be reported. The reason for this problem is that the Docker Registry interaction uses HTTPS by default, but the default HTTP service is used to build a private image, so the following error occurs when interacting with a private image

The solution is: when the Docker server starts, add startup parameters and use HTTP access by default.

vim /usr/lib/systemd/system/docker.service
--13行--修改
ExecStart=/usr/bin/dockerd -H fd:// --insecure-registry 192.168.80.8 --containerd=/run/containerd/containerd.sock
或
ExecStart=/usr/bin/dockerd --insecure-registry 192.168.10.23

Restart the service and log in

Download the mirror for testing

Upload image for testing

5. Maintenance and management of Harbor

1. Create a project through Harbor Web

In the Harbor repository, any image must have a project of its own before being pushed to regsitry.
Click "+Project" and fill in the project name. If the project level is set to "Private", do not check it. If it is set as a public warehouse, everyone has read permission for the images under this project, and you don't need to execute "Docker login" on the command line to download the images, and the image operations are consistent with Docker Hub.

2. Create a Harbor user

1) Create a user and assign permissions

2) Add project members

3) Use a common account to operate the image on the client

Delete the above tagged local image

Log out of the current user, then log in with the Suzuka account created above

Download and upload mirrors for testing

3. Check the log

4. Modify the Harbor.cfg configuration file

To change optional parameters in Harbor's configuration file, first stop the existing Harbor instance and update Harbor.cfg; then run the prepare script to populate the configuration; finally recreate and start the Harbor instance

When using docker-compose to manage Harbor, it must be run in the same directory as docker-compose.yml

5. Remove the Harbor service container while retaining the mirrored data/database, and perform migration

1) Remove the Harbor service container

docker-compose down -v

2) Package the image data in the project

6. Redeploy

If redeployment is required, all data in the Harbor service container needs to be removed

cd /usr/local/harbor
docker-compose down -v
rm -r /data/database
rm -r /data/registry