Serverless-registry: A Docker registry backed by Workers and R2

https://github.com/cloudflare/serverless-registry

by tosh • 2 years ago

169 71 2 years ago

How's the pricing with low usage? I suspect this is great. I wanted an image registry so that I can use it to deploy with Kamal, but the $5 plan is overpriced, given I push an image maybe once every 3 months. This could solve that

bayesianbot• 2 years ago

I don't use much of CloudFlare services but it seems kinda cheap, $0.015/GBmonth for storage (+10GB free), Workers are charged per request and CPU time, both of which would probably be quite low for a registry so free plan would go quite far?

I just set up the official registry on a VPS (for similar usage pattern) and it was a bit of work and probably much more expensive, this seems quite attractive unless I've misunderstood something.

Fire-Dragon-DoL2• 2 years ago

Yeah it does sound great. The alternative for me is to host my own docker registry on my home server. That would cost me 0 essentially (I have good internet at home)

Alifatisk• 2 years ago

regitry

stpedgwdgfhgdd• 2 years ago

It is unfortunate that the cloudflare dev eco system is tight into the javascript world (e.g. npm). Wasm is not there yet to be a full replacement.

thangngoc893• 2 years ago

I think this is wonderful. I’m running a Gitea instance in one of our dev machine just for private registry. Keeping the instance only had been extra workflow for us.

But 500MB limit of layer size is a dealbreaker for AI related workflow.

geek_at• 2 years ago

gitea does also bring their own registry though. If you self-host you can also use LFS for unlimited filesizes

thangngoc893• 2 years ago

I’m self-hosting gitea just for their private docker registry. LFS is actually slow for heavy deep learning workflow with millions of small files. I’m using DVC [1] instead.

[1] https://dvc.org

victorbjorklund• 2 years ago

Nice. I been seriously thinking about building exactly this (but Im glad someone smarter made it already)

jacobwg4• 2 years ago

The annoying thing about trying to implement a Docker registry on Workers and R2 is that it's so close to having everything you need, but the 500MB request body limit means Workers is unable to accept pushes of layers larger than 500MB. The limit is even lower at 100MB on the Pro plan[0].

We are running a registry that does store content on R2[1], and today this is implemented as the unholy chimera of Cloudflare Workers, AWS CloudFront, Lambda@edge, regular Lambda, S3, and R2.

Pushes go first to CloudFront+Lambda@edge, content is saved in S3 first, then moved to R2 in background jobs. Once it's transited to R2, then pulls are served from R2.

I would so love for Workers + R2 to actually be able to accept pushes of large layers, unfortunately I have yet to talk to anyone at Cloudflare who believes it's possible. Especially in this era of AI/ML models, some container images can have single layers in the 10-100GB range!

[0] https://developers.cloudflare.com/workers/platform/limits/#r...

[1] https://depot.dev/docs/guides/ephemeral-registry

amenghra• 2 years ago

Can you generate a signed url to upload directly to R2? Or perform the upload in chunks?

jacobwg4• 2 years ago

Uploading in chunks could definitely solve the issue, and the OCI Distribution Specification does actually have some language about an optional chunked push API[0].

Unfortunately very few of the registry clients actually support this, critically containerd does not[1], so this means your regular `docker push` and a whole lot of ecosystem tooling does not work.

This also means that the single PUT must be able to support very large pushes as a single request, possibly even larger than what R2 or S3 would allow without using multipart upload. This means you actually need a server to accept the PUT, then do its own chunked upload to object storage or otherwise stage the content before it's finally saved in object storage.

This rules out presigned URLs for push too, since the PUT request made to the presigned URL can be too large for the backing object storage to accept.

There's also other processing that ideally happens on push (like hash digest verification of the pushed layer) that mean a server somewhere needs to be involved.

[0] https://github.com/opencontainers/distribution-spec/blob/mai...

[1] https://github.com/containerd/containerd/blob/192679b05917b5...

telgareith• 2 years ago

What am I missing such that presigned Urls aren't the solution to this issue?

_w1tm• 2 years ago

R2 is ridiculously cheap compared to S3. The price difference was more than 40x when I last looked at it.

zimbatm• 2 years ago

Does the worker need to process the body?

Sometimes, the worker can return a signed URL and have the client directly upload to R2.

znpy2• 2 years ago

Sometimes, the worker can return a signed URL and have the client directly upload to R2.

That's not what client expect though, and that would be (iaas) provider-dependent.

koolba• 2 years ago

We are running a registry that does store content on R2[1], and today this is implemented as the unholy chimera of Cloudflare Workers, AWS CloudFront, Lambda@edge, regular Lambda, S3, and R2.

What’s the advantage over just using ECR? Cost of storage? Cost of bandwidth to read? Hosting provider genetic diversity?

gyre0072• 2 years ago

Cost of storage and egress cost are wildly more expensive on ECR compared to CF+R2

Shakahs• 2 years ago

ECR is slow. Despite being a static datastore presumably backed by S3 it will only serve container image layers at around 150mbps, when dealing with large (10GB) container images this is a problem. R2 will happily serve the same data at multi-gigabit speed.

jacobwg4• 2 years ago

Data transfer costs. Our registry is for our customers, and they expect to pull their images from environments outside AWS, e.g. GitHub Actions.

If that customer has a 2GB image, they want to build the image and then pull it into 10 separate matrix jobs (think like parallel Cypress tests), and they have 1,000 commits in a month, then the AWS data transfer costs are $1,800/mo, just for that one customer to pull their images.

With R2, it acts both as a CDN and since Cloudflare does not charge for egress, reduces the cost to only storage + the one-time transfer out of AWS.

ljm2• 2 years ago

Live by the cloud, die by the cloud, right?

It’s trivial to set up a self hosted docker registry on your own storage. I’m running the helm version of it on my own k3s cluster, the cluster itself costing 20€/mo.

Why would you need all of this fancy vendor lockin when a few low cost ARM boxes can get the job done?

rfoo2• 2 years ago

Because I actually want it to serve 10GB container images to our "enthusiastic" users over the Internet.

Oh, and our "enthusiastic" users want to pull it on 100s of boxes at the same time. What are you going to do? Send a legal notice to them for "DDoS"-ing your poor low cost ARM boxes?

jacobwg4• 2 years ago

Yeah in our case we are operating a private registry on behalf of our customers, so slightly different use-case than running your own registry for your own internal use.

If you do want to run your own registry, there's some great OSS projects including https://github.com/project-zot/zot, https://goharbor.io/, and of course https://github.com/distribution/distribution.

chx2• 2 years ago

Why R2 instead of Backblaze B2? Isn't R2 more than double the price of B2?

captainjapeng• 2 years ago

I was able to push to a serverless-registry deployment a 10GB docker image, I've shared my approach here

https://github.com/cloudflare/serverless-registry/issues/42

mikeocool• 2 years ago

Have any container running tools just implemented basic S3 compatibility for pushing/pulling images? If your registry doesnt accept pushes from untrusted sources, it doesn't seem like there is a ton of value in having "smarts" in the registry server itself.

When you push, the client could just PUT a metadata file and an object for each layer in the object store, and pulling would just read the metadata file, which would tell it where to get each layer. And could use etags to skip downloaded layers that have already been downloaded.

For auth just use the standard S3 auth.

Would be compatible with S3/r2/any other S3-compatible storage.

tfolbrecht• 2 years ago

The docker registry container supports S3 as a storage backend you could use it locally

You can also `docker image save` then write the tarball to S3, then load to use.

champtar2• 2 years ago

I would love if the container pull protocol stopped using custom headers or content-type, so we could use any dumb http server.

mayli• 2 years ago

this? https://github.com/NicolasT/static-container-registry and this? https://github.com/jpetazzo/registrish

champtar2• 2 years ago

Both exemples generate custom nginx config

RyeCombinator• 2 years ago

Great feat.

However I am ever more confused now on what Cloudflare does and builds. They have everything from CDN, DNS to Orange Meets and this now?

rozenmd• 2 years ago

There's a developer platform: https://workers.cloudflare.com/

yazaddaruvala• 2 years ago

My understanding is Cloudflare is a competitor of AWS, Azure, and GCP.

yecuken• 2 years ago

I'm using this registry with regctl[0] to chunk uploads (to circumvent 100MB limit), works just fine for huge layers with models. With regctl you will also get 'mount' query parameter for upload initialization with the proper blob name so you can skip additional R2 copy when multi-part upload finalisation which speeds up the upload (and avoids crashes on larger blobs). This is not part of docker registry API, so I never got to PR that.

[0] https://github.com/regclient/regclient

miohtama• 2 years ago

When you switch to private Docker or Github registry to Cloudflare, are you effectively just trading one vendor lock in to another, or is there more into this?

vineyardmike• 2 years ago

None of these are really vendor lock in. The registry protocol is an open standard, this is just one more source that implements it. So you’re only locked in as far as your data is stored somewhere, but that data is behind an open API, so minimal risk there.

spikey_sanju• 2 years ago

Interesting. Just wish it handled larger image layers a bit better!

jzelinskie• 2 years ago

If you are a CloudFlare employee reading this, you should get involved with the OCI Distribution group that develops the standards for the registry: https://github.com/opencontainers/distribution-spec

gyre0072• 2 years ago

OCI is demonstrably broken as a specification body as demonstrated by the referrers API. Distirbution spec as it is at the moment is just a very poorly written technical doc.

beeboobaa3• 2 years ago

Can you explain a bit more what you mean?

re-thc• 2 years ago

you should get involved with the OCI Distribution group

This is likely just a sample to showcase workers. Not sure it's enough reason for CloudFlare to get involved?

fswd• 2 years ago

using this same architecture, it would be cool to build a serverless-git

mdaniel• 2 years ago

I would have thought for sure someone would have already tried that, but regrettably trying to search for "serverless git" coughs up innumerable references to the framework that is hosted on GIThub

Anyway, I was curious how much work such a stunt would be and based on the git-http-backend docs <https://git.github.io/git-scm.com/docs/git-http-backend#Docu...> it seems like there are actually a manageable number of endpoints

I actually prefer their second scenario of splitting out access to the objects and pack files but since doing that would still require a function (or, ahem, a web server running) I suspect that optimization is not within the scope of what you had in mind

jedberg• 2 years ago

Isn’t GitHub already serverless git?

airocker• 2 years ago

Is there a registry that would work on extremely cheap disk storage if the use case if only push and very infrequent pulls?

qudat• 2 years ago

This is pretty nice. Does it support an API for deleting images (and having it properly garbage-collected)? It looks like maybe this does it? https://github.com/cloudflare/serverless-registry/blob/13c4e...

We have a managed docker registry and could have definitely used this project!

Slightly unrelated, but we've been experimenting with using SSH for authenticating with a docker registry if anyone is interested: https://github.com/picosh/tunkit?tab=readme-ov-file#why

bravetraveler• 2 years ago

Interesting approach when running one of these on your 'LAN' is relatively easy

Though, to be fair, the pull-through mechanism in the reference registry been kind of goofy for years. Ask me how I know /s

ImJasonH• 2 years ago

I built a similar PoC using Workers+R2, before Cloudflare released theirs, in case you find it useful: https://github.com/chainguard-dev/crow-registry

We eventually built our own registry in Go running on Cloud Run, which now serves all our images on cgr.dev.

Zero egress fees is really a game changer.

ram_rattle• 2 years ago

Looks like a neat idea, does anyone know any open source version that does just this?

Serverless-registry: A Docker registry backed by Workers and R2

Related Stories