Hacker News Reader

Comment by dlor | Hacker News Reader

I'm Tech Lead/maintainer for these images. Happy to answer any questions!

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?

Genuinely curious here -- what alternatives are there to this service that are guaranteed beyond 18-24 months?

Why is 18.04 not an available-at-launch image choice?

This was a mistake - we have it ready and just forgot to publish it. I'll get it out ASAP!

I think Ubuntu 16.04 is used internally a lot with Google, as they have hardened it themselves. I believe GKE On-Prem will also be based on Ubuntu 16.04 for this reason.

Not that much anymore. https://www.zdnet.com/article/google-moves-to-debian-for-in-...

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.

* https://buildpacks.io/

I'm a pretty big fan of the new build pack spec. I haven't gotten a chance to really try it out in depth yet, but the layer-aware caching is a pretty elegant way to make fast builds possible.

There is a fair amount of ongoing contact between Google teams (like dlor's) and the folks working on/around Cloud Native Buildpacks at Pivotal and Heroku (including me). We are continuing to compare notes.

I think these images will fold up neatly into CNBs without much fuss, if they are packaged as stacks.

Great, I can see lots of potential.

What's the difference between this and say:

FROM ubuntu:16.04

Won't that pull the latest official Ubuntu image with that tag?

There are a few reasons you might want to use our version of these images:

- If you're running on GCP, pulling images from GCR will likely be much faster than Dockerhub given network locality.

- Content Trust. DockerHub images are maintained by a large team of upstream maintainers and volunteers. These images are fully managed by Google, and you can examine and audit the full supply chain from source to built image.

I think you're listing wrong reasons to prefer Google's images, while there are some right reasons.

* Faster fetch - not a big deal IMO (edit: you could just mirror, you don't have to do the patching)

* Content trust - but trust to e.g. Canonical's Ubuntu is required anyway, right? And then, you have to trust Google.

Examples of reasons I would take as good:

* Does Google routinely do audit of original distro images, so that it's less of a risk to use community distro like Debian? It could.

* Is Google "manning" the work on the actual distributed software, accepting users' bugreports and then working with upstream to fix it? It could.

Even-more-downstream-distro is actually not a bad idea.

If you really wanted to contribute to the ecosystem you could have offered another vulnerability list to work against, work with upstream to deal with issues, and mirror the existing bits on GCR for your customers.

--- edit add disclosure statement

Disclosure: I work at Microsoft on Azure, previously at Docker on the core engine.

There's nothing about this that excludes that work as well.

But, there's nothing to say that the upstream distro would accept the changes. Google has more stringent requirements that a general distro, and you're choosing to follow those requirements (at the benefit of Google's automated scanning). It's totally your choice.

Disclosure: I work at Microsoft on Azure.

> But, there's nothing to say that the upstream distro would accept the changes

If upstream didn't accept it, then it shouldn't be masquerading as what upstream is... which is what changing `FROM $image` to point to Google's image does.

> and you're choosing to follow those requirements

From what I gathered from the article, Google is changing the meaning of `FROM $image` to mean Google's build of the image. There is no choice in the matter outside of using Google's services.

Disclosure (and sorry for not mentioning in the original comment, I've updated): I work at Microsoft on Azure, and formerly at Docker on the core engine.

Nothing is changing with FROM - not sure what gave you that impression. We're simply offering some new base images people can choose to use if they want to.

These also happen to be the ones that have been in use by some of our "more serverless" offerings, where users don't get to supply a Dockerfile, for some time now.

> As long as the FROM field in your Dockerfile points to `$distro:latest` from Cloud Marketplace

I read this perhaps the wrong way, in which case I apologize on that front.

The upstream images are also validated from source to built image, and constantly scanned for vulnerabilities.

At best such a comment is completely ignorant of the existing ecosystem.

Disclosure: I work at Microsoft on Azure, previously at Docker on the core engine.

Is this similar to what Red Hat does with OpenShift?

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...

I think it's closer to saying that Google will stand behind Centos and Ubuntu images without you needing to sign contracts with Red Hat or Canonical.

I work for Pivotal. We have a contract with Canonical that leads us to base all our work on Ubuntu, including derived base images, analogous to how RHEL is bundled into OpenShift.

If you're buying from us, this news is neutral. If you're buying from Red Hat, this news is neutral. If you're buying from neither, it's good news.

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.

You can put the image tag URL into your browser's address bar and it'll redirect to the Cloud Console page listing tags for that image, e.g.:https://marketplace.gcr.io/google/ubuntu16_04

From there you can go up a level to see all images in the /google/ namespace: https://console.cloud.google.com/gcr/images/cloud-marketplac...

I'm trying to understand the value proposition here. Is it:

Today, these images are already safer than other images

In the future, these images have an SLA for updates and patches in case of future problems

(or, both?)

Just the fact that google is gatekeeping the images instead of dockerhub makes them a better security proposition.

It's 2018 and dockerhub _still_ doesn't have 2FA. All it takes is one cred-stuffed account belonging to a debian maintainer to take you down if you don't pin your images.

What's the difference between these and say launcher.gcr.io/google/ubuntu16_04? (aside from not being pinned)

It's the same underlying image, just hosted somewhere else :)

Oh, ok good to know :)

Thanks!

Do you think this strategy could be successful/have a future for non-container based Operating Systems?

For AWS:

https://docs.aws.amazon.com/systems-manager/latest/userguide...

4.4.7 (unable to deliver this

What about windows containers?

Alpine?

Reply on news.ycombinator.com