Docker私服对比
Docker Harbor私有仓库搭建(docker registry/nexus/harbor) - 知乎
构建本地私有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
官方给出的运行命令
1 | mkdir -p certs |
结合本地持久化需求, 总结一下运行命令如下
1 | DATA_DIR=${PWD} |
Q&A
tls: private key does not match public key
这个提示证书和私钥不匹配, 可以通过👆🏻的链接提示进行验证
1 | openssl x509 -noout -modulus -in cert.crt | openssl md5 |
相关的命令解释见图
或使用👇🏻的链接进行在线验证
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转换
安装要求
Registry
The Registry is compatible with Docker engine version 1.6.0 or higher.
Habor
| 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
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:
- Embedded data (H2, OrientDB, Elastic Search) requires very responsive, fast storage, ideally local disk
- 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.*