docker-harbor镜像仓库搭建

摘要

Harbor是一个用于存储和分发Docker镜像的企业级Registry服务器,通过添加一些企业必需的功能特性,例如安全、标识和管理等,扩展了开源Docker Distribution。作为一个企业级私有Registry服务器,Harbor提供了更好的性能和安全。提升用户使用Registry构建和运行环境传输镜像的效率。Harbor支持安装在多个Registry节点的镜像资源复制,镜像全部保存在私有Registry中, 确保数据和知识产权在公司内部网络中管控。另外,Harbor也提供了高级的安全特性,诸如用户管理,访问控制和活动审计等。

Registry是Dcoker官方的一个私有仓库镜像,可以将本地的镜像打标签进行标记然后push到以Registry起的容器的私有仓库中。企业可以根据自己的需求,使用Dokcerfile生成自己的镜像,并推到私有仓库中,这样可以大大提高拉取镜像的效率。

官方用户手册

Harbor核心组件

  • Proxy:Harbor的registry, UI, token等服务,通过一个前置的反向代理统一接收浏览器、Docker客户端的请求,并将请求转发给后端不同的服务。
  • Registry:负责储存Docker镜像,并处理docker push/pull 命令。由于我们要对用户进行访问控制,即不同用户对Docker image有不同的读写权限,Registry会指向一个token服务,强制用户的每次docker pull/push请求都要携带一个合法的token, Registry会通过公钥对token 进行解密验证。
  • Adminserver:是系统的配置管理中心附带检查存储用量,ui和jobserver启动时候回需要加载adminserver的配置。
  • Core services: 这是Harbor的核心功能,主要提供以下服务:
    • UI:提供图形化界面,帮助用户管理registry上的镜像(image), 并对用户进行授权。
    • webhook:为了及时获取registry 上image状态变化的情况, 在Registry上配置webhook,把状态变化传递给UI模块。
    • token 服务:负责根据用户权限给每个docker push/pull命令签发token. Docker 客户端向Regiøstry服务发起的请求,如果不包含token,会被重定向到这里,获得token后再重新向Registry进行请求。
  • Database:为core services提供数据库服务,负责储存用户权限、审计日志、Docker image分组信息等数据。
  • Job Services:提供镜像远程复制功能,可以把本地镜像同步到其他Harbor实例中。
  • Log collector:为了帮助监控Harbor运行,负责收集其他组件的log,供日后进行分析。

Harbor 特性

  • 基于角色的访问控制 :用户与Docker镜像仓库通过“项目”进行组织管理,一个用户可以对多个镜像仓库在同一命名空间(project)里有不同的权限。
  • 镜像复制 : 镜像可以在多个Registry实例中复制(同步)。尤其适合于负载均衡,高可用,混合云和多云的场景。
  • 图形化用户界面 : 用户可以通过浏览器来浏览,检索当前Docker镜像仓库,管理项目和命名空间。
  • AD/LDAP 支持 : Harbor可以集成企业内部已有的AD/LDAP,用于鉴权认证管理。
  • 审计管理 : 所有针对镜像仓库的操作都可以被记录追溯,用于审计管理。
  • 国际化 : 已拥有英文、中文、德文、日文和俄文的本地化版本。更多的语言将会添加进来。
  • RESTful API : RESTful API 提供给管理员对于Harbor更多的操控, 使得与其它管理软件集成变得更容易。
  • 部署简单 : 提供在线和离线两种安装工具, 也可以安装到vSphere平台(OVA方式)虚拟设备。

Harbor和Registry的比较

Harbor和Registry都是Docker的镜像仓库,但是Harbor作为更多企业的选择,是因为相比较于Regisrty来说,它具有很多的优势。

提供分层传输机制,优化网络传输

Docker镜像是是分层的,而如果每次传输都使用全量文件(所以用FTP的方式并不适合),显然不经济。必须提供识别分层传输的机制,以层的UUID为标识,确定传输的对象。

提供WEB界面,优化用户体验

只用镜像的名字来进行上传下载显然很不方便,需要有一个用户界面可以支持登陆、搜索功能,包括区分公有、私有镜像。

支持水平扩展集群

当有用户对镜像的上传下载操作集中在某服务器,需要对相应的访问压力作分解。

良好的安全机制

企业中的开发团队有很多不同的职位,对于不同的职位人员,分配不同的权限,具有更好的安全性。

Harbor提供了基于角色的访问控制机制

通过项目来对镜像进行组织和访问权限的控制。kubernetes中通过namespace来对资源进行隔离,在企业级应用场景中,通过将两者进行结合可以有效将kubernetes使用的镜像资源进行管理和访问控制,增强镜像使用的安全性。尤其是在多租户场景下,可以通过租户、namespace和项目相结合的方式来实现对多租户镜像资源的管理和访问控制。

Harbor 安装

依赖

  • docker
  • docker-compose

下载安装包

1
2
3
4
5
6
7
8
9
10
11
export VERSION="1.7.4"
export WORKDIR="/data/soft"
mkdir -p ${WORKDIR}
cd ${WORKDIR}
wget https://github.com/goharbor/harbor/archive/v${VERSION}.tar.gz
tar xf v${VERSION}.tar.gz && cd harbor-${VERSION}/make

# 离线安装包
wget https://storage.googleapis.com/harbor-releases/release-1.7.0/harbor-offline-installer-v${VERSION}.tgz
# 在线安装包
wget https://storage.googleapis.com/harbor-releases/release-1.7.0/harbor-online-installer-v${VERSION}.tgz

修改配置harbor/harbor.cfg

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
hostname = 172.16.198.133
ui_url_protocol = https
# https证书位置 需要根据实际情况修改
ssl_cert = /data/cert/172.16.198.133.crt
ssl_cert_key = /data/cert/172.16.198.133.key
# secretkey保存目录
secretkey_path = /data/harbor

# 邮件配置
email_identity =
email_server = smtp.mydomain.com
email_server_port = 25
email_username = sample_admin@mydomain.com
email_password = abc
email_from = admin <sample_admin@mydomain.com>
email_ssl = false
email_insecure = false
# 初始admin密码
harbor_admin_password = Harbor123456

# 是否禁止用户注册
self_registration = off
# 创建项目权限 everyone or adminonly
project_creation_restriction = adminonly

修改docker-compose.yml

1
2
3
4
5
6
# 修改宿主机挂载目录位置
sed -i 's#- /data#- /data/harbor#' docker-compose*.yml
# 修改日志保存位置
sed -i 's#/var/log/harbor#./log#' docker-compose.yml
mkdir /data/harbor
mkdir log

配置https

由于Harbor未附带任何证书,因此默认情况下使用HTTP来提供注册表请求。但是,强烈建议为任何生产环境启用安全性。Harbor有一个Nginx实例作为所有服务的反向代理,您可以使用prepare脚本配置Nginx以启用https。

在测试或开发环境中,您可以选择使用自签名证书,而不是来自受信任的第三方CA的证书。以下内容将向您展示如何创建自己的CA,并使用您的CA签署服务器证书和客户端证书。

生成证书

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
export CERTDIR="/data/cert"
export CN_DOMAIN="172.16.198.133"
mkdir ${CERTDIR}

# 获得证书授权
openssl genrsa -out ca.key 4096

openssl req -x509 -new -nodes -sha512 -days 3650 \
-subj "/C=TW/ST=Taipei/L=Taipei/O=example/OU=Personal/CN=${CN_DOMAIN}" \
-key ${CERTDIR}/ca.key \
-out ${CERTDIR}/ca.crt

# 获得服务器证书

## 创建自己的私钥
openssl genrsa -out ${CERTDIR}/${CN_DOMAIN}.key 4096

## 生成证书签名请求
openssl req -sha512 -new \
-subj "/C=TW/ST=Taipei/L=Taipei/O=example/OU=Personal/CN=${CN_DOMAIN}" \
-key ${CERTDIR}/${CN_DOMAIN}.key \
-out ${CERTDIR}/${CN_DOMAIN}.csr

## 生成注册表主机的证书
cat > v3.ext <<-EOF
authorityKeyIdentifier=keyid,issuer
basicConstraints=CA:FALSE
keyUsage = digitalSignature, nonRepudiation, keyEncipherment, dataEncipherment
extendedKeyUsage = serverAuth
subjectAltName = @alt_names

[alt_names]
DNS.1=yourdomain.com
DNS.2=yourdomain
DNS.3=hostname
EOF

openssl x509 -req -sha512 -days 3650 \
-extfile v3.ext \
-CA ca.crt -CAkey ca.key -CAcreateserial \
-in ${CERTDIR}/${CN_DOMAIN}.csr \
-out ${CERTDIR}/${CN_DOMAIN}.crt

# openssl req -x509 -new -nodes -key ${CERTDIR}/server.key -subj "/CN=${CN_DOMAIN}" -days 5000 -out ${CERTDIR}/server.crt

客户端配置

Docker守护程序将.crt文件解释为CA证书,将.cert文件解释为客户端证书。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
openssl x509 -inform PEM -in ${CERTDIR}/${CN_DOMAIN}.crt -out ${CERTDIR}/${CN_DOMAIN}.cert

mkdir -p /etc/docker/certs.d/${CN_DOMAIN}

scp ${CERTDIR}/${CN_DOMAIN}.cert root@harbor:/etc/docker/certs.d/${CN_DOMAIN}/
scp ${CERTDIR}/${CN_DOMAIN}.key root@harbor:/etc/docker/certs.d/${CN_DOMAIN}/
scp ${CERTDIR}/ca.crt root@harbor:/etc/docker/certs.d/${CN_DOMAIN}/

cat /etc/docker/daemon.json
"insecure-registries": [
"https://${CN_DOMAIN}"
],

systemctl restart docker
docker login ${CN_DOMAIN}

执行安装脚本

1
/usr/local/harbor/install.sh --with-notary --with-clair --with-chartmuseum

管理

1
2
3
4
5
6
启动Harbor
# docker-compose start
停止Harbor
# docker-comose stop
重启Harbor
# docker-compose restart

容器

1
2
3
4
5
6
7
8
9
10
11
12
13
root@ubuntu:~/harbor# docker-compose ps
Name Command State Ports
----------------------------------------------------------------------------
harbor-adminserver /harbor/start.sh Up
harbor-core /harbor/start.sh Up
harbor-db /entrypoint.sh postgres Up 5432/tcp
harbor-jobservice /harbor/start.sh Up
harbor-log /bin/sh -c /usr/local/bin/ ... Up 127.0.0.1:1514->10514/tcp
harbor-portal nginx -g daemon off; Up 80/tcp
nginx nginx -g daemon off; Up 0.0.0.0:443->443/tcp, 0.0.0.0:4443->4443/tcp, 0.0.0.0:80->80/tcp
redis docker-entrypoint.sh redis ... Up 6379/tcp
registry /entrypoint.sh /etc/regist ... Up 5000/tcp
registryctl /harbor/start.sh Up
  • harbor-adminserver:harbor-adminserver是harbor系统管理接口,可以修改系统配置以及获取系统信息。
  • harbor-core:这是Harbor的核心功能,主要提供ui、token、webhook等服务
  • harbor-db:harbor-db是harbor的数据库,这里保存了系统的job以及项目、人员权限管理。由于本harbor的认证也是通过数据,在生产环节大多对接到企业的ldap中;
  • harbor-jobservice:harbor-jobservice 是harbor的job管理模块,job在harbor里面主要是为了镜像仓库之前同步使用的;
  • harbor-log:harbor-log是harbor的日志服务,统一管理harbor的日志。通过inspect可以看出容器统一将日志输出的syslog。
  • nginx:nginx负责流量转发和安全验证,对外提供的流量都是从nginx中转,所以开放https的443端口,它将流量分发到后端的ui和正在docker镜像存储的docker registry。
  • redis:缓存、session等
  • registry:registry就是docker原生的仓库,负责保存镜像。
  • registryctl:harbor与registry交互

升级

  • 升级镜像版本后升级容器,待续。。。

Harbor的镜像同步

为什么需要镜像同步

由于对镜像的访问是一个核心的容器概念,在实际使用过程中,一个镜像库可能是不够用的,下例情况下,我们可能会需要部署多个镜像仓库:

  • 国外的公有镜像下载过慢,需要一个中转仓库进行加速
  • 容器规模较大,一个镜像仓库不堪重负
  • 对系统稳定性要求高,需要多个仓库保证高可用性
  • 镜像仓库有多级规划,下级仓库依赖上级仓库

更常用的场景是,在企业级软件环境中,会在软件开发的不同阶段存在不同的镜像仓库,

  • 在开发环境库,开发人员频繁修改镜像,一旦代码完成,生成稳定的镜像即需要同步到测试环境。
  • 在测试环境库,测试人员对镜像是只读操作,测试完成后,将镜像同步到预上线环境库。
  • 在预上线环境库,运维人员对镜像也是只读操作,一旦运行正常,即将镜像同步到生产环境库。
  • 在这个流程中,各环境的镜像库之间都需要镜像的同步和复制。

Harbor的镜像同步机制

有了多个镜像仓库,在多个仓库之间进行镜像同步马上就成为了一个普遍的需求。比较传统的镜像同步方式,有两种:

  • 第一种方案,使用Linux提供的RSYNC服务来定义两个仓库之间的镜像数据同步。
  • 第二种方案,对于使用IaaS服务进行镜像存储的场景,利用IaaS的配置工具来对镜像的同步进行配置。

这两种方案都依赖于仓库所在的存储环境,而需要采用不同的工具策略。Harbor则提供了更加灵活的方案来处理镜像的同步,其核心是三个概念:

  • 用Harbor自己的API来进行镜像下载和传输,作到与底层存储环境解耦。
  • 利用任务调度和监控机制进行复制任务的管理,保障复制任务的健壮性。在同步过程中,如果源镜像已删除,Harbor会自动同步删除远端的镜像。在镜像同步复制的过程中,Harbor会监控整个复制过程,遇到网络等错误,会自动重试。
  • 提供复制策略机制保证项目级的复制需求。在Harbor中,可以在项目中创建复制策略,来实现对镜像的同步。与Docker Registry的不同之处在于,Harbor的复制是推(PUSH)的策略,由源端发起,而Docker Registry的复制是拉(PULL)的策略,由目标端发起。

高可用集群

主从同步

harbor官方默认提供主从复制的方案来解决镜像同步问题,通过复制的方式,我们可以实时将测试环境harbor仓库的镜像同步到生产环境harbor,类似于如下流程:

在实际生产环境中,往往需要把镜像发布到几十或上百台集群节点上。这时,单个Registry已经无法满足大量节点的下载需求,因此要配置多个Registry实例做负载均衡。手工维护多个Registry实例上的镜像,将是十分繁琐的事情。Harbor可以支持一主多从的镜像发布模式,可以解决大规模镜像发布的难题:

只要往一台Registry上发布,镜像就像“仙女散花”般地同步到多个Registry中,高效可靠。

如果是地域分布较广的集群,还可以采用层次型发布方式

然而单靠主从同步,仍然解决不了harbor主节点的单点问题。

双主复制

所谓的双主复制其实就是复用主从同步实现两个harbor节点之间的双向同步,来保证数据的一致性,然后在两台harbor前端顶一个负载均衡器将进来的请求分流到不同的实例中去,只要有一个实例中有了新的镜像,就是自动的同步复制到另外的的实例中去,这样实现了负载均衡,也避免了单点故障,在一定程度上实现了Harbor的高可用性:

这个方案有一个问题就是有可能两个Harbor实例中的数据不一致。假设如果一个实例A挂掉了,这个时候有新的镜像进来,那么新的镜像就会在另外一个实例B中,后面即使恢复了挂掉的A实例,Harbor实例B也不会自动去同步镜像,这样只能手动的先关掉Harbor实例B的复制策略,然后再开启复制策略,才能让实例B数据同步,让两个实例的数据一致。

另外,我还需要多吐槽一句,在实际生产使用中,主从复制十分的不靠谱。

负载集群

共享后端存储算是一种比较标准的方案,就是多个Harbor实例共享同一个后端存储,任何一个实例持久化到存储的镜像,都可被其他实例中读取。通过前置LB进来的请求,可以分流到不同的实例中去处理,这样就实现了负载均衡,也避免了单点故障:

这个方案在实际生产环境中部署需要考虑三个问题:

  • 共享存储的选取,Harbor的后端存储目前支持AWS S3、Openstack Swift, Ceph、nfs等* Session在不同的实例上共享,这个现在其实已经不是问题了,在最新的harbor中,默认session会存放在redis中,我们只需要将redis独立出来即可。可以通过redis sentinel或者redis cluster等方式来保证redis的可用性。
  • Harbor多实例数据库问题,这个也只需要将harbor中的数据库拆出来独立部署即可。让多实例共用一个外部数据库,数据库的高可用也可以通过数据库的高可用方案保证。

与k8s集成

https://registry.docker-cn.com/

附录

完整配置解析

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
_version = 1.7.0
# 修改harbor地址
hostname = 172.16.198.133
# http or https
ui_url_protocol = https
# job_server中最大job节点数量
max_job_workers = 10
# 是否开启自定义证书
customize_crt = on
# https证书位置
ssl_cert = /data/cert/server.crt
ssl_cert_key = /data/cert/server.key
# secretkey保存目录
secretkey_path = /data/harbor
admiral_url = NA
# 日志相关
log_rotate_count = 50
log_rotate_size = 200M
# 代理相关
http_proxy =
https_proxy =
no_proxy = 127.0.0.1,localhost,core,registry
# 邮件配置
email_identity =
email_server = smtp.mydomain.com
email_server_port = 25
email_username = sample_admin@mydomain.com
email_password = abc
email_from = admin <sample_admin@mydomain.com>
email_ssl = false
email_insecure = false
# 初始admin密码
harbor_admin_password = Harbor123456
# 验证方式 db_auth or ldap_auth
auth_mode = db_auth
# ldap配置
ldap_url = ldaps://ldap.mydomain.com
ldap_basedn = ou=people,dc=mydomain,dc=com
ldap_uid = uid
ldap_scope = 2
ldap_timeout = 5
ldap_verify_cert = true
ldap_group_basedn = ou=group,dc=mydomain,dc=com
ldap_group_filter = objectclass=group
ldap_group_gid = cn
ldap_group_scope = 2
# 是否禁止用户注册
self_registration = off
# token失效时间
token_expiration = 30
# 创建项目权限 everyone or adminonly
project_creation_restriction = adminonly
# 连接数据库配置
db_host = postgresql
db_password = root123
db_port = 5432
db_user = postgres
# 连接redis配置
redis_host = redis
redis_port = 6379
redis_password =
redis_db_index = 1,2,3
# clair_db配置
clair_db_host = postgresql
clair_db_password = root123
clair_db_port = 5432
clair_db_username = postgres
clair_db = postgres
clair_updaters_interval = 12
# uaa认证配置
uaa_endpoint = uaa.mydomain.org
uaa_clientid = id
uaa_clientsecret = secret
uaa_verify_cert = true
uaa_ca_cert = /path/to/ca.pem
# registry配置
registry_storage_provider_name = filesystem
registry_storage_provider_config =
registry_custom_ca_bundle =
  • guilite
  • makisu