DigitalOcean Container Registry Now GA | Hacker News Reader

DigitalOcean Container Registry Now GA

digitalocean.com

81 pointsraiyu34 comments

I'm a big DO fan as their pricing models are easier to understand, and use them myself for personal projects, but I would hesitate to use some of their products at an enterprise. The reason is that they do not seem committed to SLAs and offering metrics around their reliability.

One example of this is in DO Spaces [1]. Nowhere on their site do they say the durability of the data, or whether they have multiple AZs within one DC for availability, or anything like that. Compare that with AWS S3, where the 11 9's of durability is front and center on the page [2]. Marketing Spaces as S3-compatible without providing transparency on the reliability of the underlying storage engine feels disingenuous to me. Especially when, upon investigation, there are several complaints of data loss on the Spaces storage engine with DO not able to provide assistance [3].

Now whether that's an issue for a container registry, maybe not so much, since you can likely rebuild containers if you have reproducible builds, but it's a pattern I've seen across their offerings.

[1]: https://www.digitalocean.com/products/spaces/ [2]: https://aws.amazon.com/s3/ [3]: https://news.ycombinator.com/item?id=17225665

That S3 number is not an SLA. It's just saying that's what they're hoping they'll achieve by its design.

I also noticed this with their managed databases product and was the main reason why I went with AWS RDS - they don't have availability zones so if they have a data centre issue, all your database instances including your standby nodes could be affected.

Spaces are build on ceph, as far as I can understand.

Edit: It is mentioned here https://www.digitalocean.com/docs/spaces/

As we've seen recently, with cloud providers you are at the mercy of their "sole discretion" judgment on terms of service violations. You could be shut down tomorrow with no recourse. So you still have to do all your own backups and continuity of operations planning across different providers or in-house. To me this really calls into question the entire value proposition, since if you want to be safe you need to have the ability to redeploy your entire business on another provider at a moment's notice.

Sadly tokens you use for Container Registry are full access tokens - they can also be used for everything else in the Digital Ocean API. I don't see why DO doesn't have scoped token support yet.

They do have specific and read only token for the Container Registry.

As an alternative, Scaleway is offering managed container registry too, but with a pay-as-you-go pricing: https://www.scaleway.com/en/container-registry/

I haven't tried it out myself though.

What is GA? I don't see GA mentioned on the page, or any words starting with G, does it mean generally available? If so I don't think the abbreviation is necessary.

GA (General Availability) just meant out of "Beta". If you don't see "Beta", you can assume GA unless they word things a bit weirdly and not mention "Beta" but a synonym, such a "limited availability". Just be careful and read the full page, which seems like it's your habit anyway. :)

Correct, it means General Availability. It’s pretty common to abbreviate it (actually, I don’t think I ever see it written out).

Seems like everyone is more than willing to step in to fill dockerhub's shoes.

What do you expect when you try to monopolise a key-value store of static files and attempt to only ship binaries that remove the ability to define your own registry?

It's not like dockerhub gets the electricity, storage hardware and bandwidth without cost. A startup/application can only bleed money for so long before they need to at least try to break even.

I'm not sure why I see so many comments with expectations companies should provide services for free. Considering DH is hosted in AWS costs must be insane. Limits should have been imposed sooner imo. I've seen many companies pull images hundreds of times per hour with caches being cleared in between. Barely coming under Docker Hubs rate limits.

I'm not sure why you and the comment you're replying to are ignoring the second half of the sentence. "attempt to only ship binaries that remove the ability to define your own registry"

There are lots of alternatives. Artifactory, Gitlab Registry, ... the list goes on.

As more of these emerge, we need a Registry V3 API with some key changes: images and layers should be (1) expressible as URNs, not URLs and (2) entirely content-addressable. A nice bonus would be to (3) register a URI scheme to make image references more easily identified in other places (such as YAML, YAML oh and YAML).

Right now (1) causes the most pain. Suppose you have a reference to 'ubuntu'. That actually expands to `index.docker.io/library/ubuntu:latest`. If you decide to switch to a private registry or alternative public registry, you now need to find every instance of `ubuntu` and change it to `registry.example.com/library/ubuntu:latest`. This is called the "relocation problem".

You might think this is easy: just find references and update them. Firstly, what a colossal hack. Secondly, "just find"ing the references turns out to be a game of whack-a-mole. People stuff image references into all sorts of whacky places and at many different levels of detail. Any such solution is stringly typed and relies on a pile of wobbly heuristics. We need to do better.

So what do I mean by "URNs, not URLs"? I mean that an ideal scheme is agnostic to the registry's domain. Maven gets this basically correct: every package has its "coordinates" triplet of groupid:artifactid:version. These represent a universal name that can be submitted to any conforming Maven server for resolution into a pile of bits. Maybe they're there on the server, maybe they aren't, but you won't have to change all your references when you switch servers.

This leads to (2), content addressability. Perhaps you are confused -- doesn't that already exist? Yes, but no. You can add `@sha256:abcdef123...` to your references. But this resolves only within that domain and only for that repository name. I can wind up with a variety of names like `ubuntu@sha256:123abc...`, `library/ubuntu@sha256:123abc...` and so on. These are resolved to the same bits, but I am still stuck with the entire nightmare of image relocation.

It gets worse with layers. These are addressed by digest, but scoped to repositories. You can't ask the registry "do you have layer `10a9b4...`?", just as you can't ask "do you have an existing image of any name with the digest `bc4d9ee...?`". You must include the repository, such as `library/ubuntu`, in the query. That means you must know in advance what repos and images are already in the target registry, otherwise you can't even ask if they are in the target registry.

As for (3), it would be an alternative or addition to (1). If all image references started with `oci://`, then it would be tremendously easier to find them and modify them programmatically. There would still be jank and corner cases, but it would be less janky, with fewer corners.

The reason layers are scoped is so that they can be authed to something. Public only registries don't have this restriction, but otherwise if you saw a reference to a layer then you would be able to access it. The alternatives are to encrypt everything, or shard by access control (potentially to larger chunks than they are now.

I almost mentioned the auth thing but left it out as a bit of an implementation detail.

It would not be difficult to map from a digest to a list of repositories.

Thats a information disclosure potentially.

I disagree. You can still apply rules to repo/image and have those descend to blobs, just as happens now. If you ask for a blob and have access to repo/image with that blob, you see it. Otherwise not.

Champion such an updated standard.

Here I am!

Touché :)

what do they mean by "GA"?

sigh. DigitalOcean continues their march towards irrelevance.

First it was the app platform and now this. Gouging us at $0.10/gigabyte bandwidth charges makes us: (1) think less of you, and (2) adds a bunch of cognitive complexity & work to developers' lives.

If this is how it's going to be we may as well just use AWS or move on to one of your competitors that isn't trying to pretend that bandwidth is expensive. It isn't, and there isn't any reason we should have to design applications around artificially absurdly inflated costs.

Even Oracle pretends to understand this. _ORACLE_ are the ones trying to make the case that they aren't only about having hostages/locked in customers.

When Oracle is beating you on this metric you've really jumped the shark.

I don’t think this is reasonable criticism. It’s more than fair for them to charge for egress traffic, and they’re doing it at a price point less than AWS.

Of course it would be nicer if things were free, but to claim this to be evidence of a march into irrelevance? For charging for egress traffic on a Docker registry? That’s a bit too much don’t you think? Especially considering how easy it is to set up some GitHub action and or another CI tool that constantly keeps hammering their registries without a lot of value. Docker (the company) clearly feels the pain of this a lot, and they just want to prevent this type of thing from happening.

If I were to guess the intended use case is to help you with deployments inside the DO cloud, and to actually reduce your ingress traffic when pulling from other, remote docker registries. It’s a win/win for these use cases, and to be honest, it’s not expensive.

Besides, DO’s pricing still is very much favorable compared to other cloud vendors.

There are many CDNs that make money charging < $0.01/gb.

Indeed DigitalOcean themselves built their place in the market by charging $0.01/gb for bandwidth. How do we reasonably get to $0.10 as is the case here?

If it were really that expensive for them they could outsource it to a CDN for well under $0.01/gb at their scale, which would leave them the ability to get margin. But all of this pricing is in fact completely detached from the underlying physical realities -- they are charging these prices because they think they can get away with it, not because they need to do so to cover costs and have some margin.

Bandwidth prices shouldn't be going up, indeed they should be going down. 100 gigabit interconnects are a thing now.

I believe that bandwidth charge is after you've exceeded the monthly allowance and for when someone wants to pull your image over the internet, and not distributing to your instances.

"In the future, each plan will have a bandwidth allowance and additional outbound data transfer (from the registry to the internet) will be $0.10/GiB."

BW topic is not related to container registry, but worth mentioning as it is being discussed in this thread. Regarding the outbound data transfer pricing for a $5/month droplet, you get minimum 1TB/month free Internet-bound BW. The price of 0.01/GB kicks in only after that.

Disclaimer - I work for DigitialOcean.

There's a really big gap between the $0.01/gb you are talking about being charged on droplets and the $0.10/gb that DigitalOcean is using on newer offerings like this and "App Platform".

https://www.digitalocean.com/docs/container-registry/ - "In the future, each plan will have a bandwidth allowance and additional outbound data transfer (from the registry to the internet) will be $0.10/GiB."

The fact that somebody could put a caching proxy in front of the container registry -- on a droplet also hosted at DigitalOcean -- and have their bandwidth costs fall 10x for doing that does indeed provide further illustration of the absurdity of DigitalOcean's new approach to bandwidth pricing.

I don’t think I agree. This is still a great choice if you need a container registry for your images that you run on Digital Ocean compute - as far as I can tell there is no bandwidth charge there. This means that DO has a total container hosting platform.

You should probably double-check on egress data pricing from AWS.

Reply on news.ycombinator.com