Rancher: Global Built-In Registry - Using Harbor

[rcarmo]

I've been poring over past (closed) issues, and see no explicit mention of this, so thought it best to ask even if it's only to have it filed away for future reference:

• Even given that running a registry can be considered an entirely different proposition from orchestrating containers, wouldn't it make sense for Rancher to have a built-in registry, even if there was no UI for it?

This would be an added value (i.e., deploy Rancher, have a complete solution) and might also do away with a fair amount of issues of various kinds regarding trusting private registries.

[ebuildy]

Docker registry runs with Docker very easily, I am not sure of the plus value, maybe with some hooks that for instance, could restart Rancher services when you push a new image.

[rcarmo]

"very easily" doesn't really go too well with registry 2.0. Setting up the required certificates and the backing store is mandatory if you intend to actually use instead of just playing around with it, so I think there's plenty of added value there.

It's not just docker run registry:2, it actually requires some sane defaults, plus each Rancher host has to be manually configured to trust a new registry.

[JamesBarwell]

I've just been setting up a registry and for me there would be a lot of value if Rancher could:

• set up multiple redudant registries across physical hosts with a shared data store and load balancing
• simplify addition of the certificate and key through the UI
• automatically configure itself to consume images from the registry service

[nicolasmery]

+1 @JamesBarwell

[robzhu]

+1

[ibuildthecloud]

Keep the +1's coming :). If we get enough requests will do something along the lines of what @JamesBarwell suggested.

FYI @cloudnautique

[fentas]

+1

[lavvy]

Yeah +1. I see this feature almost like resting on a distributed volume
concept being defaulted for rancher. Cos there still many apps that may
come in the future that will still make use of this concept
On Aug 27, 2015 1:21 PM, "Jan Guth" [email protected] wrote:

+1

—
Reply to this email directly or view it on GitHub
https://github.com/rancher/rancher/issues/1738#issuecomment-135497667.

[dx9]

+1

[EliSnow]

+1

[willseward]

:+1:

[Rucknar]

+1

[blackjid]

:+1:

[cusspvz]

tl;dr

Don't see built-in private registry as an option just because you have to setup storage. That means that you would need to have some configuration on admin panel before starting it.

But since I've read the issue #1272 a few minutes ago, it seems a better solution for this case.

EDIT: just because it seems you could setup options on templates, IMHO that discards the need of built that in.

[vincent99]

Templates still need to ultimately deploy a docker image, which comes from a registry, and people don't necessarily want their image in public DockerHub...

[fentas]

@cusspvz I do not see quite the connection between docker registry and templates. A built in docker registry in rancher would mean to me

• easy self managed (private) docker registry. (no hassle with certs etc.)
• no need of external traffic (image pull) > faster.
• integrated functionality like restarting of running containers if new images are available. (maybe easy configuration with container labels)
• and all what JamesBarwell mentioned.

[cusspvz]

@vincent99 yep, but registry image is public, which mean you could have a template that creates a private registry service on your hosts, allows to configure storage (to prevent issues with later reboots) and its up and running as it was built-in. You could even launch multiple private registries with for different teams or stacks. :)

[cusspvz]

@fentas

easy self managed (private) docker registry. (no hassle with certs etc.)

That should be useful, but rancher allows you to add any registry right?

no need of external traffic (image pull) > faster.

My idea covers that also, well, as it runs as a normal service, you could also say in which hosts should the registry run.

integrated functionality like restarting of running containers if new images are available. (maybe easy configuration with container labels)

That should be triggered by the CD software, not by the registry. Example: tests workflow could vary between companies, if a company needs to push images so it could be tested by worker services, this would be a hassle. So, Continuous Development Software should be the one who triggers an upgrade (not difficult if you use rancher-composer to do a rolling upgrade after testing and pushing the image to the registry).

and all what JamesBarwell mentioned.
set up multiple redudant registries across physical hosts with a shared data store and load balancing

Allowable by the templating feature

simplify addition of the certificate and key through the UI
automatically configure itself to consume images from the registry service

A fork of registry could be created for rancher to do just that

[kaos]

+1 :D

[gordontyler]

+1!

[dhax]

+1

[see0]

+1

[ajagnanan]

+1

[gbisheimer]

There is a nice project to manage private docker registry v2 token authentication named Portus. May be it can be integrated into rancher.

[mishak87]

@gbisheimer I quickly scoped Protus and it has several configuration issues which prevent it running in production mode just from docker-compose.yml and one nasty bug when tagging images.

:+1:

To keep it simple I would suggest registry:2 behind nginx proxy with htpasswd read/write ACL and use SSL certs stored in Rancher.

[Tails]

+1

[willseward]

I agree with @mishak87. I tried standing Portus up on rancher, and it would require a few modifications in order to run properly w/o initialization by the user. It also locked up one of my hosts by filling up the HD. I'm not sure why though; I didn't do a postmortem.

[gbisheimer]

@mishak87, before finding Portus I also found this blog that explains how to setup docker_auth to use the new docker registry v2 token-authentication. This is a nice feature that allows to have more fine-grained access control to the registry images.

The nice thing about Portus is that it uses token authentication and manages namespaces, teams and users, and allow to limit the access level (owner, collaborator, viewer) of different team members to the registry. Sure it's not usable in production right now, and also it may need to be ported from Rails before including it in Rancher, but it's a starting point.

Registry proxy cache is also a nice feature that should be included

[sshipway]

+1 here as well.

I've been trying to set up registry:2 with certs and a GUI and it is not so simple. If Rancher had one supplied it would be much simpler, particularly if the UI were integrated and you could use the existing Environment permissions to grant access to maintain said registry.

Of course, once you get RancherOS + Rancher + Registry + Registry UI + ... you end up with Rancher becoming more of a full end-to-end PaaS solution than a Docker cluster (eg: OpenShift). It might be a bit soon to go that far before Rancher itself has even reached 1.0.

[Ilya-Kuchaev]

+1

[ibuildthecloud]

We definitely want to make setting up a registry easier. UI and integrated authz is probably not something we would consider before 1.0.

I think the best route atm would be to create a catalog entry for registry:2. @cloudnautique has been very busy building out elk, Jenkins, gluster, Hadoop, and others in the catalog. We will probably get to registry but we would love some community contribution to speed up the process. If anybody is interested in helping let us know. I'd love to see a one click install of registry:2.

[fred4jupiter]

+1

[nomonamo]

+1

[cusspvz]

Here's our contribution! A scalable registry compose :)

Be sure to have a valid htpasswd on your btsync share. before starting it.

# Stack name: docker

btsync:
  labels:
    io.rancher.scheduler.affinity:container_label_ne: io.rancher.stack_service.name=docker/btsync
  command:
  - bootstrap
  - ${BTSYNC_SHARED_KEY}
  - data
  image: cusspvz/btsync:2.0.1
  privileged: true
  volumes:
  - ${EPHEMERAL_STORAGE}/docker/registry:/data
  stdin_open: true

registry-redirect:
  environment:
    REDIRECT: https://${DOMAIN}
  tty: true
  image: cusspvz/redirect:0.0.1
  stdin_open: true

redis:
  image: redis:latest

registry:
  environment:
    REGISTRY_AUTH: htpasswd
    REGISTRY_AUTH_HTPASSWD_PATH: /data/htpasswd
    REGISTRY_AUTH_HTPASSWD_REALM: Registry Realm
    REGISTRY_HTTP_HOST: ${DOMAIN}
    REGISTRY_HTTP_SECRET: ${HTTP_SECRET}
    REGISTRY_REDIS_ADDR: redis-server:6379
    REGISTRY_STORAGE_FILESYSTEM_ROOTDIRECTORY: /data/storage
    REGISTRY_STORAGE_CACHE_BLOBDESCRIPTOR: redis
  image: registry:2
  privileged: true
  links:
  - redis:redis-server
  - btsync:nfs-server
  entrypoint:
  - /bin/bash
  command:
  - -c
  - apt-get -y -qq update; apt-get install -y -qq nfs-common; mkdir -p /data; mount -t nfs4 nfs-server:/data /data; while [ ! -d "/data/.sync" ]; do echo "waiting for sync process to be completed"; sleep 2; done; exec registry /etc/docker/registry/config.yml

http-and-https:
  ports:
  - '443'
  - '80'
  links:
  - registry:registry
  - registry-redirect:registry-redirect
  labels:
    io.rancher.scheduler.global: 'true'
    io.rancher.loadbalancer.ssl.ports: '443'
    io.rancher.loadbalancer.target.registry-redirect: ${DOMAIN}:80=80
    io.rancher.loadbalancer.target.registry: ${DOMAIN}:443=5000
  tty: true
  image: rancher/load-balancer-service
  stdin_open: true

EDIT: @cloudnautique this also serves an example on how to scale storage with btsync. :)

[sshipway]

@cusspvz - that's interesting. I've something similar that uses nginx, registry:2 and one of the frontends, and works with certificates; however the problem I have is that there seems to be no decent web frontend that supports a registry with authentication enabled. Also, registry:2 does not seem to allow me to use LDAP authentication.

The trick to do the NFS mount on the registry container is handy, too. I'd originally thought to do that using a sidekick.

The Holy Grail to me is a stack that has registry, web admin interface, certificates, LDAP authentication, and NFS mounting of the registry backend storage...

[lucidprogrammer]

+1

[abaxo]

+1

[e-durante]

+1

[cusspvz]

The Holy Grail to me is a stack that has registry, web admin interface, certificates, LDAP authentication, and NFS mounting of the registry backend storage...

Agree with those, but I suppose as it comes built-in with rancher to authenticate against rancher's authentication. It should support then LDAP, GitHub, Local users and future Rancher's authentication methods.

The trick to do the NFS mount on the registry container is handy, too. I'd originally thought to do that using a sidekick.

Nice to hear that!

however the problem I have is that there seems to be no decent web frontend that supports a registry with authentication enabled.

There is one, Portus - made by Suse, think someone already talked about it over here (checked and it was already mentioned). I've already tested it, but unfortunately at that time, it wasn't mature enough. Maybe things have changed.

[sshipway]

I've tried installing Portus - it looks ike it could be very good, especially if wrapped up with a mysql container and registry into a stack with a load balancer to offload the certificate... however I just cannot make it work with our AD LDAP. If it ever decides to play nicely then I'll create a Catalog definition, but I suspect it needs a bit of work. If anyone else has managed this then please share...

[that0n3guy]

+1

[hendrikhofstadt]

+1

[sshipway]

Here's what is now working for me. I've wrapped up everything into a Catalogue definition which you can access from https://github.com/sshipway/rancher-catalogue.git (just point your Rancher at this catalogue to get a couple of goodies including this)

This Catalogue item will give you a secure, SSL-protected and authenticated Registry, with a web UI for administration (Portus) which can link to LDAP for authentication. It works on our setup (behind F5 load balancer, AD LDAP) but YMMV. Please give me feedback on the Github Issues page at https://github.com/sshipway/rancher-catalogue/issues if you have problems.

Ideally, of course, this would be built-in to Rancher, share the Rancher authentication and certificates, allow deletions, etc. but this is the best I've managed to date.

[taketnoi]

+1

[pedrommone]

+1

[gitmonster]

+1

[blaggacao]

@cusspvz @sshipway @ibuildthecloud @gbisheimer

A word on auth: I feel hashicorp vault could come handy in here as well, if it is decided to leverage it's auth features, see respective authz/secrets cross-refs...

https://github.com/rancher/rancher/issues/3267 (Access Control)
https://github.com/rancher/rancher/issues/1269 (Secrets Management)
https://github.com/rancher/rancher/issues/3138 (Secrets Management)
https://github.com/rancher/os/issues/724 (RancherOS Auth Mgt.)

IIRC, the no more missing piece from docker side is this: https://docs.docker.com/registry/spec/auth/jwt/
which has even a stub counterpart, as i just discovered: https://github.com/hashicorp/vault/issues/644

This would discart portus as UI "overhead", rancher's playground.

---

A word on templates: I don't see one single reason, why a template is not the right place for this sort of first class citizens.

+1

[raphink]

:+1:

[silviupanaite]

+1

[Negashev]

+1

[sstine]

+1

[mtrofimm]

+1

[lewistaylor]

+1

If one day I go to catalog and registry:2 is there by default I will cry tears of joy you have no idea.

[mishak87]

If someone is building catalog this could be useful component for authentication https://github.com/cesanta/docker_auth

[lenovouser]

:+1:

[sshipway]

@mishak87 - I built mine using Portus (which has built-in auth support for registry:2), however this only links to LDAP for auth. The one you mention seems to have Google auth support as well as LDAP and static. One problem with the Portus approach is that (if you use LDAP) then all users need to be in LDAP, so you can't define an additional static user creds for Rancher to use (its not so easy for me to add an LDAP identity because of the way our LDAP synchs to our main identiy service)
Also, Portus does not have an official Docker build as yet, so I had to do some tweaks and produce my own... it does, however, have a web UI which is very helpful for user management and defining goup/namespace access. Catalogue at https://github.com/sshipway/rancher-catalogue.git if you want to see how I put ours together.

[mishak87]

@sshipway I was thinking more like this: It is opensource project so I could (or better convince here someone else to) hack support for GitLab (it has full oauth) to support my team. :smile:
I don't like Portus for several reasons one of them is that it is written in ruby and tries to do multiple jobs instead of one very well.
EDIT: Also it acts as another source of truth. I want to use members role and his/hers assignment to projects for defining access to registries.

[sshipway]

@mishak87 - I would far rather Rancher itself were able to support the registry auth, so as to use the single definitions... however with Portus at least we can link both to our LDAP for authentication and only authorization is separate. Also, we have some valid use cases where we would want a registry to be managed by different people to the ones who have environment member rights, so that actually helps.

[mishak87]

@sshipway It is hidden in examples but cesanta/docker_auth supports multiple backends via failover so you could in theory implement your usecase by providing more sources (custom, ops etc.). Still you would need some UI to manage that source.

[jlaswell]

+1 here and I'll see what we can do to help in contributing to this!

[mishak87]

I'm implementing in-house auth service using GitLab as SSoT with mapping namespace/project 1:1 namespace/image. I might make an open-source version based on my experience building it.
So far I just realized how much opinionated and variable the registry setup can get. For orgs with LDAP Portus is probably the fastest way to get started.

FYI GitLab is discussing adding private registry too.

[jpettersson]

+1

[xinity]

why bothering to integrate docker registry in rancher, when you can have it fully implemented using portus from rancher community catalog : https://github.com/rancher/community-catalog/tree/master/templates/registry

now that community catalog have a template for it,
i don't think it's still necessary to have a registry built-in.

that's my 2cents :)

[lewistaylor]

@xinity because it's an absolutely massive image and for those that require just a lightweight solution to keep images private, docker-registry makes a lot of sense! :-D

[djskinner]

The registry stack in community catalog is too heavy and all-encompassing for my requirements. There is still a gap for a simple lightweight registry:2 solution.

I agree there is still scope for this but I'm not convinced it needs to be built in. Perhaps an alternative registry catalog entry would suffice. If you use the letsencrypt stack and terminate the SSL with a load balancer its quite simple to set up a registry. The only missing piece is basic auth. However, I'm toying with the idea of leaving the registry internal so that it can only be accessed by VPNing into the rancher network.

For me the end goal would be to have a CI such as Drone pushing to the registry anyway, which would happen internally to the Rancher network.

[lewistaylor]

Exactly my thoughts for a setup. Think it would work really nice and would
minimise security concerns.

On 22 March 2016 at 17:01, djskinner [email protected] wrote:

The registry stack in community catalog is too heavy and all-encompassing
for my requirements. There is still a gap for a simple lightweight
registry:2 solution.

I agree there is still scope for this but I'm not convinced it needs to be
built in. Perhaps an alternative registry catalog entry would suffice. If
you use the letsencrypt stack and terminate the SSL with a load balancer
its quite simple to set up a registry. The only missing piece is basic
auth. However, I'm toying with the idea of leaving the registry internal so
that it can only be accessed by VPNing into the rancher network.

For me the end goal would be to have a CI such as Drone pushing to the
registry anyway, which would happen internally to the Rancher network.

—
You are receiving this because you commented.
Reply to this email directly or view it on GitHub
https://github.com/rancher/rancher/issues/1738#issuecomment-199907945

_Lewis Taylor_

Managing Director
Danger Farms
[email protected]
[phone]

Office 1.05, 1st Floor, 20 Ropemaker Street, London, EC2Y 9AR

[tritao]

+1

[bhchew]

+1

[djskinner]

Just a thought, it might be nice if the Rancher API could be used as the token authentication server for a registry, fulfilling a similar role to https://github.com/cesanta/docker_auth

[sshipway]

@djskinner - I agree with you on that, I think the subject came up once before somewhere else, too. This would be a great solution as we could just use registry:2 but have unified authnz in Rancher. It might need to have some more configuration in Rancher, though, as you'd want to be able to grant permissions to the registry on a namespace basis, independently of environment access

[trondvh]

+1

[bennythomps]

👍

[FGRibreau]

:+1:

[luisrudge]

:+1: for the complete built-in solution.

[mercuriete]

+1. the kubernetes stack takes so much time to build up when is the first time you add a node. (dsl internet conection)

[bradjones1]

GitLab completed their roll-out of this feature, per the comments above. It has some room to grow but could be an option for a self-hosted solution with access control.

[luisrudge]

Yeah.. I'm using the GitLab registry and it works great!

[shakefu]

We considered doing a private registry, but given that we had done a lot of work on Docker Hub previously, it was a non-starter due to having to update all our images to use the private registry URL, instead of just the repository namespace.

However we did go forward using a --registry-mirror container, in Rancher, which is working great to speed up our pulls. Not sure if doing something like that would fall under this issue, but I'd +1 a private registry catalog, and a +1 for a registry mirror catalog, or even a built-in registry mirror.

[sstine]

I would definitely like a stable registry or registry mirror catalog item, possibly with VMWare Harbor...I may end up creating it myself. I use Dockerhub when I can, but sometimes it's not an option. Gitlab's container registry is nice, but it limits you to 1 image per repo and they don't have a date of when that'll be changed.

Some work with VMWare Harbor and Rancher has already been done:
http://www.it20.info/2017/01/vmware-harbor-as-a-rancher-catalog-entry/
https://github.com/mreferre/rancher-catalog-extension/tree/master/templates/vmware-harbor

I might make a new one which uses Rancher's certificate store.

[frol]

Just for your info.

I would definitely like a stable registry or registry mirror catalog item.

GitLab Registry works great for me (and it is nicely integrated into GitLab and GitLab CI).

For the Docker Hub registry mirroring NGINX with caching works perfectly and it is very lightweight, here is the NGINX config:

proxy_cache_path /tmp/dockerhub-nginx-cache levels=1:2 keys_zone=DOCKERHUB:10m inactive=72h max_size=10g;

server {
    server_name dockerhub-mirror.com;

    include /etc/letsencrypt/options-ssl-nginx.conf;
    ssl_certificate_key /etc/letsencrypt/live/dockerhub-mirror.com/privkey.pem;
    ssl_certificate /etc/letsencrypt/live/dockerhub-mirror.com/fullchain.pem;
    listen 443 ssl;

    # DockerHub Caching Proxy
    location /v2/ {
        proxy_pass https://registry-1.docker.io;
        proxy_cache            DOCKERHUB;
        proxy_cache_valid      200  1d;
        proxy_cache_use_stale  error timeout invalid_header updating
                               http_500 http_502 http_503 http_504;
        proxy_intercept_errors on;
        proxy_cache_lock on;
        error_page 301 302 307 = @handle_redirect;
    }
    location @handle_redirect {
        set $saved_redirect_location '$upstream_http_location';
        proxy_pass $saved_redirect_location;
        proxy_cache            DOCKERHUB;
        proxy_cache_valid      200  1d;
        proxy_cache_use_stale  error timeout invalid_header updating
                               http_500 http_502 http_503 http_504;
        proxy_cache_lock on;
        proxy_cache_lock_age 600s;
        proxy_cache_lock_timeout 600s;
        proxy_cache_key $scheme$proxy_host$uri;
    }

}

Once the mirror is up and running, you should add --registry-mirror https://dockerhub-mirror.com to the Docker daemon on every server where you plan to use the mirror.

Gitlab's container registry is nice, but it limits you to 1 image per repo and they don't have a date of when that'll be changed.

I just (ab)use tags if I need to put several images, e.g. dockerhub.mygitlab.com/group/project:latest-service1.

[Negashev]

We use this:
gitlab stack

GITLAB_URL=gitlab.company.com
DOCKER_GITLAB_URL=docker.company.com
GITLAB_REGISTRETION_TOKEN='' #get from you gitlab 

version: '2'
services:
  server:
    image: gitlab/gitlab-ce:latest
    hostname: ${GITLAB_URL}
    environment:
      GITLAB_OMNIBUS_CONFIG: |-
        external_url 'https://${GITLAB_URL}';
        nginx['listen_port'] = 80;
        nginx['listen_https'] = false;
        nginx['proxy_set_headers'] = {
          "X-Forwarded-Proto" => "https",
          "X-Forwarded-Ssl" => "on"
        };
        gitlab_rails['gitlab_shell_ssh_port'] = 2222;
        gitlab_rails['smtp_enable'] = true;
        gitlab_rails['smtp_address'] = "smtp.yandex.ru";
        gitlab_rails['smtp_port'] = 587;
        gitlab_rails['smtp_user_name'] = "[email protected]";
        gitlab_rails['smtp_password'] = "passw0rd";
        gitlab_rails['smtp_domain'] = "www.yandex.ru";
        gitlab_rails['smtp_authentication'] = "login";
        gitlab_rails['smtp_enable_starttls_auto'] = true;
        gitlab_rails['smtp_openssl_verify_mode'] = 'peer';
        gitlab_rails['gitlab_email_from'] = '[email protected]';
        gitlab_rails['gitlab_email_reply_to'] = '[email protected]';
        # Settings used by Registry application;
        registry_external_url 'https://${DOCKER_GITLAB_URL}';
        registry['enable'] = true;
        gitlab_rails['registry_enabled'] = true;
        registry_nginx['listen_port'] = 80;
        registry_nginx['listen_https'] = false;
        registry_nginx['proxy_set_headers'] = {
          "X-Forwarded-Proto" => "https",
          "X-Forwarded-Ssl" => "on"
        };
        ];
    volumes:
    - /gitlab/config:/etc/gitlab
    - /gitlab/logs:/var/log/gitlab
    - /gitlab/data:/var/opt/gitlab
    labels:
      io.rancher.container.pull_image: always
  cleanup:
    image: quay.io/gitlab/gitlab-runner-docker-cleanup
    environment:
      DEFAULT_TTL: 10m
      USE_DF: '1'
      LOW_FREE_SPACE: 4G
      EXPECTED_FREE_SPACE: 8G
    stdin_open: true
    volumes:
    - /var/run/docker.sock:/var/run/docker.sock
    tty: true
    labels:
      io.rancher.container.pull_image: always
      io.rancher.scheduler.global: 'true'
  ci-node:
    privileged: true
    image: gitlab/gitlab-runner
    environment:
      CI_SERVER_URL: https://${GITLAB_URL}/ci
      REGISTER_NON_INTERACTIVE: 'true'
      REGISTRATION_TOKEN: ${GITLAB_REGISTRETION_TOKEN}
    stdin_open: true
    entrypoint:
    - sh
    - /config/entrypoint.sh
    volumes:
    - /var/run/docker.sock:/var/run/docker.sock:rw
    tty: true
    volumes_from:
    - ci-node-conf
    command:
    - --executor
    - docker
    - --docker-image
    - docker
    - --docker-privileged
    labels:
      io.rancher.sidekicks: ci-node-conf
      io.rancher.container.pull_image: always
      io.rancher.scheduler.affinity:container_label_ne: io.rancher.stack_service.name=gitlab/server
  ci-node-conf:
    image: negash/dockerize
    environment:
      CI_SERVER_URL: https://${GITLAB_URL}/ci
      DOCKERIZE_GET: negash.ru/s/gitlab/config.toml.tmpl;negash.ru/s/gitlab/entrypoint.sh
      REGISTRATION_TOKEN: ${GITLAB_REGISTRETION_TOKEN}
    stdin_open: true
    volumes:
    - /config
    - /etc/gitlab-runner
    - /usr/local/share/ca-certificates
    tty: true
    - /etc/gitlab-runner
    labels:
      io.rancher.container.start_once: 'true'
      io.rancher.container.pull_image: always
      io.rancher.scheduler.affinity:container_label_ne: io.rancher.stack_service.name=gitlab/server

[alber70g]

+1

[shakefu]

FWIW, we had to stop using our --registry-mirror setup because when we were bringing up a new hosts with many containers scheduled (30+, over about 15 services), pulling that many images simultaneously ended up saturating the network and caused other issues, in addition to making the host take forever/time out coming up.

Probably not as large an issue for smaller installations or infrastructures with lighter docker images (several of ours our 1GB+), but in our case, we're going to have to move to a high-network-throughput registry mirror that lives outside the rancher/overlay network ecosystem to avoid issues.

[armand1m]

+1

[armand1m]

would be probably the most awesome feature ever

[cooljl31]

👍

[deniseschannon]

Acceptance Criteria for Alpha

[ ] Have a HA cluster with local cluster enabled, add a PV using NFS to the local cluster. Enable Harbor using the PV option. - Only Admin
[ ] Enable Harbor, selecting the S3 option - Only Admin
[ ] Add images to Harbor - Cluster Owner/Cluster Member and Project Owner/Project Member
[ ] Add username and password to the global registry - Cluster Owner/Cluster Member and Project Owner/Project Member
[ ] Deploy workloads using the private images - Cluster Owner/Cluster Member and Project Owner/Project Member

[sowmyav27]

verified on rancher:master

1. Rancher setup - HA with local cluster.
2. Enabled Harbor using

• Storage Backend for Registry - S3
• Config Database Type - external - Postgres
• Config Redis Type - external - Redis

1. Able to enable Harbor Registry by Admin.
2. Other user, other than Global Admin - Cluster Owner, Cluster member and Project Owner - Able to create an account in Harbor UI, push images to the Harbor registry and deploy workload using these private images

[jiaqiluo]

verified on rancher: master

• Enabled Harbor on the Rancher HA setup using self-signed certs
• Enabled Harbor by using EBS storage class
• as a project member, using Global Registry on EKS, AKS and imported GKE cluster

Known issue:

• using NFS to for PV in the local cluster: https://github.com/rancher/rancher/issues/20681

[jiaqiluo]

verified on rancher: master

• Enabled Harbor on the Rancher HA setup using Let's Encrypt

[jiaqiluo]

verified on rancher: master

enable Harbor using EBS as the Storage Class

• Add images to Harbor - Cluster Owner/Cluster Member and Project Owner/Project Member
• Add username and password to the global registry - Cluster Owner/Cluster Member and Project Owner/Project Member
• Deploy workloads using the private images - Cluster Owner/Cluster Member and Project Owner/Project Member