7 ms·

DigitalOcean Container Registry Now GA

81 points by raiyu 6y ago

deleted 6y ago
[deleted]
hacknat 6y ago
Seems like everyone is more than willing to step in to fill dockerhub's shoes.
- dylz 6y ago
  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?
  - tracker1 6y ago
    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.
    - CommanderData 6y ago
      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.
      - Dylan16807 6y ago
        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"
        imtringued 6y ago
        There are lots of alternatives. Artifactory, Gitlab Registry, ... the list goes on.
jacques_chester 6y ago
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.
- 6y ago
DanielDent 6y ago
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.
- skunkworker 6y ago
  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."
- bpye 6y ago
  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.
- stingraycharles 6y ago
  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.
lukevp 6y ago
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/ https://www.digitalocean.com/products/spaces/ [2]: https://aws.amazon.com/s3/ https://aws.amazon.com/s3/ [3]: https://news.ycombinator.com/item?id=17225665 https://news.ycombinator.com/item?id=17225665
- tebbers 6y ago
  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.
- csunbird 6y ago
  Spaces are build on ceph, as far as I can understand. Edit: It is mentioned here https://www.digitalocean.com/docs/spaces/ https://www.digitalocean.com/docs/spaces/
- BillinghamJ 6y ago
  That S3 number is not an SLA. It's just saying that's what they're hoping they'll achieve by its design.
- throwaway201103 6y ago
  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.
jlelse 6y ago
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/ https://www.scaleway.com/en/container-registry/ I haven't tried it out myself though.
judge2020 6y ago
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.
- sieabahlpark 6y ago
  They don't really care about api access at that granular level because most of their customers never use any of the features. They're trying to just create a not-as-good cloud provider which lacks even a 3rd US based data center. Oh and their free LE certs require you to hand over the root domain to them so they can manage it. Completely baffles me why they can't figure out nameserver delegations and accept they're incompatible with companies like Cloudflare. Really DO, build a 3rd US data center that is somewhere in Texas so you have a little more geographic coverage besides the coasts. Fix your terrible access key permissions (oh yeah a storage client should be able to delete my domain registration...)
- onlywicked 6y ago
  They do have specific and read only token for the Container Registry.
bostonvaulter2 6y ago
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.
- bgar 6y ago
  Correct, it means General Availability. It’s pretty common to abbreviate it (actually, I don’t think I ever see it written out).
- why-el 6y ago
  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. :)
deleted 6y ago
[deleted]
WillPostForFood 6y ago
what do they mean by "GA"?
deleted 6y ago
[deleted]

81 points by raiyu 6y ago

deleted 6y ago

[deleted]

hacknat 6y ago

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

dylz 6y ago
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?
- tracker1 6y ago
  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.
  - CommanderData 6y ago
    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.
    - Dylan16807 6y ago
      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"
      - imtringued 6y ago
        There are lots of alternatives. Artifactory, Gitlab Registry, ... the list goes on.

jacques_chester 6y ago

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.

6y ago

DanielDent 6y ago

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.

skunkworker 6y ago
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."
bpye 6y ago
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.
stingraycharles 6y ago
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.

lukevp 6y ago

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/ https://www.digitalocean.com/products/spaces/ [2]: https://aws.amazon.com/s3/ https://aws.amazon.com/s3/ [3]: https://news.ycombinator.com/item?id=17225665 https://news.ycombinator.com/item?id=17225665

tebbers 6y ago
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.
csunbird 6y ago
Spaces are build on ceph, as far as I can understand. Edit: It is mentioned here https://www.digitalocean.com/docs/spaces/ https://www.digitalocean.com/docs/spaces/
BillinghamJ 6y ago
That S3 number is not an SLA. It's just saying that's what they're hoping they'll achieve by its design.
throwaway201103 6y ago
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.

jlelse 6y ago

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/ https://www.scaleway.com/en/container-registry/ I haven't tried it out myself though.

judge2020 6y ago

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.

sieabahlpark 6y ago
They don't really care about api access at that granular level because most of their customers never use any of the features. They're trying to just create a not-as-good cloud provider which lacks even a 3rd US based data center. Oh and their free LE certs require you to hand over the root domain to them so they can manage it. Completely baffles me why they can't figure out nameserver delegations and accept they're incompatible with companies like Cloudflare. Really DO, build a 3rd US data center that is somewhere in Texas so you have a little more geographic coverage besides the coasts. Fix your terrible access key permissions (oh yeah a storage client should be able to delete my domain registration...)
onlywicked 6y ago
They do have specific and read only token for the Container Registry.

bostonvaulter2 6y ago

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.

bgar 6y ago
Correct, it means General Availability. It’s pretty common to abbreviate it (actually, I don’t think I ever see it written out).
why-el 6y ago
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. :)

deleted 6y ago

[deleted]

WillPostForFood 6y ago

what do they mean by "GA"?

deleted 6y ago

[deleted]