Will it be 18 or 24 months before Google discontinues this product offering? How long will customers who chose to use this offering have to move to another solution once Google discontinues it?
What do you all think of Cloud Native Buildpacks?* A slightly different approach to solving some of the same problems of handling dependency and security updates off-cycle from application updates.
Hi, you have covered base images vs distroless images in your article.
A lot of organizations don't yet have the tooling required to maintain distroless images (since that tooling extends all the way to developer machines).
Have you considered a hybrid option, where in GKE, you automatically keep this base image layer auto-updated when running on cos? It could give organizations that don't have distroless capability to still use vanilla docker tooling, but still get the same benefits of distroless at runtime (and potential of increased adoption it might drive to GKE)?
Is there a dockerhub like interface where I can see all of the repos and available tags? I clicked several links in the blog but didn't see anything similar.
The Ubuntu base image is Ubuntu 16.04, which is an interesting choice. 18.04 LTS has been out for awhile now, so I would have expected it to at least be an option.
It's betting that Google are better package maintainers than Debian/CentOS/Ubuntu, especially when it comes to maintaining container images. From a purely technical, and financial, point of view, it's likely true.
Of course, they could have bolstered the distro teams. And the fact that the repositories are within GCR, not Docker, is just convenience.
It brings you closer into Googles warm, technototalitarian embrace, is what I mean.
This is awesome - is there any thing similar for Azure? Or possible 3rd party solutions that do the same? We don’t leverage GCP but I am very envious of this feature. Would love the community to help point me in the right direction to get same functionality - mainly not having to maintain and patch Ubuntu 16.0.4 images
Yeah, it's called Red Hat Enterprise Linux ;-) It's available on all the cloud providers and has a better API/ABI guarantee as well as very, very well defined commitments to patching and lifecycle :-)
Does Google (or any of the other cloud vendors) audit/review the actual source code of packages used in the images? such as apache, nginx, openjdk, etc? or do they just run a scanner that test for known vulnerabilities?
I generally agree with you. However I also feel that the ABI guarantees by Red Hat, Canonical and the Debian project are fairly trustworthy. Rolling forward automatically is much less risky, taken overall, than a rotting pin.
I don't understand this comment, what are you suggesting Google will do? Surreptitiously insert code into your binary during a patch?
If you are running in Google cloud, its their machines and they have power to do pretty much whatever they want anyway. How would this feature affect anything?
[+] [-] dlor|7 years ago|reply
[+] [-] JaimeThompson|7 years ago|reply
[+] [-] Operyl|7 years ago|reply
[+] [-] drewda|7 years ago|reply
* https://buildpacks.io/
[+] [-] alwaysdoit|7 years ago|reply
FROM ubuntu:16.04
Won't that pull the latest official Ubuntu image with that tag?
[+] [-] thibautg|7 years ago|reply
They maintain official RHEL-based images available on their own catalog [1]
Some images are "s2i" (Source-to-Image) which are automatically built by merging a vetted base image and source code from a git repo [2].
[1] https://access.redhat.com/containers/
[2] https://docs.openshift.com/container-platform/3.11/architect...
[+] [-] rdsubhas|7 years ago|reply
A lot of organizations don't yet have the tooling required to maintain distroless images (since that tooling extends all the way to developer machines).
Have you considered a hybrid option, where in GKE, you automatically keep this base image layer auto-updated when running on cos? It could give organizations that don't have distroless capability to still use vanilla docker tooling, but still get the same benefits of distroless at runtime (and potential of increased adoption it might drive to GKE)?
[+] [-] yanslookup|7 years ago|reply
[+] [-] philip1209|7 years ago|reply
Today, these images are already safer than other images
or
In the future, these images have an SLA for updates and patches in case of future problems
(or, both?)
[+] [-] dmoy|7 years ago|reply
[+] [-] Someone1234|7 years ago|reply
[+] [-] recipient|7 years ago|reply
[+] [-] IloveHN84|7 years ago|reply
[+] [-] tracker1|7 years ago|reply
[+] [-] rob-olmos|7 years ago|reply
That's interesting. Is there a reason for that?
IIRC the stock CentOS doesn't use HTTPS for its yum/rpm repos and I figured it wasn't necessary to use HTTPS since the package signature is verified.
[+] [-] TurningCanadian|7 years ago|reply
[+] [-] blaike|7 years ago|reply
[deleted]
[+] [-] coder543|7 years ago|reply
[+] [-] dlor|7 years ago|reply
[+] [-] paaaaaaaaaa|7 years ago|reply
[+] [-] LaGrange|7 years ago|reply
Of course, they could have bolstered the distro teams. And the fact that the repositories are within GCR, not Docker, is just convenience.
It brings you closer into Googles warm, technototalitarian embrace, is what I mean.
[+] [-] unknown|7 years ago|reply
[deleted]
[+] [-] nad7vx|7 years ago|reply
[+] [-] TheIronYuppie|7 years ago|reply
https://cloud.google.com/container-registry/docs/managed-bas...
So, to be clear, no matter what cloud you use, if you create a Dockerfile like the following:
This should work fine.Disclosure: I work at Microsoft on Azure.
[+] [-] fatherlinnux|7 years ago|reply
[+] [-] stefan_|7 years ago|reply
[+] [-] tmdk|7 years ago|reply
[+] [-] jiveturkey|7 years ago|reply
[+] [-] jacques_chester|7 years ago|reply
[+] [-] recipient|7 years ago|reply
[deleted]
[+] [-] LaGrange|7 years ago|reply
Also replace your shepherd dogs with wolves, wolves are bigger, faster, and will do it for free[*].
[+] [-] seccess|7 years ago|reply
If you are running in Google cloud, its their machines and they have power to do pretty much whatever they want anyway. How would this feature affect anything?
[+] [-] andybak|7 years ago|reply
I'm all for Google-bashing in areas that actually make some sense but this is nonsensical.