feat: allow for configuring the docker hub registry endpoint via API

[tuunit]

Comprehensive Summary of your change

This PR adds the possibility to change the registry endpoint of DockerHub via API. This is useful for Harbor instances that run in airgapped environments and have to go through a DMZ or use a reverse proxy to access DockerHub.

Why not just use a normal Docker Registry type instead of the DockerHub adapter?

Because of the logic for library images which only applies to the Registry Type DockerHub:

harbor/src/server/middleware/repoproxy/proxy.go

Lines 128 to 144 in 8bf710a

	func defaultLibrary(ctx context.Context, registryID int64, a lib.ArtifactInfo) (bool, string, error) {
	if registryID <= 0 {
	return false, "", nil
	}
	reg, err := registry.Ctl.Get(ctx, registryID)
	if err != nil {
	return false, "", err
	}
	if reg.Type != model.RegistryTypeDockerHub {
	return false, "", err
	}
	name := strings.TrimPrefix(a.Repository, a.ProjectName+"/")
	if strings.Contains(name, "/") {
	return false, "", nil
	}
	return true, name, nil
	}

By allowing to change the registry endpoint for DockerHub, those kinds of environments can still benefit from the library substitution logic.

Please indicate you've done the following:

• Well Written Title and Summary of the PR
• Label the PR as needed. "release-note/ignore-for-release, release-note/new-feature, release-note/update, release-note/enhancement, release-note/community, release-note/breaking-change, release-note/docs, release-note/infra, release-note/deprecation"
• Accepted the DCO. Commits without the DCO will delay acceptance.
• Made sure tests are passing and test coverage is added if needed.
• Considered the docs impact and opened a new docs issue or PR with docs changes if needed in website repository.

[tuunit]

/label release-note/enhancement

[tuunit]

@Vad1mo any feedback on the approach? Do you want me to write an apitest?

[Vad1mo]

Makes sense to me..

It might be the stupid questions. but why is the URL hardcoded and not changeable in the first place?
Why not add the convenience to the user to preset it and allow the user to enter what he wants.

[tuunit]

I have no idea why it is hardcoded 😅 If you want me to change the UI as well to allow changing it. I can do it as part of this PR or another. Just let me know what you guys would prefer on how to continue

[wy65701436]

We're doing this due to the behavior in the upstream. You can refer to the following link for more details: https://github.com/moby/moby/blob/master/registry/config.go#L43.

@tuunit, If you need to access Docker Hub through a proxy, you should configure the proxy for harbor-core and jobservice, rather than updating the Docker Hub URL.

[tuunit]

@wy65701436 thanks for actually finding the original place in the moby code base 😅

Nevertheless, I already know that is the official registry URL of docker hub. But as explained in my PR description, it is sometimes necessary to run Harbor inside an air gapped / private environment without direct internet access and therefore replications / caching might need to go through a simple reverse proxy to communicate with the public web. For this purpose it would be great to keep the logic of the library completion if missing despite running behind a proxy. More details in the PR summary. (which is only done for the docker-hub adapter)

[Vad1mo]

We're doing this due to the behavior in the upstream. You can refer to the following link for more details: https://github.com/moby/moby/blob/master/registry/config.go#L43.

The strategy Docker is following is for commercial reasons and backwards compatibility only. We should not limit ourselves to that.

If we ask ourselves why people user Harbor. One of the big arguments for Harbor is replication.

1. On-Prem/air gapped environments
2. No Cloud
3. non Standards setups

Regarding this PR or its further thinking

1. Will a prefilled and changeable URL set to registry-1.docker.io be backwards incompatible? → No
2. Will it restrict users? → No
3. Will it open up new possibilities and use cases? → yes

Personally, I don't see any strong argument against it, or any negative consequences.