This looks like it still uses Docker's craptastic who-needs-image-verification protocol.
No thanks.
Google Container Registry
21–30 of 34 posts
Re: Google Container Registry
#22Nothing about google inspires confidence, especially Eric schimdt. Socially retarded autistic people don't inspire much confidence. Worse, they are dangerous.
Re: Google Container Registry
#23>Pricing >During the beta period you will be charged only for the Google Cloud Storage storage and network egress consumed by your Docker images. Dammit google, this is not how you price things. Especially when people have been burned by price jumps on your service before. I don't know why i'd bother integrating with a service when I have no idea what the cost will be.
This could end up being more expensive than Docker's own or CoreOS's. People would rather pay a flat fee rather than worrying about storage and bandwidth.
[deleted]
Re: Google Container Registry
#24Interesting. I've been using google/docker-registry to have a private docker registry based in Google Cloud Storage for some time now. I wonder what additional benefits this service will provide for the (presumably) higher price once it comes out of beta.
Re: Google Container Registry
#25>Pricing >During the beta period you will be charged only for the Google Cloud Storage storage and network egress consumed by your Docker images. Dammit google, this is not how you price things. Especially when people have been burned by price jumps on your service before. I don't know why i'd bother integrating with a service when I have no idea what the cost will be.
Your quote says it is a beta service. If you are betting the farm on beta services or expecting them not to change under you during a beta period, it really is only your own fault.
Re: Google Container Registry
#26Earlier quoted context omitted.
I imagine that wouldn't be very likely in this case—this is much less like Google's usual "let's build some random thing and see if customers like it", and instead very much in the vein of the way Amazon treats AWS: as a set of infrastructure services they themselves consume, but also happen to expose to the public. Now, they might make it private in the future, but as long as Google are using containers for everythi…
From what I know of Google's infrastructure, they are very unlikely to be consuming this internally, just like the rest of GCP. Just because they use containers doesn't mean they use this container repository. Just because they use Java web servers doesn't mean they use AppEngine.
Google absolutely uses App Engine internally, and many other GCP offerings as well. This is simply inaccurate.
Re: Google Container Registry
#27Aweosme, I can't wait till they pull the plug out from under me.
I imagine that wouldn't be very likely in this case—this is much less like Google's usual "let's build some random thing and see if customers like it", and instead very much in the vein of the way Amazon treats AWS: as a set of infrastructure services they themselves consume, but also happen to expose to the public. Now, they might make it private in the future, but as long as Google are using containers for everythi…
> a set of infrastructure services they themselves consume, but also happen to expose to the public
So like google code then. I mean they need all that source control infrastructure anyway, so they'd never shut something like that down. Oh wait....
Re: Google Container Registry
#28Earlier quoted context omitted.
>I'd rather have it from docker, who made the tool for my containers, than google. Interesting take on things. It's mostly contributions from Google that made containers viable in the first place.
True that, the original LXC library was Google. Then Docker wrote their own implementation called libcontainer (and systemd-nspawn popped about). While Google made containers possible I think Docker made them happen. I can't imagine committing an LXC container and pushing it to a repo if it weren't for docker. Nor would I want to manage raw networking in LXC. Nor sharing of filesystems.
(Tedious disclaimer: my opinion, not my employer's. Not representing anybody else. I work at Google, not on borg)
You might find the borg paper very interesting: http://static.googleusercontent.com/media/research.google.co...
The bits of containers that made it out into lxc are essentially borglet features. The rest of the infrastructure around it was never released to the outside world, and now docker is recreating some of that infrastructure. We've had borg for a long time ;)
There's lots more detail in the paper about how these pieces relate to each other.
Re: Google Container Registry
#29>Pricing >During the beta period you will be charged only for the Google Cloud Storage storage and network egress consumed by your Docker images. Dammit google, this is not how you price things. Especially when people have been burned by price jumps on your service before. I don't know why i'd bother integrating with a service when I have no idea what the cost will be.
> During the beta period you will be charged only for the Google Cloud Storage storage and network egress consumed by your Docker images. Is there any guarantee the cost will be a linear function of those things? Quadratic? Quartic? Exponential? Fine print, fine print everywhere.
Down voted by fans I see.
Re: Google Container Registry
#30Earlier quoted context omitted.
From what I know of Google's infrastructure, they are very unlikely to be consuming this internally, just like the rest of GCP. Just because they use containers doesn't mean they use this container repository. Just because they use Java web servers doesn't mean they use AppEngine.
Google absolutely uses App Engine internally, and many other GCP offerings as well. This is simply inaccurate.
They use the external version of App Engine to run any of their customer-facing products? Which ones? Products -- I'm not talking about marketing micro-sites.