phillebaba

Spegel itself does not manage state as a normal registry would. Maybe ephemeral would be a better word to describe it. A normal registry would require some stateful storage solution along with a database to store image that clients push to it. Spegel exploits the fact that images used by containers will be stored on disk by Containerd for its benefit. Any image currently being used by a pod in a cluster will be available for all other nodes in the cluster to pull.

I am having some discussions about getting things working on GKE but I can't give an ETA as it really depends on how things align with deployment schedules. I am positive however that this will soon be resolved.

It's been a while since I looked at kuik, but I would say the main difference is that Spegel doesn't do any of the pulling or storage of images. Instead it relies on Containerd to do it for you. This also means that Spegel does not have to manage garbage collection. The nice thing with this is that it doesn't change how images are initially pulled from upstream and is able to serve images that exist on the node before Spegel runs.

Also it looks kuik uses CRDs to store information about where images are cached, while Spegel uses its own p2p solution to do the routing of traffic between nodes.

If you are running k3s in your homelab you can enable Spegel with a flag as it is an embedded feature.

Spegel does not only mirror Docker Hub, and works a lot differently than the alternatives you suggested. Instead of being yet another failure point closer to your production environment, it runs a distributed stateless registry inside of your Kubernetes cluster. By piggy backing off of Containerds image store it will distribute already pulled images inside of the cluster.

I would say most people would say it't best practice while a minority actually does it.

I initially built Spegel to deal with a series of GHCR outages along with rate limit changes in Docker Hub. I am a bit biased but it is a no brainier to run Spegel to mitigate these types of issues.

I am not to familiar with Kamal but it seems possible to integrate it with my project Spegel to remove some of the load from upstream. Especially if they are running clusters of servers physically located close to each other they could avoid some of the replication complexity with multiple Harbor instances.

Well your license is only as good as you are able to enforce it. Even with the law there is no guarantees.

I grew up thinking that people would follow the spirit of open source rather than the specific letter of the law. This is obviously not true, and probably never has been.

I agree with this. It seems to be one of the licenses out there that scares the big three cloud providers.

Any copies of the code should include the notice according to the MIT license. I do agree that I could have used a less permissive license, and it is something that I am now considering to change.

The reality is that licenses do not mean anything unless you are actually able to enforce it. So I really do not think the license would have mattered in this case.

I agree, after this happened to me I learned of a few other situations where the same thing happened to other friends.

On my end if was a mix of naivete and flattery which made me want to take the meeting. I suspect it is the same case for others. I will not make the same mistake the next time it happens.