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.<p>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].<p>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.<p>[1]: <a href="https://www.digitalocean.com/products/spaces/" rel="nofollow">https://www.digitalocean.com/products/spaces/</a>
[2]: <a href="https://aws.amazon.com/s3/" rel="nofollow">https://aws.amazon.com/s3/</a>
[3]: <a href="https://news.ycombinator.com/item?id=17225665" rel="nofollow">https://news.ycombinator.com/item?id=17225665</a>
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.
As an alternative, Scaleway is offering managed container registry too, but with a pay-as-you-go pricing: <a href="https://www.scaleway.com/en/container-registry/" rel="nofollow">https://www.scaleway.com/en/container-registry/</a><p>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.
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).<p>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".<p>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.<p>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.<p>This leads to (2), content addressability. Perhaps you are confused -- doesn't that already exist? Yes, but no. You <i>can</i> add `@sha256:abcdef123...` to your references. But this resolves <i>only within that domain</i> and <i>only for that repository name</i>. 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.<p>It gets worse with layers. These are addressed by digest, but <i>scoped</i> 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 <i>in advance</i> what repos and images are already in the target registry, otherwise you can't even <i>ask</i> if they are in the target registry.<p>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.
<i>sigh</i>. DigitalOcean continues their march towards irrelevance.<p>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.<p>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.<p>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.<p>When Oracle is beating you on this metric you've <i>really</i> jumped the shark.