当前位置：首页 > news >正文

企业级容器镜像仓库Harbor：从核心架构到高可用部署与运维实战

news 2026/8/16 9:57:15

1. 从“镜像仓库”到“企业级制品中心”：Harbor的定位与价值

如果你在容器化这条路上已经走了一段时间，那么“镜像仓库”这个词对你来说一定不陌生。从最开始的Docker Hub，到后来自己用Docker Registry搭个私有仓库，这几乎是每个团队的必经之路。但当你团队规模扩大，项目数量激增，镜像从几十个变成几百上千个，并且开始涉及安全扫描、权限管控、多环境分发这些需求时，你会发现，一个简单的Registry已经有点力不从心了。这时候，一个更强大的工具就该登场了，它就是Harbor。

Harbor，直译过来是“港湾”，这个名字非常贴切。它不仅仅是一个存放容器镜像的仓库，更是一个为企业级云原生应用提供制品（Artifact）全生命周期管理的“安全港湾”。它由VMware公司（现为Broadcom旗下）中国团队开源，现在是CNCF（云原生计算基金会）的毕业项目，这意味着它的成熟度和社区活跃度都得到了业界的广泛认可。简单来说，Harbor在基础的镜像存储和分发功能之上，集成了企业最关心的几大核心能力：基于角色的访问控制（RBAC）、镜像漏洞扫描、镜像签名与内容信任、多租户管理、跨仓库复制、以及一个直观的Web管理界面。

为什么说它解决了从“能用”到“好用”、“敢用”的关键问题？举个例子，早期我们用自建的Docker Registry，权限管理基本靠防火墙策略，谁都能推能拉；镜像有没有安全漏洞？不知道，只能等运行时出问题；生产环境的镜像和测试环境的怎么保证一致？靠人工记录和自觉。而Harbor把这些都变成了可配置、可审计、自动化的流程。它让镜像从开发者的本地环境，到测试、预发布、生产环境的流转，变成了一条清晰、可控、安全的流水线。对于运维和安全团队而言，Harbor提供了治理的抓手；对于开发团队而言，它提供了自助服务和效率提升的工具。接下来，我们就深入Harbor的内部，看看它是如何构建起这座“港湾”的。

2. Harbor的核心架构与组件拆解：不只是个带UI的Registry

要理解Harbor的强大之处，必须先弄明白它的内部构造。很多人初次接触Harbor，会以为它只是一个给Docker Registry套了个Web壳子的东西。这个理解就太片面了。Harbor是一个由多个独立组件构成的分布式系统，这些组件协同工作，共同提供了远超单一Registry的功能。典型的Harbor高可用部署会包含以下核心组件，理解它们各自的责任，是后续运维和排错的基础。

Core（核心服务）：这是Harbor的大脑和API网关。所有通过Web UI、命令行工具（如docker client）或其他系统（如CI/CD流水线）发起的请求，首先都会到达Core服务。它负责处理用户认证、权限校验、项目管理、Webhook触发等所有业务逻辑，并协调其他组件完成具体任务。比如，当你通过docker push推送镜像时，docker client实际上是在和Core服务通信，由Core来验证你的权限，并最终指示Registry组件存储数据。

Registry：这就是我们熟悉的那个容器镜像仓库（Docker Distribution）。在Harbor中，它被深度集成，主要负责镜像和Chart（Helm包）等制品二进制数据的实际存储、上传和下载。Harbor对原生的Registry进行了增强，使其能够与Harbor的数据库（用于存储元数据）进行交互。

Portal（Web UI）：提供图形化管理界面。通过它，管理员可以管理用户、项目、配置复制策略；开发者可以浏览镜像、查看漏洞报告、管理自己的项目成员。它是Harbor易用性的重要体现。

Database：通常使用PostgreSQL或MySQL。它存储了Harbor所有的元数据，包括用户信息、项目信息、机器人账户、权限策略、复制任务日志、系统配置等。这里有一个非常重要的注意点：镜像本身的层数据（blobs）和清单（manifests）是存储在Registry后端的存储系统（如文件系统、S3）中的，而描述这个镜像属于哪个项目、谁创建的、有哪些标签等“描述信息”则存在数据库里。两者必须保持一致，系统才能正常工作。

Jobservice：这是Harbor的“后台任务引擎”。所有异步的、耗时的任务都交给它来处理。最典型的就是镜像复制和漏洞扫描。当你设置了一个从北京仓库复制到上海仓库的策略后，Core服务会创建一个复制任务扔到Jobservice的队列里，Jobservice会异步地执行拉取、推送的全过程。同样，触发镜像扫描后，具体的扫描工作也是由Jobservice调度扫描器组件来完成的。这种设计避免了前端请求被长时间阻塞。

Redis：用作Jobservice的任务队列缓存、Core服务的会话（Session）存储以及一些临时数据的缓存。它是保证系统性能和无状态扩展的关键组件。

Trivy/Scanner Adapter：漏洞扫描器。Harbor默认集成了Trivy（从2.0版本开始），这是一个当前非常流行且开源的漏洞扫描工具。它会拉取镜像的每一层，与CVE（通用漏洞披露）数据库进行比对，生成详细的漏洞报告。Harbor也支持通过Adapter模式接入其他扫描器，如Anchore、Clair等，提供了灵活性。

Notary：提供内容信任（Content Trust）服务，即镜像签名和验证。它可以确保你拉取的镜像确实来自可信的发布者，且在传输过程中未被篡改。这对于保障供应链安全至关重要。

这些组件通常以容器化的方式运行，通过Docker Compose或Kubernetes Helm Chart进行部署和编排。它们之间通过内部网络通信，共同构成了一个功能完备的企业级制品仓库。

3. 实战部署：从零搭建一个高可用的Harbor集群

了解了架构，我们动手搭建一个。对于生产环境，单节点部署存在单点故障风险，因此高可用（HA）部署是必须的。这里我们以使用外部数据库（PostgreSQL）和外部Redis，并配置共享对象存储（如S3/MinIO）的方案为例，这是最经典、扩展性最好的HA架构。它确保了无状态组件（Core, Jobservice, Portal）可以水平扩展，而有状态的数据（数据库、Redis、镜像存储）被外置并共享。

3.1 环境与依赖准备

首先，你需要准备：

至少两台Linux服务器（虚拟机或物理机），作为Harbor服务节点。系统建议使用Ubuntu 20.04/22.04 LTS或CentOS/RHEL 8+。
一个高可用的PostgreSQL集群（如Patroni + etcd，或云厂商的RDS服务）。记下连接地址、端口、数据库名、用户名和密码。
一个高可用的Redis集群（如Redis Sentinel或云厂商服务）。记下连接地址和端口。
一个共享对象存储。可以是AWS S3、阿里云OSS、腾讯云COS，或者自建的MinIO集群。确保所有Harbor节点都能访问这个存储桶（Bucket），并准备好Access Key和Secret Key。
域名与SSL证书：为Harbor准备一个域名（如harbor.yourcompany.com），并申请一个受信任的SSL证书（或使用Let‘s Encrypt自动签发）。切勿在生成环境使用自签名证书，这会导致所有客户端都需要额外配置，带来巨大的运维负担。

在所有Harbor节点上，安装必要的依赖：

# Ubuntu/Debian sudo apt-get update sudo apt-get install -y apt-transport-https ca-certificates curl software-properties-common # CentOS/RHEL sudo yum install -y yum-utils device-mapper-persistent-data lvm2

安装Docker和Docker Compose（如果使用Compose部署）：

# 安装Docker curl -fsSL https://get.docker.com -o get-docker.sh sudo sh get-docker.sh sudo systemctl enable docker sudo systemctl start docker # 安装Docker Compose Plugin (推荐，替代旧的docker-compose二进制文件) sudo apt-get update # For Ubuntu sudo apt-get install -y docker-compose-plugin # 验证 docker compose version

3.2 下载与配置Harbor安装包

访问Harbor的GitHub Release页面，下载最新稳定版的离线安装包（包含所有镜像，便于内网部署）。例如：

wget https://github.com/goharbor/harbor/releases/download/v2.10.0/harbor-offline-installer-v2.10.0.tgz tar xzvf harbor-offline-installer-v2.10.0.tgz cd harbor

关键的配置文件是harbor.yml。我们需要重点修改以下部分：

# 主机名：必须配置为访问Harbor的域名 hostname: harbor.yourcompany.com # HTTPS配置 https: port: 443 # 你的证书和私钥路径 certificate: /data/cert/yourdomain.com.crt private_key: /data/cert/yourdomain.com.key # 外部数据库配置 external_database: harbor: host: your-pg-host port: 5432 db_name: harbor username: harbor password: your-strong-password ssl_mode: disable # 生产环境建议启用并配置SSL clair: # 如果使用Clair扫描器需要配置 ... notary_signer: ... notary_server: ... # 外部Redis配置 external_redis: host: your-redis-host port: 6379 password: your-redis-password # 如果有的话 # Redis数据库索引，默认0 registry_db_index: 1 jobservice_db_index: 2 chartmuseum_db_index: 3 # 如果启用Helm仓库 trivy_db_index: 4 # 如果使用Trivy扫描器 # 存储后端：配置为S3兼容存储 storage_service: s3: accesskey: YOUR_S3_ACCESS_KEY secretkey: YOUR_S3_SECRET_KEY region: us-east-1 # 你的存储区域 bucket: your-harbor-bucket # 存储桶名称 # 重要：对于MinIO或某些S3兼容服务，需要指定endpoint endpoint: https://minio.yourcompany.com # 如果是MinIO # 是否使用路径风格访问（MinIO通常需要设为true） path_style: true # 是否启用HTTPS secure: true # 跳过证书验证（仅用于测试，生产环境请配置有效证书） skip_verify: false # 数据持久化路径（当使用外部存储时，本地路径仅用于临时数据或缓存） data_volume: /data # 初始化管理员密码 harbor_admin_password: Harbor12345 # 首次登录后务必修改！ # 启用哪些功能 chart: absolute_url: disabled # Helm Chart仓库相关 trivy: ignore_unfixed: false # 漏洞扫描器Trivy配置 skip_update: false jobservice: max_job_workers: 10 # Jobservice工作线程数，根据负载调整 notification: webhook_job_max_retry: 3 # Webhook重试次数

注意：storage_service.s3的配置是重中之重。endpoint和path_style这两个参数根据你的对象存储服务商不同而不同。对于AWS S3，通常不需要设置endpoint；对于自建MinIO，则必须设置。path_style决定了访问URL的格式（虚拟主机风格 vs 路径风格），配置错误会导致无法上传/下载镜像。

3.3 执行安装与初始化

配置好harbor.yml后，将SSL证书文件放到配置中指定的路径（如/data/cert/）。然后执行安装脚本：

sudo ./install.sh

这个脚本会：

加载Docker镜像。
根据harbor.yml生成各个组件的docker-compose配置文件。
启动所有容器。
执行数据库初始化（如果使用内置数据库）。

安装完成后，访问https://harbor.yourcompany.com，使用用户名admin和你在配置文件中设置的密码登录。

3.4 配置负载均衡与高可用

现在你在一台节点上部署成功了。要实现高可用，你需要在另一台（或多台）节点上重复3.1到3.3的步骤，但有一个关键区别：从第二台节点开始，不需要也不应该再次运行./install.sh，因为./install.sh会尝试初始化数据库，而数据库已经被第一台节点初始化过了。

正确的做法是：

在第二台节点上，准备好相同的环境（Docker，证书文件）。
将第一台节点上安装目录（如/opt/harbor）下的harbor.yml和整个common目录（包含生成的配置文件）拷贝到第二台节点的相同路径。
在第二台节点上，直接使用docker-compose命令启动服务：
```
cd /opt/harbor docker compose up -d
```

现在，你有了两个独立运行但共享同一套数据库、Redis和对象存储的Harbor实例。最后一步，在它们前面配置一个负载均衡器（如Nginx, HAProxy, 或云负载均衡器），将流量分发到这两个后端实例。负载均衡器需要配置SSL终止（Termination），并将HTTPS流量以HTTP协议转发到后端的Harbor节点（因为Harbor内部服务已经是HTTP）。同时，需要确保负载均衡器启用了对长连接和较大文件上传（Push镜像）的支持。

至此，一个高可用的Harbor集群就搭建完成了。这种架构下，任何一个Harbor节点宕机，服务都不会中断。

4. 日常运维核心：用户、项目、镜像与安全策略管理

Harbor部署好了，接下来就是日常使用了。它的管理逻辑非常清晰，核心是“项目（Project）”。所有镜像都必须属于一个项目，而所有权限都是围绕项目来设置的。

4.1 用户与权限体系：RBAC实战

Harbor内置了基于角色的访问控制（RBAC）。用户分为系统管理员和普通用户。

系统管理员：拥有整个Harbor实例的所有权限，可以管理所有用户、所有项目、系统配置等。
普通用户：由管理员创建或通过外部认证系统（如LDAP/AD, OIDC）同步而来。普通用户本身没有任何权限，必须被添加到具体的项目中，并赋予角色。

项目角色从低到高主要有：

访客（Guest）：只能拉取（Pull）镜像，不能推送（Push），也不能查看日志等敏感信息。适合只读场景。
开发者（Developer）：可以推送和拉取镜像，可以操作项目内的Helm Chart，但不能管理项目成员或设置扫描、复制等策略。
维护者（Maintainer）：拥有开发者的所有权限，此外可以编辑项目描述、配置Webhook、手动触发镜像扫描和复制。
项目管理员（Project Admin）：拥有项目的最高权限，可以管理项目成员（添加/删除用户并分配角色）、配置镜像保留策略、配置漏洞扫描策略、配置复制策略等。

实操心得：权限分配要遵循最小权限原则。给CI/CD系统的机器人账户（Robot Account）通常只需要Developer角色，用于推送构建好的镜像。给测试环境或某些只读系统（如监控）的账户分配Guest角色。只有团队负责人或核心运维才需要Project Admin角色。避免滥用Project Admin和系统管理员账号。

4.2 镜像生命周期管理：推送、拉取与清理

推送镜像：首先，你需要让Docker客户端信任你的Harbor仓库（因为使用了HTTPS）。如果使用的是受信任的CA签发的证书，则不需要额外配置。如果是内部CA，需要将CA证书放到Docker客户端的信任目录。

# 登录到你的Harbor仓库 docker login harbor.yourcompany.com # 输入用户名和密码 # 给本地镜像打上符合Harbor规范的标签 # 格式：<Harbor域名>/<项目名称>/<镜像名>:<标签> docker tag myapp:latest harbor.yourcompany.com/myproject/myapp:latest # 推送镜像 docker push harbor.yourcompany.com/myproject/myapp:latest

推送成功后，你可以在Harbor的Web UI对应项目的镜像仓库里看到它。

拉取镜像：

docker pull harbor.yourcompany.com/myproject/myapp:latest

镜像清理（垃圾回收）：这是运维中的一个重要环节。当你多次推送不同标签的镜像，或者删除了镜像后，底层的存储层（Registry）并不会立即释放物理空间，因为镜像层可能被其他镜像共享。Harbor提供了镜像保留策略和垃圾回收功能。

保留策略：你可以基于规则（如保留最近N个标签、保留匹配某模式的标签）自动清理旧的镜像标签。这属于“软删除”，只删除元数据（标签），底层数据层还在。
垃圾回收（GC）：在Web UI的“系统管理”->“垃圾回收”中，可以手动或定时执行GC。GC会真正删除那些没有被任何镜像标签引用的数据层（blobs），释放磁盘（或对象存储）空间。重要提示：执行GC期间，Registry会进入只读模式，所有推送操作会被阻止，因此需要在维护窗口进行。

4.3 安全扫描与内容信任：构筑供应链安全防线

这是Harbor区别于简单仓库的核心价值。

漏洞扫描：

全局配置：系统管理员需要在“系统管理”->“漏洞扫描”中，配置默认的扫描器（如Trivy）和扫描计划（如每天凌晨自动扫描所有镜像）。
项目级策略：项目管理员可以在项目设置中，配置“自动扫描镜像”（推送后自动扫描）和“阻止潜在漏洞镜像”（根据严重程度，如Critical或High，阻止该镜像被拉取）。这是一个非常重要的安全门禁。
查看报告：在镜像详情页面，可以查看详细的漏洞报告，包括CVE编号、严重等级、受影响的软件包及版本、修复建议等。你可以基于此决定是否要升级基础镜像或应用依赖。

内容信任（Notary）：内容信任机制确保了镜像的完整性和发布来源可信。它使用基于TUF（The Update Framework）的Notary服务。

启用：在项目设置中启用“内容信任”。

签名：镜像推送者需要在客户端配置Docker Content Trust（DCT），并使用自己的私钥对推送的镜像进行签名。

# 启用DCT并推送签名镜像 export DOCKER_CONTENT_TRUST=1 export DOCKER_CONTENT_TRUST_SERVER=https://harbor.yourcompany.com:4443 docker push harbor.yourcompany.com/myproject/myapp:signed-tag

验证：当其他用户拉取镜像时，如果启用了DCT（export DOCKER_CONTENT_TRUST=1），Docker客户端会自动验证镜像的签名，只有签名有效且来自可信发布者的镜像才会被拉取。这可以有效防止中间人攻击或仓库被篡改后分发恶意镜像。

5. 高级特性与集成：复制、Webhook与CI/CD流水线

当你的业务扩展到多个数据中心或云区域时，Harbor的复制功能就变得不可或缺。

5.1 跨实例镜像复制

复制功能允许你将一个Harbor实例中的项目（或特定镜像）自动同步到另一个Harbor实例。常见场景：

多地容灾与加速：将镜像从中心仓库复制到各个区域的边缘仓库，供当地集群拉取，加速部署并降低网络延迟和出口流量成本。
环境隔离：在开发Harbor中测试通过的镜像，自动复制到生产Harbor，实现物理隔离。

配置步骤：

在目标Harbor实例上，创建一个具有项目管理员以上权限的机器人账户（Robot Account）。
在源Harbor实例的“系统管理”->“注册表”中，添加目标实例为“复制目标”，填写URL和上一步创建的机器人账户凭据。
在需要复制的项目中，进入“复制”选项卡，创建新的复制规则。
选择目标实例、资源过滤器（可以复制整个项目，或按名称/标签过滤镜像）、触发模式（手动、定时、事件驱动——即推送后立即复制）。
保存规则。之后，根据触发模式，镜像就会自动同步过去。所有复制任务的历史和状态都可以在“日志”中查看。

避坑经验：复制大量镜像或单个超大镜像时，可能会因网络超时而失败。建议在Jobservice的配置中调整超时参数（jobservice.job_loggers相关配置），对于不稳定网络，可以考虑分批次手动触发复制。

5.2 Webhook与外部系统集成

Harbor支持Webhook，可以在特定事件发生时（如推送镜像、删除镜像、扫描完成等）向一个预设的URL发送HTTP POST请求， payload中包含事件的详细信息。这是将Harbor集成到外部自动化系统的关键。

典型应用：

CI/CD联动：当开发人员推送一个带有prod标签的镜像到Harbor时，Webhook触发Jenkins或GitLab CI/CD流水线，自动将该镜像部署到生产环境。
安全事件通知：当镜像扫描发现严重（Critical）漏洞时，Webhook触发消息通知（如发送到钉钉、Slack、企业微信）或自动创建JIRA工单给安全团队。
镜像同步审计：记录所有镜像推送/删除事件到外部的审计日志系统（如ELK）。

配置Webhook非常简单，在项目设置的“Webhook”页面添加即可，需要指定目标URL、请求格式（通常为JSON）和触发的事件类型。

5.3 与CI/CD工具无缝对接

以Jenkins Pipeline为例，集成Harbor非常顺畅：

pipeline { agent any environment { HARBOR_CREDENTIALS = credentials('harbor-robot-account') // 在Jenkins中预先配置的凭据 } stages { stage('Build & Push') { steps { script { docker.build("harbor.yourcompany.com/myproject/myapp:${BUILD_NUMBER}") docker.withRegistry('https://harbor.yourcompany.com', 'harbor-robot-account') { docker.image("harbor.yourcompany.com/myproject/myapp:${BUILD_NUMBER}").push() // 也可以推送latest标签 docker.image("harbor.yourcompany.com/myproject/myapp:${BUILD_NUMBER}").push('latest') } } } } stage('Deploy') { // 此处可以触发Kubernetes部署，或者等待Webhook触发另一条流水线 steps { echo '镜像已推送至Harbor，触发部署流程...' // 例如调用 kubectl set image ... } } } }

在这个流程中，Jenkins使用一个存储在内部的机器人账户密钥登录Harbor并推送镜像。结合前面提到的Webhook，可以实现推送完成后自动部署。

6. 故障排查与性能调优指南

即使架构再完善，运维中总会遇到问题。这里分享几个常见问题的排查思路和性能优化点。

6.1 常见问题排查链路

问题一：推送镜像失败，报错“unauthorized: authentication required”

排查思路：
1. 检查客户端登录状态：运行docker logout harbor.yourcompany.com然后重新docker login。确保使用的用户名密码或访问令牌（Token）有权限推送至目标项目。
2. 检查项目权限：登录Web UI，确认该用户是否已被添加到目标项目中，并且角色是Developer、Maintainer或Project Admin。
3. 检查网络与代理：如果公司有网络代理，确保Docker客户端配置了正确的代理（HTTP_PROXY/HTTPS_PROXY），并且代理允许访问Harbor的域名和端口。
4. 检查Harbor服务状态：在Harbor服务器上执行docker compose ps或docker ps，查看所有核心容器（特别是harbor-core）是否都处于“Up”状态。
5. 查看Core服务日志：docker logs -f harbor-core，看是否有具体的错误信息，比如数据库连接失败、Redis连接失败等。

问题二：拉取镜像非常慢，或超时

排查思路：
1. 区分网络层与存储层：先尝试从Harbor拉取一个非常小的镜像（如alpine:latest）。如果小镜像也慢，问题可能出在网络或Harbor服务本身。如果小镜像快，大镜像慢，问题可能出在存储后端（如S3/MinIO）的带宽或延迟上。
2. 检查存储后端：如果使用S3/MinIO，登录其管理控制台，查看监控指标（请求延迟、带宽）。检查Harbor所在区域到存储服务区域的网络状况。
3. 检查Harbor节点负载：使用docker stats或top命令查看服务器CPU、内存、磁盘IO情况。重点观察harbor-registry容器的资源使用。
4. 调整Registry配置：对于文件系统存储，磁盘IO可能是瓶颈，考虑使用SSD或更高性能的存储。对于S3存储，可以在registry.yml配置文件中调整storage.s3部分的参数，如chunksize（分块大小，对于大文件上传下载有影响）。

问题三：Webhook触发失败

排查思路：
1. 查看Jobservice日志：Webhook的发送是由Jobservice执行的。查看docker logs -f harbor-jobservice日志，寻找与Webhook相关的错误，如目标URL不可达、连接超时、返回非2xx状态码等。
2. 检查目标服务：确认Webhook配置的URL地址是否正确，且目标服务（如Jenkins）正在运行并可以访问。
3. 检查网络策略：确保Harbor容器网络能够访问到目标服务的网络（考虑防火墙、安全组规则）。
4. 测试Webhook：在Harbor的Webhook配置页面，有“测试”按钮，可以手动发送一个测试事件，这是最直接的验证方式。

6.2 性能调优建议

数据库优化：Harbor的数据库（PostgreSQL/MySQL）是性能关键。确保为数据库实例分配足够的资源（CPU、内存）。对于PostgreSQL，可以调整shared_buffers、work_mem等参数。定期对核心表（如artifact，tag，audit_log）进行清理或归档，防止表过大影响查询性能。
Redis优化：确保Redis有足够内存，并启用持久化。如果Jobservice任务队列堆积严重，可以考虑增加jobservice.max_job_workers（在harbor.yml中）的值，允许并行执行更多任务。
存储后端优化：
- 文件系统：使用高性能本地SSD，并确保data_volume挂载点有充足空间和IOPS。
- 对象存储（S3/MinIO）：启用存储桶的传输加速（如果支持）。对于自建MinIO，可以考虑部署分布式MinIO集群，并将存储桶策略设置为reduced_redundancy（如果可接受）以提升写入速度。
Registry缓存：可以配置Redis作为Registry的缓存层，缓存镜像清单（manifests）等元数据，显著提升频繁拉取相同镜像的速度。这需要在registry.yml配置文件中进行配置。
水平扩展：对于访问量非常大的场景，可以水平扩展无状态组件。通过增加harbor-core和harbor-jobservice的容器副本数（在K8s中通过Deployment的replicas，在Compose中需要借助外部负载均衡手动部署多套），并在前面用负载均衡器分发流量，可以有效提升并发处理能力。

从我自己的运维经验来看，Harbor的稳定性很大程度上依赖于其外部依赖（数据库、Redis、存储）的稳定性。因此，在规划Harbor集群时，对这些外部组件的投入（如使用云托管的RDS、Redis服务，使用高可用的对象存储）往往能起到事半功倍的效果，远比去调优Harbor本身的几个参数来得重要。把Harbor看作一个“状态”的管理者，而把“状态”本身交给更专业的、高可用的服务去存储，是构建稳健企业级制品仓库的最佳实践。

查看全文

http://www.cnnetsun.cn/news/4051924.html