[harbor learning notes] – teach you to quickly build docker private warehouse

[TOC]

The development and operation of docker container applications are inseparable from reliable image management. Although docker officially provides a public image warehouse, it is also very necessary to deploy the registry in our private environment from the perspective of security and efficiency.HarborIt is an enterprise level docker registry management project open source by VMware company. It includes rights management (RBAC), LDAP, log audit, management interface, self registration, image replication, Chinese support and other functions.

All components of harbor are deployed in dcoker, so harbor can be quickly deployed using docker compose.

Note: since harbor is based on docker registry V2 version, docker version must be > = 1.10 0 docker-compose >= 1.6. 0

Harbor’s goal is to help users quickly build an enterprise level docker registry service. itBased on docker's open source registryIn addition, the following functions are provided:

• Role based access control
• Policy based image replication
• Mirror vulnerability scanning
• Ad / LDAP integration (LDAP / ad support)
• Image deletion & garbage collection
• Friendly management UI (graphical user portal)
• Audit logging
• RESTful API
• Easy deployment

Architecture diagram

• https://github.com/goharbor/harbor

Each component of harbor is built in the form of docker container, which can be deployed using docker compose. If kubernetes is used in the environment, harbor also provides kubernetes configuration files.

Harbor is composed of the following containers: UI (harbor’s core service), log (container running rsyslog for log collection), MySQL (database container composed of official MySQL image), nginx (using nginx as reverse agent), Registry (official docker Registry), adminserver (harbor’s configuration data manager), jobservice (Harbor’s task management service) Redis (used to store sessions).

Harbor is an enterprise registry server used to store and distribute docker images. The overall architecture is still very clear. The following is an online architecture diagram:

Harbor dependent external components

• ->Nginx (proxy proxy layer): nginx front-end proxy is mainly used to distribute front-end page UI access and image upload and download traffic; Harbor’s registry, UI, token and other services uniformly receive requests from browsers and docker clients through a front-end reverse proxy, and forward the requests to different back-end services.

• ->Registry V2: image warehouse, which is responsible for storing image files; The docker official image warehouse is responsible for storing docker images and processing docker push / pull commands. Because we need to control users’ access, that is, different users have different read and write permissions on docker image, registry will point to a token service, forcing users to carry a legal token in each docker pull / push request, and registry will decrypt and verify the token through the public key.

• ->Database (MySQL or PostgreSQL): provides database services for core services, and is responsible for storing data such as user permissions, audit logs, docker image grouping information, etc.

Harbor own components

• ->Core services (admin server): This is the core function of harbor. It mainly provides the following services:
  • ->UI: provides a graphical interface to help users manage images on the registry and authorize users.
  • ->Webhook: in order to timely obtain the status changes of the image on the registry, configure webhook on the registry and pass the status changes to the UI module.
  • ->Auth service: responsible for issuing tokens to each docker push / pull command according to user permissions If the request initiated by the docker client to the registry ø ry service does not contain a token, it will be redirected here. After obtaining the token, it will make a request to the registry again.
  • ->API: provide harbor restful API
• ->Replication job service: provides image synchronization between multiple harbor instances.
• ->Log collector: to help monitor harbor operation, it is responsible for collecting logs of other components for later analysis.

Core components

• Proxy: a nginx front-end proxy, which represents the registry, UI, token and other services of harbor- First identified by dark blue

• DB: responsible for storing user permissions, audit logs, dockerimage grouping information and other data.

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

• Jobdevice: jobdevice is responsible for image replication. It communicates with the registry, pulls images from one registry, then pushes them to another registry, and records jobs_ log。 Identified by purple line

• Adminserver: it is the configuration management center of the system. It is attached to check the storage consumption. The configuration of adminserver needs to be loaded when the UI and JObserver are started. Marked by gray line;

• Registry: image warehouse, which is responsible for storing image files. After the image is uploaded, notify the UI to create a repository through the hook. The above figure is marked by a red line. Of course, the token authentication of the registry is also completed through the UI component. Identified by red line

• Log: to help monitor harbor operation, collect logs of other components for later analysis. The logs are summarized by the log driver of docker and identified by light blue lines

  

install

1. Download offline installation package

• Harbor is deployed as a container, so it can be deployed to any Linux distribution that supports docker. To use harbor, you need to install docker and docker compose orchestration tools

• visitharbor release page, download the harbor software tgz package

• Or execute the following commandwget https://storage.googleapis.com/harbor-releases/release-2.0.0/harbor-offline-installer-latest.tgz

• Unzip tgz compressed package

  tar xvf harbor-offline-installer-<version>.tgz

2. Configure harbor cfg （harbor.yml）

Note: the new version is Yaml file, previous version is Conf or Cfg file

• Of the extracted file in the current directoryharbor/Directory

  cd harbor/
  vim harbor.cfg
  harbor_admin_password = Harbor12345
  

3. Start harbor

• After configuration, execute the installation script./install.sh

  #Will pull down several images and check the environment
  Note: docker version: 1.12.5
  Note: docker-compose version: 1.9.0
  
  [Step 0]: checking installation environment ...
  ....
  [Step 1]: loading Harbor images ...
  ....
  [Step 2]: preparing environment ...
  ....
  [Step 3]: checking existing instance of Harbor ...
  ....
  [Step 4]: starting Harbor ...
  ✔ ----Harbor has been installed and started successfully.----
  ...
  For more details, please visit https://github.com/vmware/harbor .

  After the installation is completed, you will find that there is a docker – compose. Exe under the extracted directory harbor YML file, which contains the image that harbor depends on and the information created by the corresponding container

• Execute docker compose PS (docker compose should be executed in the directory containing docker-compose.yml), and ensure that the status of the container is up (Health)

• If the installation goes well, pass it before harbor CFG configured hostname can access the front end

Installation configuration problem

After harbor is installed, you need to usedocker-compose psCommand to check the status and ensure that all docker containers are healthy, otherwise login harbor may fail

If the service does not start normally, check the corresponding log under / var / log / Harbor /

[email protected]:/disk/harbor_v2.0.0$ ls /var/log/harbor/ -lht
Total consumption 22m
-Rw-r -- R -- 1 10000 10000 3.5m December 15 23:03 registryctl log
-Rw-r -- R -- 1 10000 5.4m December 15 23:02 core log
-Rw-r -- R -- 1 10000 4.4m December 15 23:02 portal log
-Rw-r -- R -- 1 10000 4.9M December 15 23:02 registry log
-Rw-r -- R -- 1 10000 1.2m December 15 23:02 proxy log
-Rw-r -- R -- 1 10000 392k December 15 23:00 redis log
-Rw-r -- R -- 1 10000 1.6m December 15 23:00 jobservice log
-Rw-r -- R -- 1 10000 53k December 14 21:42 PostgreSQL log
-Rw-r -- R -- 1 10000 10000 65K July 7 23:35 claim log
-Rw-r -- R -- 1 10000 1.2k July 5 11:43 claim adapter log
-Rw-r -- R -- 1 10000 1.4k July 5 11:38 chartuseum log

To modify the operation configuration of harbor, the following steps are required:

#Stop harbor
 docker-compose down -v
#Modify configuration
 vim harbor.cfg
#Execution/ Prepare has updated the configuration to docker compose YML file
 ./prepare
#Start harbor
 docker-compose up -d

Problem – 1 service startup exception

[email protected]:/opt/harbor$ docker login 192.20.16.51
Username: admin
Password:
Error response from daemon: login attempt to http://192.20.16.51/v2/ failed with status: 502 Bad Gateway

Harbor DB service cannot be started normally. Finally, check PostgreSQL Log found the following message

 | initdb: directory "/var/lib/postgresql/data" exists but is not empty
 | If you want to create a new database system, either remove or empty
 | the directory "/var/lib/postgresql/data" or run initdb
 | with an argument other than "/var/lib/postgresql/data".

Because it was not empty in the / data / datebase directory at that time, docker compose was manually changed YML, thendocker-compose up -dRestart the container and the service is normal

  postgresql:
    image: goharbor/harbor-db:v2.0.0
    container_name: harbor-db
    restart: always
    cap_drop:
      - ALL
    cap_add:
      - CHOWN
      - DAC_OVERRIDE
      - SETGID
      - SETUID
    volumes:
      - /data/database:/var/lib/postgresql/data:z

Question – 2 – dial TCP XXX xxx. xxx. xxx:443: connect: connection refused

# docker login 192.20.16.51:80
Username: admin
Password:
Error response from daemon: Get https://192.20.16.51:80/v2/: http: server gave HTTP response to HTTPS client
perhaps
Error response from daemon: Get https://192.168.31.107/v2/: dial tcp 192.168.31.107:443: connect: connection refused

docker1. Since version 3.2, the default docker registry uses HTTPS, and the default harbor installation uses HTTP protocol. Therefore, when using the docker login, pull, push and other commandsDocker Regsitry other than HTTPSIt will report an error when it is.

Temporary solution: you need to set “secure registers” on each harbor client machine（Thoroughly solve the need to start harbor HTTPS certificate)

• If the system is MacOS, you can click “advanced” in “preference”, add hostname (e.g. docker. Bksx. Com) to “secure registry”, and restart the docker client.

• If the system isUbuntu, modify the configuration file/lib/systemd/system/docker.service, modify the execstart parameter under [service] and add–insecure-registry hostname (e.g. docker.bksx.com)

• If the system isCentos, you can modify the configuration/etc/sysconfig/docker, add options–insecure-registry hostname (e.g. docker.bksx.com)

If it is a new version of docker, there is no docker configuration file in / etc / sysconfig /.

#At daemon Add the following parameters to JSON
[[email protected] harbor]# cat /etc/docker/daemon.json
{
  "insecure-registries": [
    "hostname"
  ]
}

Note: the file must comply with the JSON specification, otherwise docker cannot be started. In addition, hostname must be the same as harbor The hostname in CFG is consistent.

Restart docker after adding:systemctl daemon-reload && systemctl enable docker && systemctl restart docker

After logging in, the account information is saved to the local computer~/.docker/config.json

[email protected]:~/gitee/vnote_notebooks$ docker login 192.168.31.107
Username: admin
Password: 
WARNING! Your password will be stored unencrypted in /home/owen/.docker/config.json.
Configure a credential helper to remove this warning. See
https://docs.docker.com/engine/reference/commandline/login/#credentials-store

Login Succeeded
[email protected]:~/gitee/vnote_notebooks$ cat ~/.docker/config.json 
{
    "auths": {
        "192.168.31.107": {
            "auth": "YWRtaW46SGFyYm9yMTIzNDU="
        }
    },
    "HttpHeaders": {
        "User-Agent": "Docker-Client/19.03.14 (linux)"
    }

Problem – 3 prevents the container process from not having permission to read the generated configuration