This is really much needed (if they did it right). The container registry @ docker is terribly broken and the user experience is frustrating. I ended up using Git repositories + building on server because it was "so unusable".
Same story for my team.
DockerHub is a mess from a UX perspective and pricing structure which goes against the microservices concepts that Docker enables.
More than 50 container images and I need to "Contact Sales" for an Enterprise contract? Really?
In a (brief) defense of Docker Hub, it has gotten WAY better in just the last 6 months. UX is sufficient for the number of times you interact with the website, versus command line. Still it is very slow and this has an impact on my continuous deployment ambitions.
In a world where we routinely ship 0.x tools to production, it may feel a bit peculiar to see 2.0 as being the first 'production ready' version for Docker's suite of tools, but that very well may be the reality.
Docker files are still insufficient for building anything but trivial bloated stacks using any docker registry build service, forcing you to setup a CI pipeline to build and push your containers to your registry. They froze the syntax and this mountain of trouble is just getting worse.
Then they modernised the UI and its just like ... Terrible. I have no more words for how much of a step backwards the latest UI is compared to the original one.
yea I'm hoping that this will speed up pushing/pulling and it's not just on the Docker Engine side because taking 1+ minutes to push a >500MB image is ridiculous...
This is definitely a great move for Amazon. As it is now, the docker registry is ridiculously difficult to get set up and secured.
That said, I find myself wishing that Amazon would contribute more back to the Docker project (specifically the registry in this case), and then provide a hosted option with IAM integration, etc.
The existing AWS ecosystem is already enough for me to want to stay with them, but I'd say the Docker ecosystem is fragile enough that it could use some bolstering just to keep it viable and ensure Amazon's investments don't go down the tube if something better comes along.
you hit a sensible point which of course we all know but refuse to take into account:
the more AWS provides, the more it does right, the more locked in you are in AWS. At some point everything will be AWS with zero commit back to any other project - stall.
In fact when we reach that point it's going to be difficult for AWS to provide new things since everything AWS does is basically provide open source tools with a scaling, programmable deployment AND management model (basically what open source tools usually lack).
Docker and Kubernetes turn cloud providers into a commodity - which is why Amazon is not keen on promoting them more than is required to satisfy market demand.
If you are the market leader, lock in is your strategy; Hence the launch of so many new AWS services.
Google's play with Kubernetes is to reduce the dependency on proprietary cloud features. They are betting they can deliver better/faster/cheaper cloud services when compared to AWS. It should be interesting to watch, and great for us consumers of cloud services.
I think Kubernetes is a good example of the right way to go about things. It gives a taste of what's possible on Google infrastructure and lowers the migration cost if you decide to move to Google (from what I understand).
Both Google and Amazon will hugely benefit just by making the internet more ubiquitous (all roads lead to Rome). Google seems to realize that providing great open-source tools and systems is a good way to bolster their business. Amazon, on the other hand, provides great infrastructure but doesn't seem to be incredibly interested in anything that doesn't increase lock-in.
It;d be nice if someone proposed a comprehensive comparison of google cloud vs aws, including featureset compare, porting-to-and-from compare, and benchmarks.
Let's not dream, let's get started! A few challenges (list gets longer every day, some asymmetric features), but I think it's a great idea. Since it's got to be grown/updated constantly, where should it live, maybe a github page? Benchmarks is pretty close via this: https://github.com/GoogleCloudPlatform/PerfKitBenchmarker I'm interested; what parts do you think you could contribute? It strikes me as a thing that's far more valuable if the community does it.
Google Container Registry is definitely a lot faster than DockerHub in my experience. However, it is still lacking some important features, like being able to delete an image. We have a CI pipeline building Docker images and pushing to GCR. This is using a ton of storage and there is no documented method to remove un-needed images. They did recently add an option to un-tag an image by clicking an "X" on each tag, but it still doesn't remove the image from the Google Cloud Storage bucket that it is stored in, just removes the tag. Occasionally we will have issues with using the "latest" tag as well where we can push an image to latest but when we retrieve the image, we get a previous version. For the most part we eliminated using the latest tag, which is probably a good idea anyways.
I believe when you remove all tags, it just deletes the image (takes a little time though, there seems like to be an async cleanup operation). I remember having the data gone from storage bucket too but gonna check again.
I sent an email to Google last week and they responded:
"One of the things we are investigating is opt-in garbage collection to clear out old and unreachable images from the graph, but we do not have this today."
It's crazy. Amazon's container registry only charges you for the storage, which means they've got something like ELBs tuned for this, so they don't care about the instance time on their side. They're only charging you for what you're storing in S3 (although at 10 cents/GB, it _is_ more expensive then straight S3, but still extremely reasonable for not needing to manage your own registry).
No UI out of the box (Registry:v2). DTR has a 'health' UI that is pretty worthless since you can't browse images. There are other frontend tools that work with registry:v2 though, such as Portus:
What would you actually want to use the UI for? For my part, all interactions with the registry are entirely automated. We set it up, and I forgot all about it. It's low level plumbing.
It's also, in my experience, much slower (inexplicably, since apparently Docker Hub is also backed by S3 under the hood). Using the official docker registry images (only modification was to point them to a private S3 bucket w/ credentials) resulted in frequent push/pull failures with 500 errors. Even when they succeeded, images were taking ~15-20 minutes to push. I filed a GitHub issue and the only suggestion was to decrease the chunk size, which did not improve anything.
Now we use quay.io and it's much easier and faster.
I have seen a lot of people having trouble in IRC with setting it up and one more thing I have to worry about uptime myself (even if it's fairly simple) is not something I'm a fan of
PM for Quay.io here, my contact information is in my profile if you would like to discuss ways in which we can improve the product. We are always looking for ways to deliver the best possible experience.
Official API support would be nice. We need to query repos for specific tags. we're using the unofficial API currently, but having our cd pipeline rely on that does not feel right.
1. You have big rectangular elements that represent repositories, but 90% of that rectangle is dead space. Apply the click event to the whole rectangle, not just the title of the repo.
2. As a user, I am solely a member of an organization. I don't need to see a dashboard with just 3 starred project, 3 random projects from my org, and 3 of my personal projects (of which there are 0). Just let me start at my org's page, or let me see every project from my org on the dashboard.
3. Wtf is the "list view" link on my dashboard? It appears to just show me 3 random projects out of the 9 in my organization, and completely hide the "starred" and "personal" sections?
Bugs:
1. Until recently, the Sign Out link 100% always threw an HTTP 500 error. Today, that is not happening? Who knows. Weird.
2. My IT guy created an account for me. As a result, I received an email with a login link. However, 24 hours later, I was logged out and could not log back in, because I never had a password set. Had to get the IT guy to send me another welcome email. IF PEOPLE NEED TO SET UP A PASSWORD, YOU SHOULD FORCE THEM TO, NOT HOPE THEY EVENTUALLY POKE AROUND AND FIND THE SET PASSWORD SCREEN.
Speaking as someone who has paid for enterprise quay.io (CoreOS enterprise registry), and seen the source code and docker image.... Run far away. Not even the most basic security or availability precautions were taken.
A casual security evaluation revealed that all of the 20+ processes in the quay.io registry container run as real root. Worse, the system has no authentication for image uploading allowing -anyone- clobber any existing image. Auth only exists for reading images which is entirely backwards. Requests for to patch these and other holes myself were denied.
Don't even get me started on general instability or that on a failed build it would hang and never accept new ones without a manual container restart.
Had to pull the plug on the whole thing and replace it with a few git hooks and a vanilla docker registry... Which has been simple and rock solid.
What I'd really like is an all-in-one service that incorporated Docker Content Trust[0]. While I'd prefer that they'd used something a bit more mainstream (e.g. GPG), some image signing is better than none at all.
Doing this today requires a fair bit of extra infrastructure over a basic v2 registry, and really it'd be much nicer to have a single service that was able to manage this.
49 comments
[ 4.7 ms ] story [ 105 ms ] threadHopefully, this changes things.
More than 50 container images and I need to "Contact Sales" for an Enterprise contract? Really?
In a world where we routinely ship 0.x tools to production, it may feel a bit peculiar to see 2.0 as being the first 'production ready' version for Docker's suite of tools, but that very well may be the reality.
Then they modernised the UI and its just like ... Terrible. I have no more words for how much of a step backwards the latest UI is compared to the original one.
That said, I find myself wishing that Amazon would contribute more back to the Docker project (specifically the registry in this case), and then provide a hosted option with IAM integration, etc.
The existing AWS ecosystem is already enough for me to want to stay with them, but I'd say the Docker ecosystem is fragile enough that it could use some bolstering just to keep it viable and ensure Amazon's investments don't go down the tube if something better comes along.
the more AWS provides, the more it does right, the more locked in you are in AWS. At some point everything will be AWS with zero commit back to any other project - stall.
In fact when we reach that point it's going to be difficult for AWS to provide new things since everything AWS does is basically provide open source tools with a scaling, programmable deployment AND management model (basically what open source tools usually lack).
Kinda scary when you think of it for too long.
If you are the market leader, lock in is your strategy; Hence the launch of so many new AWS services.
Google's play with Kubernetes is to reduce the dependency on proprietary cloud features. They are betting they can deliver better/faster/cheaper cloud services when compared to AWS. It should be interesting to watch, and great for us consumers of cloud services.
Both Google and Amazon will hugely benefit just by making the internet more ubiquitous (all roads lead to Rome). Google seems to realize that providing great open-source tools and systems is a good way to bolster their business. Amazon, on the other hand, provides great infrastructure but doesn't seem to be incredibly interested in anything that doesn't increase lock-in.
It recently hit GA and is super fast. You can use it from anywhere -- not just GCE.
(Disclaimer: I used to work at Google on GCE/GKE/Kubernetes).
/dream
Let's not dream, let's get started! A few challenges (list gets longer every day, some asymmetric features), but I think it's a great idea. Since it's got to be grown/updated constantly, where should it live, maybe a github page? Benchmarks is pretty close via this: https://github.com/GoogleCloudPlatform/PerfKitBenchmarker I'm interested; what parts do you think you could contribute? It strikes me as a thing that's far more valuable if the community does it.
id think google has enough money to assign people to it if they want them to switch from aws. community can always build on that.
"One of the things we are investigating is opt-in garbage collection to clear out old and unreachable images from the graph, but we do not have this today."
This is typically when they release stuff
https://github.com/SUSE/Portus
Now we use quay.io and it's much easier and faster.
1. You have big rectangular elements that represent repositories, but 90% of that rectangle is dead space. Apply the click event to the whole rectangle, not just the title of the repo.
2. As a user, I am solely a member of an organization. I don't need to see a dashboard with just 3 starred project, 3 random projects from my org, and 3 of my personal projects (of which there are 0). Just let me start at my org's page, or let me see every project from my org on the dashboard.
3. Wtf is the "list view" link on my dashboard? It appears to just show me 3 random projects out of the 9 in my organization, and completely hide the "starred" and "personal" sections?
Bugs:
1. Until recently, the Sign Out link 100% always threw an HTTP 500 error. Today, that is not happening? Who knows. Weird.
2. My IT guy created an account for me. As a result, I received an email with a login link. However, 24 hours later, I was logged out and could not log back in, because I never had a password set. Had to get the IT guy to send me another welcome email. IF PEOPLE NEED TO SET UP A PASSWORD, YOU SHOULD FORCE THEM TO, NOT HOPE THEY EVENTUALLY POKE AROUND AND FIND THE SET PASSWORD SCREEN.
A casual security evaluation revealed that all of the 20+ processes in the quay.io registry container run as real root. Worse, the system has no authentication for image uploading allowing -anyone- clobber any existing image. Auth only exists for reading images which is entirely backwards. Requests for to patch these and other holes myself were denied.
Don't even get me started on general instability or that on a failed build it would hang and never accept new ones without a manual container restart.
Had to pull the plug on the whole thing and replace it with a few git hooks and a vanilla docker registry... Which has been simple and rock solid.
Doing this today requires a fair bit of extra infrastructure over a basic v2 registry, and really it'd be much nicer to have a single service that was able to manage this.
0: https://blog.docker.com/2015/08/content-trust-docker-1-8/
- Replay attack prevention
- Freshness guarantees (so you can't be given older, vulnerable images)
- Trusted, delegated signing
AWS ECR: $0.10/GB-month (+ data transfer)
quay.io: $12/month - cheapest plan (5 repos)
docker.com: $7/month - cheapest plan (5 repos)
https://aws.amazon.com/ecr/pricing/ https://quay.io/plans/ https://www.docker.com/pricing