6 ms·

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

by dlor 8y ago

Operyl 8y ago
Why is 18.04 not an available-at-launch image choice?
- stingraycharles 8y ago
  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.
  - ssambros 8y ago
    Not that much anymore. https://www.zdnet.com/article/google-moves-to-debian-for-in-house-linux-desktop/ https://www.zdnet.com/article/google-moves-to-debian-for-in-...
- dlor 8y ago
  This was a mistake - we have it ready and just forgot to publish it. I'll get it out ASAP!
Someone1234 8y ago
Do you think this strategy could be successful/have a future for non-container based Operating Systems?
- scarface74 8y ago
  For AWS: https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-patch.html https://docs.aws.amazon.com/systems-manager/latest/userguide...
alwaysdoit 8y ago
What's the difference between this and say: FROM ubuntu:16.04 Won't that pull the latest official Ubuntu image with that tag?
- dlor 8y ago
  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.
  - andrey_utkin 8y ago
    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.
  - cpuguy83 8y ago
    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.
    - cpuguy83 8y ago
      Disclosure: I work at Microsoft on Azure, previously at Docker on the core engine.
  - cpuguy83 8y ago
philip1209 8y ago
I'm trying to understand the value proposition here. Is it: 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?)
- bsamuels 8y ago
  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.
dmoy 8y ago
What's the difference between these and say launcher.gcr.io/google/ubuntu16_04? (aside from not being pinned)
- dlor 8y ago
  It's the same underlying image, just hosted somewhere else :)
  - dmoy 8y ago
    Oh, ok good to know :) Thanks!
yanslookup 8y ago
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.
- ImJasonH 8y ago
  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 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-marketplace-containers/GLOBAL/google?gcrImageListsize=100 https://console.cloud.google.com/gcr/images/cloud-marketplac...
rdsubhas 8y ago
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)?
thibautg 8y ago
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/ https://access.redhat.com/containers/ [2] https://docs.openshift.com/container-platform/3.11/architecture/core_concepts/builds_and_image_streams.html#source-build https://docs.openshift.com/container-platform/3.11/architect...
- jacques_chester 8y ago
  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.
drewda 8y ago
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/ https://buildpacks.io/
- dlor 8y ago
  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.
- jacques_chester 8y ago
  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.
  - drewda 8y ago
    Great, I can see lots of potential.
tracker1 8y ago
Alpine?
IloveHN84 8y ago
What about windows containers?
JaimeThompson 8y ago
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?
- jmole 8y ago
  Genuinely curious here -- what alternatives are there to this service that are guaranteed beyond 18-24 months?
recipient 8y ago
4.4.7 (unable to deliver this

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

by dlor 8y ago

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

Operyl 8y ago

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

stingraycharles 8y ago
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.
- ssambros 8y ago
  Not that much anymore. https://www.zdnet.com/article/google-moves-to-debian-for-in-house-linux-desktop/ https://www.zdnet.com/article/google-moves-to-debian-for-in-...
dlor 8y ago
This was a mistake - we have it ready and just forgot to publish it. I'll get it out ASAP!

Someone1234 8y ago

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

scarface74 8y ago
For AWS: https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-patch.html https://docs.aws.amazon.com/systems-manager/latest/userguide...

alwaysdoit 8y ago

What's the difference between this and say: FROM ubuntu:16.04 Won't that pull the latest official Ubuntu image with that tag?

dlor 8y ago
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.
- andrey_utkin 8y ago
  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.
- cpuguy83 8y ago
  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.
  - cpuguy83 8y ago
    Disclosure: I work at Microsoft on Azure, previously at Docker on the core engine.
- cpuguy83 8y ago

philip1209 8y ago

I'm trying to understand the value proposition here. Is it: 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?)

bsamuels 8y ago
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.

dmoy 8y ago

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

dlor 8y ago
It's the same underlying image, just hosted somewhere else :)
- dmoy 8y ago
  Oh, ok good to know :) Thanks!

yanslookup 8y ago

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.

ImJasonH 8y ago
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 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-marketplace-containers/GLOBAL/google?gcrImageListsize=100 https://console.cloud.google.com/gcr/images/cloud-marketplac...

rdsubhas 8y ago

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)?

thibautg 8y ago

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/ https://access.redhat.com/containers/ [2] https://docs.openshift.com/container-platform/3.11/architecture/core_concepts/builds_and_image_streams.html#source-build https://docs.openshift.com/container-platform/3.11/architect...

jacques_chester 8y ago
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.

drewda 8y ago

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/ https://buildpacks.io/

dlor 8y ago
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.
jacques_chester 8y ago
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.
- drewda 8y ago
  Great, I can see lots of potential.

tracker1 8y ago

Alpine?

IloveHN84 8y ago

What about windows containers?

JaimeThompson 8y ago

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?

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

recipient 8y ago

4.4.7 (unable to deliver this