👨🏻🎓博主介绍：大家好！我是李大白，一名运维容器运维工程师，热爱分享知识🌟
🌈擅长领域：云原生、数据库、自动化运维
🙏🏻如果本文章对小伙伴们有帮助的话，🍭关注+👍🏻点赞+🗣评论+📦收藏！
🤝如果在文章描述时如有错，恳请各位大佬指正，在此感谢！！！
🍂 落叶而知秋，博闻而强识！
📕 精品专栏：Harbor进阶实战（企业级）
本文已参与「开源摘星计划」，欢迎正在阅读的你加入,活动链接。
前言
基于Kubernetes集群搭建的高可用架构是Harbor官方提供的方案。但用户可能出于某种原因无法部署独立的Kubernetes集群，更希望创建基于Harbor离线安装包的高可用方案。
Harbor官方鼓励用户使用Kubernetes集群实现高可用，因为Harbor官方会维护Harbor的Helm Chart版本，并为社区提供技术支持。而基于离线安装包的高可用方案由于用户环境千差万别，需要用户去探索并解决各自环境下的问题。同时，由于官方未提供基于离线安装包的高可用方案，所以也不能提供相应的技术支持。
基于 Harbor 离线安装包搭建高可用系统是一项复杂的任务，需要用户具有高可用的相关技术基础，并深入了解 Harbor 的架构和配置。本节介绍的两种常规模式仅为参考方案，主要说明基于离线安装包实现高可用时，用户需要解决的问题和需要注意的地方。建议先阅读本章的其他内容，理解 Harbor 的安装及部署方式，在此基础上再结合各自的实际生产情况进行修改并实施。
在下面的两种方案中均使用了负载均衡器作为网关，需要用户自行安装并配置负载均衡器。同时，负载均衡器的搭建和配置及如何用负载均衡器调度多个 Harbor 实例，不在本节的讨论范围内。
方案1：基于共享服务的高可用方案
此方案的基本思想是多个Harbor实例共享PostgreSQL、Redis及存储，通过负载均衡器实现多台服务器提供Harbor服务，如图所示。
1）关于负载均衡器的设置
在安装Harbor实例的过程中，需要设置每个Harbor实例的配置文件的external_url项，把该项地址指定为负载均衡器的地址。通过该项指定负载均衡器的地址后，Harbor将不再使用配置文件中的hostname作为访问地址。客户端（Docker和浏览器等）通过external_url提供的地址（即负载均衡器的地址）访问后端服务的API。如果不设置该值，则客户端会依据hostname的地址来访问后端服务的API，负载均衡在这里并没有起到作用。也就是说，服务访问并没有通过负载均衡直接到达后端，当后端地址不被外部识别时（如有NAT或防火墙等情况），服务访问还会失败。
Harbor 实例在使用了 HTTPS，特别是自持证书时，需要配置负载均衡器信任其后端每个Harbor实例的证书。同时，需要将负载均衡器的证书放置于每个Harbor实例中，其位置为harbor.yml配置项中data_volume指定路径下的“ca_download”文件夹中，该文件夹需要手动创建。这样，用户从任意Harbor 实例的UI下载的证书就是负载均衡器的证书，如图所示。
2）外置数据库的配置
用户需要自行创建PostgreSQL共享实例或者集群，并将其信息配置到每个Harbor实例外置的数据库配置项中。注意：外置PostgreSQL需要预先为Harbor Core、Clair、Notary Server及Notary Signer组件分别创建空数据库registry、clair、notary_server及notary_singer，并将创建的数据库信息配置到相应组件外置的数据库信息部分。Harbor在启动时，会自动创建对应数据库的数据库表。
3）外置Redis的配置
用户需要自行创建Redis共享实例或者集群，并将其信息配置到每个Harbor实例外置的Redis配置项中。
4）外置存储的配置
用户需要提供本地或云端共享存储，并将其信息配置到每个 Harbor 实例的外置存储配置项中。
5）多个Harbor实例之间需要共享的文件或者配置
基于离线安装包安装的高可用方案需要保证以下文件在多个实例之间的一致性。同时，由于这些文件是在各个 Harbor 实例的安装过程中默认生成的，所以需要用户手动复制这些文件来保证一致性。
private_key.pem和root.crt文件
Harbor在客户端认证流程中（参考第5章）提供了证书和私钥文件供Distribution创建和校验请求中的Bearer token。在多实例Harbor的高可用方案中，多实例之间需要做到任何一个实例创建的Bearer token都可被其他实例识别并校验，也就是说，所有实例都需要使用相同的private_key.pem和root.crt文件。
如果多实例Harbor之间的这两个文件不同，在认证过程中就可能发生随机性的成功或失败。成功的原因是请求被负载均衡器转发到创建该Bearer token的实例中，该实例可以校验自身创建的bearer token；失败的原因是请求被负载均衡器转发到非创建该Bearer token的实例中，该实例无法解析非自身创建的token，从而导致认证失败。因为private_key.pem文件同时用于机器人账户的JWT token的校验，所以如果不共享此文件，机器人账户的登录也会发生随机性的成功或失败，原因同上。
private_key.pem文件位于harbor.yml配置项data_volume 指定路径的“secret/core”子目录下。root.crt文件位于harbor.yml配置项data_volume 指定路径的“secret/registry”子目录下。
csrf_key
为防止跨站gongji（Cross Site Request Forgery），Harbor启用了csrf的token校验。Harbor会生成一个随机数作为csrf的token附加在cookie中，用户提交请求时，客户端会从cookie中提取这个随机数，并将其作为csrf的token一并提交。Harbor会依据这个值是否为空或者无效来拒绝该访问请求。那么，多实例之间需要做到任何一个实例创建的token都可被其他任意实例成功校验，也就是需要统一各个实例的csrf token私钥值。
用户需要自行创建PostgreSQL共享实例或者集群，并将其信息配置到每个Harbor实例外置的数据库配置项中。注意：外置PostgreSQL需要预先为Harbor Core、Clair、Notary Server及Notary Signer组件分别创建空数据库registry、clair、notary_server及notary_singer，并将创建的数据库信息配置到相应组件外置的数据库信息部分。Harbor在启动时，会自动创建对应数据库的数据库表。
该配置位于Harbor安装目录下的“common/config/core/env”文件中，用户需要把一个Harbor实例的值手动复制到其他实例上，使该值在所有实例上保持一致。
注意：手动修改以上文件或配置时，均需要通过docker-compose重启Harbor实例以使配置生效。另外，如果后续要使用Harbor安装包中的prepare脚本，则需要重复上述手动复制过程，因为该脚本会随机创建字符串并改写以上文件或配置，导致手动复制的文件或配置被覆盖而失效。
方案2：基于复制策略的高可用方案
此方案的基本思想是多个Harbor实例使用Harbor原生的远程复制功能实现Artifact的一致性，通过负载均衡器实现多台服务器提供单一的Harbor服务，如图所示。
负载均衡器的配置及多实例之间需要共享的资源和配置方法同方案1。
方案2与方案1不同的是，在安装Harbor实例时不需要指定外置的PostgreSQL、Redis及存储，每个实例都使用自己独立的存储。Harbor 的多实例之间通过远程复制功能实现Artifact数据的一致性。关于PostgreSQL和Redis的数据一致性问题，需要用户自行实现数据同步的解决方案。基于复制的多实例解决方案，其实时性不如基于共享存储的方案，但相比之下搭建更为简单，用户使用Harbor离线安装包提供的PostgreSQL、Redis即可。
