fruitywelsh @fruitywelsh@qoto.org
Hello All,
With DockerHub removing its free tier and potential for future shenanigans, people are looking to move away from them for free and personal use.
To me, there seems to be a couple straight forward solutions:
* quay.io: open source but still centralized and ran by single for profit
* Gitlab.com registry: open source but still centralized and ran by single for profit
* GitHub.com registry: Same boat as DockerHub but larger corporation
* Running your own personal registry: Additional work for each party involved, low discovery options.
Now with the boring, straightforward solutions mentioned, and the bar set, I am going to suggest that we take this opportunity to push for a better long term solution.
Push for decentralized storage of OCI images and federated metadata support. The only urgency I see is that, because of the bone headiness of the latest Docker decision, frogs are actually jumping out of the pot, and I fear they might turn down the temp to a slower boil, or people might just jump into a slower cooker like github. Either way, the status quo looks to be a slow boiling away of the common infrastructure we are used today.
Here some decentralized options and strategies I've found so far:
## nerdctl ipfs support
[nerdctl](https://github.com/containerd/nerdctl/blob/main/docs/ipfs.md) supports IPFS for both image pulling and pushing, including encrypted images and eStargz lazy pulling. For building, the current method is a locally hosted translator so that the traditional pulls can be converted to work over IPFS. They even have docs on running it on k8s node, though if my reading is correct this isn't exactly a cloud native approach (running systemd services on each node...).
## IPDR: InterPlanetary Docker Registry
[IPDR](https://github.com/ipdr/ipdr) is a service to allow for images stored on IPFS to be accessible over Docker Registry HTTP API V2 Spec
## ociipfs OCI layer to IPFS content translation
[ociipfs](https://github.com/mkmik/ocipfs) this is tool to be able to translate to IPFS stored layers as the expected OCI layers and pulls found in the Docker build system.
## My thoughts
If you notice, the same thing I noticed in this list is that most of these are workarounds to support the web2 api on IPFS. There is a pull in draft for [BuildKit](https://github.com/moby/buildkit/pull/3510) that may make native IPFS image support better on the image build side. With the work on the nerdctl side being the most direct support for images for pushing and pulling images with IPFS hashes.
The last piece I hope you noticed is that none of these answer the discoverability question, and with none human friendly name spacing on the hashes do not serve well for code readability on either the ops or build side of the house. IPNS could serve to help the latter, but I think that something like an ActivityPub/Fediverse enabled site may better serve as a hosting point for images, allowing for multiple actors to better curate images, tags, Cosign, ipfs links, and other metadata for end users to select from.
Lastly, this is just some last minute research on my part and would love to hear more people's thoughts!
Edit 1 some points made in discussion:
Having a hard requirement on running a full IPFS daemon and node would be barriar to entry for a lot of people, and so if IPFS is used it should more ideally be used in a totally contained way.
[Gitea](https://nlnet.nl/project/Gitea/) and it's fork [Forgejo](https://forgejo.org/) both have federation via ForgePub in work and registry support, and thus maybe solid points targets for a federated/decentralized platform.
[Reddit post](https://www.reddit.com/r/ipfs/comments/11tjca7/dockerhub_replacement_stratagy_and_options/?utm_source=share&utm_medium=web2x&context=3)
#Docker #DockerHub #kubernetes #k8s #selfhosted #decentralized #ipfs #ActivityPub #containers #OCI #opensource #DevOps
