playground VS Harbor

The dependency proxy in GitLab can help with caching the Docker images.

https://docs.gitlab.com/ee/user/packages/dependency_proxy/

When Docker Hub introduced rate limits last year, one way to mitigate its impact was to make the dependency proxy available for everyone.

https://about.gitlab.com/blog/2020/10/30/mitigating-the-impa...

https://about.gitlab.com/blog/2020/10/30/minor-breaking-chan...

Another way can be maintaining your own group which maintains all base images for your environment, and stores them in the GitLab package registry.

Using your own images can help enforce security policies, to avoid that containers introduce vulnerabilities (e.g. when always pulling :latest tag, or sticking to old tags). Reminds me of Infrastructure as Code security scanning, which can help detect things like this. Played with it when released in GitLab 14.5, examples in https://gitlab.com/gitlab-de/playground/infrastructure-as-co... + https://gitlab.com/gitlab-de/playground/infrastructure-as-co...

Depending on the languages and environments involved, builder images might be needed to reduce complexity with installing build tools. Like, C++ with gcc and controlling the exact version being used (major versions may introduce ABI breaking changes, I've seen it with armhf and gcc6 a while ago). Builder images also reduce the possibly for users to make mistakes in CI/CD before_script/script sections. An optimized pipeline may just include a remote CI/CD template with the magic happening in central maintained projects, using the builder images.

Another thought on builder images - multi arch images with buildx. I've read https://medium.com/@tomwillfixit/migrating-a-dockerized-gitl... yesterday, need to learn more :)

cat << EOF wget \ https://github.com/goharbor/harbor/releases/download/v2.9.4/\ harbor-offline-installer-v2.9.4.tgz EOF

Now that you know a little more about Cosign, Notary, and DCT, we will take it one step further by using one of these tools: Cosign. For this example, we will use the simple Docker registry:2 reference image to run a simple registry. In a real-world scenario, a managed registry such as Harbor, Amazon ECR, Docker Hub, etc.

Have a look at harbor, you can also use it to follow the same methods for helm charts etc.

Or for something more advanced https://goharbor.io/

Look at https://goharbor.io/

You can host your own image repo if your feeling feisty. Harbor is a graduated project from the CNCF and they are also working on a new implementation called Dragonfly. https://goharbor.io/

Does anybody know whether there could be something like an open/libre container registry?

Maybe the cloud native foundation or the linux foundation could provide something like this to prevent vendor lock-ins?

I was coincidentially trying out harbor again over the last days, and it seems nice as a managed or self-hosted alternative. [1] after some discussions we probably gonna go with that, because we want to prevent another potential lock-in with sonarpoint's nexus.

Does anybody have similar migration plans?

[1] https://goharbor.io

2) Harbor instance registry