chartmuseum VS Harbor

We may switch over to Chartmusuem, and something like Charts-Syncer to try to help with this, or maybe abandon the whole idea of mirroring external repositories and just keep our repository hosting internal projects. What are your thoughts on this?

Also trying to find a small self-hosted container registry (not some beast like goharbor.io) and possibly a Helm chart repository (looking into chartmuseum.com). Anyone got some recommendations?

You can use either something like https://chartmuseum.com/ or any docker registry if it has OCI support.

ChartMuseum is indeed open source and is on GitHub.

This is also basically an s3 proxy, but it specifically implements the Terraform Registry API so that things like version constraints are handled correctly. If you use Helm at all, an analogous project for charts would be https://github.com/helm/chartmuseum

I raised a PR (WIP) https://github.com/helm/chartmuseum/pull/464 but wondering if others would think this is useful or if I just have a niche usecase.

Another benefit of Helm is in it's package management. If your application requires another team's application up and running, they can publish their Helm chart to a remote repository like a ChartMuseum. You can then install their application into your Kubernetes by naming that remote chart combined with a local values file. E.g., helm install other-teams-app https://charts.mycompany.com/other-teams-app-1.2.3.tgz -f values-other-teams-app.yaml. This is convenient because it means you don't have to checkout their project and dig through it for their helm charts to get up and running - all you need to supply is your own values file.

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

Does it HAVE to be those types of packages, have you thought of using containers instead and thus open the options for more types of storage like https://goharbor.io/ ?