Docker私服对比

Docker Harbor私有仓库搭建(docker registry/nexus/harbor) - 知乎

使用harbor和nexus作为docker registry_weixin_34088838的博客-CSDN博客

常见的几种开源镜像仓库介绍_Andriy_dangli的博客-CSDN博客_镜像仓库

构建本地私有Docker源-Nexus/Habor/registry对比

一般托管多个制品的情况, 多数情况下都会选择Nexus作为私服制品库, 因为支持多样类型的制品托管, 不过如果仅仅作为docker的私服使用, 那么这三个主流产品哪个更合适一些呢? 今天做个对比看看

对比项 Nexus Habor Registry
架构复杂度 单一容器/jar包运行 Docker Compose 单一容器
最低配置 Nexus Requirements Habor Requirements Registry Requirements
身份认证 支持角色/TLS 支持角色/TLS 支持TLS
Web界面 支持 支持 不支持
用户管理 支持 支持 不支持
LDAP/AD 支持 支持 不支持
Restful API 支持 支持 支持
审计日志 支持 支持 不支持
代理仓库 支持 不支持 不支持
仓库组 支持 不支持 不支持
其他制品类型 支持 不支持 不支持

对比下来其实不难发现, 对于不同用户群体, 其实三种产品的划分界限非常明确, 个人简单总结一下见下表

群体 适用产品 备注
个人/开发者 Registry 可以快速高效部署一个私服
混合团队 Nexus 支持多种制品托管
微服务团队 Habor 支持多样管理和审计支持

因此对我个人而言, 我需要一个简单快速的私服即可, 不需要复杂架构和复杂的角色控制以及多制品托管需求, 如果对Nexus搭建感兴趣, 可以看这篇

搭建Registry

Deploy a registry server | Docker Documentation

Registry - Official Image | Docker Hub

Docker Registry - 废物大师兄 - 博客园

官方给出的运行命令

1
2
3
4
5
6
7
8
9
10
mkdir -p certs
docker run -d \
--restart=always \
--name registry \
-v "$(pwd)"/certs:/certs \
-e REGISTRY_HTTP_ADDR=0.0.0.0:443 \
-e REGISTRY_HTTP_TLS_CERTIFICATE=/certs/domain.crt \
-e REGISTRY_HTTP_TLS_KEY=/certs/domain.key \
-p 443:443 \
registry:2

结合本地持久化需求, 总结一下运行命令如下

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
DATA_DIR=${PWD}
EXPOSE_PORT=443
SSL_CERT=</PATH/TO/CERT>
SSL_KEY=</PATH/TO/KEY>

mkdir -p ${DATA_DIR}/{certs,data}
cp ${SSL_CERT} ${DATA_DIR}/certs/domain.crt
cp ${SSL_KEY} ${DATA_DIR}/certs/domain.key

docker run -d \
--restart=always \
--name registry \
-v "${DATA_DIR}"/certs:/certs \
-v "${DATA_DIR}"/data:/var/lib/registry \
-e REGISTRY_HTTP_ADDR=0.0.0.0:443 \
-e REGISTRY_HTTP_TLS_CERTIFICATE=/certs/domain.crt \
-e REGISTRY_HTTP_TLS_KEY=/certs/domain.key \
-p ${EXPOSE_PORT}:443 \
registry:2

Q&A

tls: private key does not match public key

How to verify if a Private Key Matches a Certificate?

这个提示证书和私钥不匹配, 可以通过👆🏻的链接提示进行验证

1
2
openssl x509 -noout -modulus -in cert.crt | openssl md5
openssl rsa -noout -modulus -in privkey.txt | openssl md5

相关的命令解释见图

openssl 命令解释

或使用👇🏻的链接进行在线验证

Certificate Key Matcher - Check whether your private key matches your SSL certificate.

x509: certificate signed by unknown authority

上面验证通过的情况下也有可能Docker Registry不认, 即Docker push时报👆🏻的错误

参见👇🏻链接

Deploy a registry server | Docker Documentation

ssl - Private Docker Registry (with TLS certificate) - Server Fault

官方文档和这个ServerFault的答案均指明了一件事: Registry对于CA颁发的存在中间证书的证书, 需要严格按顺序提供全链证书

cat certificate.(pem|cer|crt) intermediate-certificate.pem ca.pem > domain.crt

如果使用Let's Encrypt或类似的证书颁发机构, 可以直接使用fullchain.cer, 其中已经完全包含了所需的全部证书

修改证书后可以正常上传镜像

pem/pfx/jks转换

HTTPS证书文件格式转换-阿里云开发者社区

安装要求

Registry

Docker Registry | Docker Documentation

The Registry is compatible with Docker engine version 1.6.0 or higher.

Habor

Harbor docs | Harbor Installation Prerequisites

Resource Minimum Recommended
CPU 2 CPU 4 CPU
Mem 4 GB 8 GB
Disk 40 GB 160 GB
Software Version Description
Docker engine Version 17.06.0-ce+ or higher For installation instructions, see Docker Engine documentation
Docker Compose Version 1.18.0 or higher For installation instructions, see Docker Compose documentation
Openssl Latest is preferred Used to generate certificate and keys for Harbor
Port Protocol Description
443 HTTPS Harbor portal and core API accept HTTPS requests on this port. You can change this port in the configuration file.
4443 HTTPS Connections to the Docker Content Trust service for Harbor. Only required if Notary is enabled. You can change this port in the configuration file.
80 HTTP Harbor portal and core API accept HTTP requests on this port. You can change this port in the configuration file.

Nexus

System Requirements

CPU

Performance is primarily bounded by IO (disk and network) rather than CPU. Available CPUs will impact longer running operations and also the thread allocation algorithms of the web container.

Minimum CPUs: 4

Recommended CPUs: 8+

Memory

Configurable Memory Types

Visit the Configuring the Runtime Enviroment page to learn how to change the default memory settings.

JVM Heap Memory

Heap memory stores runtime application objects. A min ( -Xms ) and max ( -Xmx ) value must be specified and the values should be identical.

Increasing the heap memory larger than recommendations or setting the min and max values to be different is not recommended. This will create performance issues causing the operating system to thrash needlessly.

JVM Direct Memory

Only required for OrientDB.

Direct memory is allocated outside of and distinct from heap memory. A max value must be configured if using OrientDB.

Host Physical Memory

The total memory allocated to the entire operating system or virtual hardware, commonly referred to as RAM.

Memory Requirements

The requirements assume there are no other significant memory hungry processes running on the same host.

JVM Heap JVM Direct Host Physical/RAM
Minimum ( default ) 2703MB 2703MB 8GB
Maximum 4GB (host physical/RAM * 2/3) - JVM max heap no limit

Disk Space

Application Directory - The size of this directory varies slightly each release. It currently around 330 MB. It is normal to have multiple application directories installed on the same host over time as repository manager is upgraded.

Data Directory - On first start, repository manager creates the base files needed to operate. The bulk of disk space will be held by your deployed and proxied artifacts, as well as any search indexes. This is highly installation specific, and will be dependent on the repository formats used, the number of artifacts stored, the size of your teams and projects, etc. It's best to plan for a lot though, formats like Docker and Maven can use very large amounts of storage (500Gb easily). When available disk space drops below 4GB the database will switch to read-only mode.

File Systems

Nexus Repository stores multiple kinds of data, with two primary storage requirements:

  1. Embedded data (H2, OrientDB, Elastic Search) requires very responsive, fast storage, ideally local disk
  2. Blob storage (component binaries), which requires moderately responsive, high-capacity storage

File system selection should be made bearing both of these in mind.

File System Embedded data Blob Stores Comment
Local storage Supported Supported Local storage is a good choice for both embedded data and binary storage.
NFS v4 Not Recommended* Supported Most common protocol for network attached storage among Nexus Repository deployments.
Amazon EBS Supported Supported EBS is a viable choice for both embedded data and binary storage.
Amazon EFS Unsupported Supported** EFS isn't sufficiently responsive for embedded data, but is appropriate for binary storage.
Amazon S3 N/A Supported S3 semantics aren't suitable for embedded data, but S3 is popular for binary storage.
SMB, CIFS Unsupported Supported Problems are common with SMB or CIFS-mounted devices for embedded data.
Azure Blob Storage N/A Supported Available for blob storage from Nexus 3.30.0 Pro. For performance reasons, the Azure blob store should be in the same Azure region as the Nexus Repo installation.
Azure Files Unsupported Supported Issues with file handles have been observed when accessing embedded data over SMB.
S3-Compatible Unsupported Some S3-compatible object stores do not support all the features required by Nexus Repository or have subtle compatibiity issues with the AWS Java SDK that NXRM uses. This includes providers such as Ceph S3.
NFS v3 Unsupported Numerous customers have experienced inadequate performance with NFS v3.
GlusterFS Unsupported Split-brain problems and slow performance are common.
FUSE Unsupported FUSE based user-space filesystems are known to be unreliable for Nexus Repository.

** NFSv4.1 or higher can be used for the work directory in small lightly loaded installations, but we have found that it does not provide sufficient performance for anything larger. In general it should be avoided for the work directory.*

*** EFS binary storage may not provide necessary throughput for heavy workloads in all configurations.*