Harbor多节点部署实践


Harbor是VMware开源的一套企业级Registry解决方案,功能比较丰富,特别是增加了角色管理、镜像复制等在实际场景中非常有用的功能。项目地址见:https://github.com/vmware/harbor。本文介绍一种多节点配置方法,主要是实现HA。

1. 部署架构

Harbor多机部署方案.png

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

2. 部署过程

2.1 部署Harbor

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

  1. 修改数据库相关的存储:(1)修改harbor/make/common/templates/uiharbor/make/common/templates/jobservice下面的env文件,将其中的MYSQL_HOSTMYSQL_PORTMYSQL_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过期或者时间未到的问题。

添加新评论

选择表情 captcha

友情提醒:不填或错填验证码会引起页面刷新,导致已填的评论内容丢失。

|