democratic-csi VS Harbor

The interface software regarding is not a worry of mine, as democratic-csi does the storage management for me, thus the compatibility it is not limited to the application using the storage per se, as this is handled by Kubernete's CSI drivers, being application-agnostic when utilizing the storage provided.My main worry is not latency, but rather RAM

Check out https://github.com/democratic-csi/democratic-csi

in k3s, i'm using https://github.com/democratic-csi/democratic-csi (was using iSCSI before, now everything is NFS)

Have you checked this out? GitHub democratic-csi I have yet to test this in my @home K8s cluster. It supports iSCSI volume management for FreeNAS, Synology and other CSI backends.

If you ever migrate from docker up to kubernetes, then take a look into democratic-csi. For a modest homelab, it is a valid option (said from somebody who manages a small homelab and plays around with kubernetes).

For persistent storage have you looked into using TrueNAS with a CSI provider with your container orchestrator? I'm assuming your orchestrator is Nomad or Kubernetes.

Yes, Rancher does support FreeNAS, TrueNAS. and Scale using the storage class provider https://github.com/democratic-csi/democratic-csi It's important to remember Rancher is the server. And in this case, you need to ask the question does the k8s cluster that Rancher is managing support this storage class provider? If you are using RKE the answer is Yes.

I use https://github.com/democratic-csi/democratic-csi to mount nfs/iscsi shares (and manage the shares) from my SAN (truenas box).

iSCSI with democratic-csi (https://github.com/democratic-csi/democratic-csi) works great for me on truenas. I use iSCSI for any PVs that don't need to be shared and NFS for anything I'd like to share between different pods (like movies, music).

Storage - democratic-csi looked the most promising, it has worked well so far. I am using zfs-generic-iscsi against an Ubuntu 20.04 storage server. I also tried zfs-generic-nfs and it worked successfully with the caveat of having to deal with NFS file permissions.

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