搭建本地Docker私有仓库 与 Harbor私有仓库的部署与管理

搭建本地Docker私有仓库 与 Harbor私有仓库的部署与管理

一.Harbor简介

1.1 harbor背景

• Harbor是VMware公司的开源级的企业级DockerRegistry(仓库)项目，项目地址为 https://github.com/vmware/harbor.
• Harbor的目标是帮助用户迅速搭建一个企业级的DockerRegistry服务。
• Harbor以docker公司开源的registry为基础，提供了管理UI，基于角色的访问控制（Role Based Access Control），AD/LDAP集成，以及审计日志（Auditlogging）等企业用户需求的功能，同时还原生支持中文。
• Harbor的每个组件都是以Docker容器的形式构建的，使用docker-compose来对它进行部署。用于部署Harbor的docker-compose模板位于/usr/local/bin/harbor/docker-compose.yml(自定义)

1.2 harbor的特性

• 基于角色控制：用户和仓库都是基础项目进行组织的，而用户基于项目可以拥有不同的权限。
• 基于镜像的复制策略：镜像可以在多个Harbor实例之间进行复制。
• 支持LDAP：Harbor的用户授权可以使用已经存在的用户。
• 镜像删除和垃圾回收：image可以被删除并且回收image占用的空间。
• 用户UI：用户可以轻松的浏览、搜索镜像仓库以及对项目进行管理。
• 简单的部署功能：harbor提供了online、offline安装，此外还提供了virtualappliance安装
• harbor和docker registry的关系：harbor实质上是对docker registry做了封装，扩展了自己的业务模板。

1.3 harbor的架构组成

• harbor主要有6大模块，默认的每个harbor的组件都被封装成一个docker container，所以可以通过compose来部署harbor，总共分为8个容器运行，通过docker-compose ps来查看

• 

• 1. Proxy: Harbor的registry、UI、token services等组件，都处在一个反向代理后边。该代理将来自浏览器、docker clients的请求转发到后端服务上。
  2. Registry: 负责存储Docker镜像，以及处理Docker push/pull请求。因为Harbor强制要求对镜像的访问做权限控制， 在每一次push/pull请求时，Registry会强制要求客户端从token service那里获得一个有效的token。
  3. Core services: Harbor的核心功能，主要包括如下3个服务:
  4. UI: 作为Registry Webhook, 以图像用户界面的方式辅助用户管理镜像。1) WebHook是在registry中配置的一种机制， 当registry中镜像发生改变时，就可以通知到Harbor的webhook endpoint。Harbor使用webhook来更新日志、初始化同步job等。 2) Token service会根据该用户在一个工程中的角色，为每一次的push/pull请求分配对应的token。假如相应的请求并没有包含token的话，registry会将该请求重定向到token service。 3) Database 用于存放工程元数据、用户数据、角色数据、同步策略以及镜像元数据。
  5. Job services: 主要用于镜像复制，本地镜像可以被同步到远程Harbor实例上。
  6. Log collector: 负责收集其他模块的日志到一个地方

1.4：harbor配置文件参数

• vim /usr/local/harbor/harbor.cfg，关于 Harbor.cfg 配置文件中有两类参数：所需参数和可选参数

• 1、所需参数：这些参数需要在配置文件 Harbor.cfg 中设置。如果用户更新它们并运行 install.sh脚本重新安装 Harbour，参数将生效。具体参数如下

  hostname：用于访问用户界面和 register 服务。它应该是目标机器的 IP 地址或完全限 定的域名（FQDN），例如 192.168.195.128 或 hub.kgc.cn。不要使用 localhost 或 127.0.0.1 为主机名。

  ui_url_protocol：（http 或 https，默认为 http）用于访问 UI 和令牌/通知服务的协议。如果公证处于启用状态，则此参数必须为 https。

  max_job_workers：镜像复制作业线程。

  db_password：用于db_auth 的MySQL数据库root 用户的密码。

  customize_crt：该属性可设置为打开或关闭，默认打开。打开此属性时，准备脚本创建私钥和根证书，用于生成/验证注册表令牌。

  当由外部来源提供密钥和根证书时，将此属性设置为 off。

  ssl_cert：SSL 证书的路径，仅当协议设置为 https 时才应用。

  secretkey_path：用于在复制策略中加密或解密远程 register 密码的密钥路径。

• 2、可选参数：这些参数对于更新是可选的，即用户可以将其保留为默认值，并在启动 Harbor 后在 Web UI 上进行更新。如果进入 Harbor.cfg，只会在第一次启动 Harbor 时生效，随后对这些参数 的更新，Harbor.cfg 将被忽略。

  注意：如果选择通过UI设置这些参数，请确保在启动Harbour后立即执行此操作。具体来说，必须在注册或在 Harbor 中创建任何新用户之前设置所需的

  auth_mode。当系统中有用户时（除了默认的 admin 用户），auth_mode 不能被修改。具体参数如下：

  Email：Harbor需要该参数才能向用户发送“密码重置”电子邮件，并且只有在需要该功能时才需要。

  请注意，在默认情况下SSL连接时没有启用。如果SMTP服务器需要SSL，但不支持STARTTLS，那么应该通过设置启用SSL email_ssl = TRUE。

  harbour_admin_password：管理员的初始密码，只在Harbour第一次启动时生效。之后，此设置将被忽略，并且应 UI中设置管理员的密码。

  请注意，默认的用户名/密码是 admin/Harbor12345。

  auth_mode：使用的认证类型，默认情况下，它是 db_auth，即凭据存储在数据库中。对于LDAP身份验证，请将其设置为 ldap_auth。

  self_registration：启用/禁用用户注册功能。禁用时，新用户只能由 Admin 用户创建，只有管理员用户可以在 Harbour中创建新用户。

  注意：当 auth_mode 设置为 ldap_auth 时，自注册功能将始终处于禁用状态，并且该标志被忽略。

  Token_expiration：由令牌服务创建的令牌的到期时间（分钟），默认为 30 分钟。

  project_creation_restriction：用于控制哪些用户有权创建项目的标志。默认情况下， 每个人都可以创建一个项目。

  如果将其值设置为“adminonly”，那么只有 admin 可以创建项目。

  verify_remote_cert：打开或关闭，默认打开。此标志决定了当Harbor与远程 register 实例通信时是否验证 SSL/TLS 证书。

  将此属性设置为 off 将绕过 SSL/TLS 验证，这在远程实例具有自签名或不可信证书时经常使用。

  另外，默认情况下，Harbour 将镜像存储在本地文件系统上。在生产环境中，可以考虑 使用其他存储后端而不是本地文件系统，

  如 S3、Openstack Swif、Ceph 等。但需要更新 common/templates/registry/config.yml 文件。

1.5：部署Harbor私有仓库

• 服务器设置

  主机名	IP地址	所需软件
  harbor	192.168.233.132	docker-ce、harbor、docker-compose
  client	192.168.233.133	docker-ce

• 两台主机都安装docker-ce，harbor服务器还需要安装docker-compose，不在赘述

  chmod +x docker-compose
  cp docker-compose /usr/local/bin/
  docker-compose -v
  "由于Harbor镜像仓库的镜像管理要用到compose所以compose是预安装环境"
  
     
     
  
     
     
  

1.6.2：Harbor用户管理

• 

  

  

  

• 客户端账号登陆以及下载上传镜像

  [root@localhost ~]# docker logout http://192.168.100.200
  [root@localhost ~]# docker login -u zhangsan -p Harbor12345 http://192.168.100.200
  [root@localhost ~]# docker pull 192.168.100.200/accp/nginx:v1
  v1: Pulling from accp/nginx
  d121f8d1c412: Pull complete 
  ebd81fc8c071: Pull complete 
  655316c160af: Pull complete 
  d15953c0e0f8: Pull complete 
  2ee525c5c3cc: Pull complete 
  Digest: sha256:794275d96b4ab96eeb954728a7bf11156570e8372ecd5ed0cbc7280313a27d19
  Status: Downloaded newer image for 192.168.100.200/accp/nginx:v1
  192.168.100.200/accp/nginx:v1
  [root@localhost ~]# docker tag 192.168.100.200/accp/nginx:v1 192.168.100.200/accp/nginx:v2
  [root@localhost ~]# docker images
  REPOSITORY                     TAG                 IMAGE ID            CREATED             SIZE
  192.168.100.200/accp/nginx     v1                  7e4d58f0e5f3        13 days ago         133MB
  192.168.100.200/accp/nginx     v2                  7e4d58f0e5f3        13 days ago         133MB
  192.168.100.200/accp/centos7   v1                  7e6257c9f8d8        6 weeks ago         203MB
  centos                         7                   7e6257c9f8d8        6 weeks ago         203MB
  '
  [root@localhost ~]# docker tag 192.168.100.200/accp/nginx:v1 192.168.100.200/accp/nginx:v2			"打标签"
  [root@localhost ~]# docker push 192.168.100.200/accp/nginx:v2	"上传
  [root@localhost ~]# docker tag 192.168.100.200/accp/nginx:v1 192.168.100.200/accp/nginx:v3
  [root@localhost ~]# docker push 192.168.100.200/accp/nginx:v3
  The push refers to repository [192.168.100.200/accp/nginx]
  908cf8238301: Layer already exists 
  eabfa4cd2d12: Layer already exists 
  60c688e8765e: Layer already exists 
  f431d0917d41: Layer already exists 
  07cab4339852: Layer already exists 
  v3: digest: sha256:794275d96b4ab96eeb954728a7bf11156570e8372ecd5ed0cbc7280313a27d19 size: 1362