1. 部署架构

这个架构所有Harbor共享存储。这个存储包含两个部分：（1）数据库存储（主要包括用户信息、工程信息、日志信息等）。（2）镜像信息。这里我使用的共享存储是AWS的RDS和S3，当然其他任何共享的存储都应该是可以的。

2. 部署过程

2.1 部署Harbor

Harbor的部署方式与单机部署一样，不过需要修改存储相关的部分为共享存储。修改点如下：

1. 修改数据库相关的存储：（1）修改harbor/make/common/templates/ui和harbor/make/common/templates/jobservice下面的env文件，将其中的MYSQL_HOST、MYSQL_PORT、MYSQL_USR等信息改为我的AWS RDS的信息。（2）修改harbor/make/harbor.cfg文件，将其中的db_password密码配置为RDS中用户的密码。

2. 修改镜像相关存储：修改harbor/make/common/templates/registry下的config.yml，将默认的本地存储改为S3.比如我的改完之后信息如下：

   version: 0.1
   log:
     level: debug
     fields:
       service: registry
   storage:
       cache:
           layerinfo: inmemory
       s3:
           accesskey:******
           secretkey:*****
           region: cn-north-1
           bucket:*****
           rootdirectory: /s3/harbor/registry
       maintenance:
           uploadpurging:
               enabled: false
       delete:
           enabled: true
   http:
       addr: :5000
       secret: placeholder
       debug:
           addr: localhost:5001
   auth:
     token:
       issuer: registry-token-issuer
       realm: $ui_url:8080/service/token
       rootcertbundle: /etc/registry/root.crt
       service: token-service
   
   notifications:
     endpoints:
         - name: harbor
           disabled: false
           url: http://ui/service/notifications
           timeout: 3000ms
           threshold: 5
           backoff: 1s

3. 重要：修改harbor/make/common/templates/nginx/nginx.http.conf文件，注释掉其中的location /v2/中的proxy_set_header X-Forwarded-Proto $$scheme;，不然到时候docker pull和push镜像的时候会有问题。

集群内的Harbor都按照这种方式部署。

2.2 部署LB

我是用Nginx做了一个LB，其配置文件如下：

worker_processes auto;

events {
  worker_connections 1024;
  use epoll;
  multi_accept on;
}

http {
  tcp_nodelay on;

  # this is necessary for us to be able to disable request buffering in all cases
  proxy_http_version 1.1;

  upstream harbor {
    ip_hash;
    server xxx.xxx.xxx.xxx:8080;
    server xxx.xxx.xxx.yyy:8080;
  }


  server {
    listen 443; server_name xxxx.com;
    ssl on;
    #root html;
    #index index.html index.htm;
    ssl_certificate   /***/***.pem;
    ssl_certificate_key  /***/***.key;
    ssl_session_timeout 5m;
    ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
    ssl_ciphers AESGCM:ALL:!DH:!EXPORT:!RC4:+HIGH:!MEDIUM:!LOW:!aNULL:!eNULL;
    ssl_prefer_server_ciphers on;
    ssl_session_cache shared:SSL:10m;

    # disable any limits to avoid HTTP 413 for large image uploads
    client_max_body_size 0;

    # required to avoid HTTP 411: see Issue #1486 (https://github.com/docker/docker/issues/1486)
    chunked_transfer_encoding on;

    location / {
      proxy_pass http://harbor/;
      proxy_set_header Host $host;
      proxy_set_header X-Real-IP $remote_addr;
      proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;

      # When setting up Harbor behind other proxy, such as an Nginx instance, remove the below line if the proxy already has similar settings.
      proxy_set_header X-Forwarded-Proto $scheme;

      proxy_buffering off;
      proxy_request_buffering off;
    }
  }
}

我部署了两台harbor，监听端口都是8080，而且都是http的，而这个LB是https的。对于LB，有一个注意点就是upstream中需要使用ip_hash方式轮询，否则会有session问题。这样整个部署就完成了。此时你可以使用https://xxx.com去访问harbor了。

3. 其他

1. 之前我的LB使用的也是http，不修改harbor/make/common/templates/nginx/nginx.http.conf文件也不会有什么问题，但换成https之后，不修改pull和push就会一直Retrying，还不知道是什么问题。
2. 如果后端存储使用S3的话，需要使用#1244之后的Harbor版本，不然pull和push的时候也会有问题。
3. 当然这种部署方式主要是为了HA：只要集群内有一台Harbor正常工作，系统就是可用的。但是因为后端使用的是共享存储，所以实际使用中可能在存储这块会有性能瓶颈。另外，这种多实例使用共享存储是否会有问题，也没有经过生产验证。本文的部署方式只是对Harbor多节点部署方式的一种探索与实践，暂时还不保证生产环境使用会有什么问题。

4. 补充（更新于2017.1.24）

最近发现之前方案部署时一些可能出现的问题，这里再补充一下。

token问题

1. 之前的部署方案如果后台的Harbor没有公网IP的话，就会有问题。而多节点部署时，后台的Harbor都是在私网内，只有前端的LB暴露在公网。而registry得配置文件里面需要配置一个获取token的地址，这个地址必须是公网可以访问的。因为registry会把这个返回给访问registry的用户，让用户去获取token，如果公网没法访问，用户就没法docker login了。所以，如果后台的Harbor是在私网内，那在原来配置的基础上需要将harbor/make/common/templates/nginx/nginx.http.conf文件里面的realm配置为LB的公网IP（http(s)://LB公网IP或域名/service/token）。
2. 多节点部署的时候多个Harbor的private_key.pem文件要一样，否则可能出现在一台上面生成的token到另外一台验证不通过。需要注意的是执行./prepare命令默认会重新生成registry用来生成token的密钥文件，所以要么加参数让不重新生成pem文件，要么就将一台生成的拷贝到其他节点上去。
3. 多个服务器的时间也要完全一致，不然可能出现token过期或者时间未到的问题。