4 ms·

Seems like good alternative to CoreOS. Maintained by Google. More details [1][2] [1] https://cloud.google.com/compute/docs/containers/vm-image/ https://cloud.g

by nwrk 10y ago

Seems like good alternative to CoreOS. Maintained by Google. More details [1][2] [1] https://cloud.google.com/compute/docs/containers/vm-image/ https://cloud.google.com/compute/docs/containers/vm-image/ [2] https://cloud.google.com/compute/docs/containers/vm-image/release-notes https://cloud.google.com/compute/docs/containers/vm-image/re...

gtirloni 10y ago
First thought was CoreOS seem more mature and polished so why Container-VM? I can run CoreOS on my own servers. Can I run Container-VM on them if GCE doesn't cut it for me (or I want to standardize my hybrid cloud on a single OS)?
- JeanMertz 10y ago
  We booted a fresh GKE 1.4 cluster yesterday to migrate from our old 1.3 cluster. Looking at the machine, it looks like this is a fork(?) of CoreOS: $ grep core /etc/passwd core:x:5000:5000::/home/core:/bin/bash $ cat /etc/os-release BUILD_ID=8820.0.0 NAME="Container-VM Image" GOOGLE_CRASH_ID=Lakitu VERSION_ID=55 BUG_REPORT_URL=https://crbug.com/new PRETTY_NAME="Google Container-VM Image" VERSION=55 GOOGLE_METRICS_PRODUCT_ID=26 HOME_URL="https://cloud.google.com/compute/docs/containers/vm-image/" ID=gci $ toolbox Spawning container core-debian-jessie-backports on /var/lib/toolbox/core-debian-jessie-backports. Press ^] three times within 1s to kill container. If not a direct fork, it certainly uses the same base Chromium OS (which is no surprise) and uses some of the same toolsets that CoreOS uses.
- mikecb 10y ago
  You'd still use core on your own servers, but this has the benefit of tight integration with GCE, like verified boot, as well as the accounts and IAM system (seamless key management). But cloud-init configs work across both.
copperx 10y ago
Does this entail lock-in, given that these containers won't run anywhere else?
- kelseyhightower 10y ago
  Short answer is no. I'm a Google employee, so I'm biased. The Container-VM is just a Linux distro optimized for the Google Cloud Platform (GCP). As a former CoreOS employee, I can tell you first hand that a lot of effort goes into shipping and maintaining CoreOS Linux so it works well across every cloud provider and bare-metal target. This is not a goal of the Container-VM. The Container-VM also reduces the bootstrapping overhead required to run containers on GCP by including Docker, Kubernetes, and any patches required to run container workloads well, and securely, on GCP. Why not use distro X? While the majority of Linux distros do a great job of reviewing and accepting patches, there is a ton of value in producing a custom Linux distro and controlling the release cycle. A custom Linux distro gives the GCP team the ability to: * Enable kernel features, by default, that support Docker, Kubernetes and other GCP offerings; even if those kernel features offer little value on other platforms. This ability also extends to other tools and utilities commonly found on a Linux distribution. * Provide a better security and support story. When critical patches are required, Google has full control over when, and how, we roll them out. This is not to say other Linux distros are doing a poor job, it's to say Google should be in position to support GCP customers at this level. The Container-VM simply provides GCP customers another option with deeper support from Google. So how does this not result in lock-in? Here are a few reasons: * The Container-VM is built using common open source technologies such as the Linux kernel, Docker, and Kubernetes, with minor patches for stability and performance. These patches are usually cherrypicked from upstream or being proposed for acceptance. * Just about every Linux distro must be customized for each cloud provider. For example, on AWS you'll want to optimize for Xen and ship the AWS SDK. On GCP your target will be KVM and the Google Cloud SDK. Virtual machine (VM) images have never been portable, which is one reason so many people are pushing for containers to deliver workload portability across providers. The Container-VM is all about running containers, the same containers you'd run on any platform, we're just aiming to be the best platform to do that on.
  - 10y ago

by nwrk 10y ago

gtirloni 10y ago

First thought was CoreOS seem more mature and polished so why Container-VM? I can run CoreOS on my own servers. Can I run Container-VM on them if GCE doesn't cut it for me (or I want to standardize my hybrid cloud on a single OS)?

JeanMertz 10y ago
We booted a fresh GKE 1.4 cluster yesterday to migrate from our old 1.3 cluster. Looking at the machine, it looks like this is a fork(?) of CoreOS: $ grep core /etc/passwd core:x:5000:5000::/home/core:/bin/bash $ cat /etc/os-release BUILD_ID=8820.0.0 NAME="Container-VM Image" GOOGLE_CRASH_ID=Lakitu VERSION_ID=55 BUG_REPORT_URL=https://crbug.com/new PRETTY_NAME="Google Container-VM Image" VERSION=55 GOOGLE_METRICS_PRODUCT_ID=26 HOME_URL="https://cloud.google.com/compute/docs/containers/vm-image/" ID=gci $ toolbox Spawning container core-debian-jessie-backports on /var/lib/toolbox/core-debian-jessie-backports. Press ^] three times within 1s to kill container. If not a direct fork, it certainly uses the same base Chromium OS (which is no surprise) and uses some of the same toolsets that CoreOS uses.
mikecb 10y ago
You'd still use core on your own servers, but this has the benefit of tight integration with GCE, like verified boot, as well as the accounts and IAM system (seamless key management). But cloud-init configs work across both.

copperx 10y ago

Does this entail lock-in, given that these containers won't run anywhere else?

kelseyhightower 10y ago
Short answer is no. I'm a Google employee, so I'm biased. The Container-VM is just a Linux distro optimized for the Google Cloud Platform (GCP). As a former CoreOS employee, I can tell you first hand that a lot of effort goes into shipping and maintaining CoreOS Linux so it works well across every cloud provider and bare-metal target. This is not a goal of the Container-VM. The Container-VM also reduces the bootstrapping overhead required to run containers on GCP by including Docker, Kubernetes, and any patches required to run container workloads well, and securely, on GCP. Why not use distro X? While the majority of Linux distros do a great job of reviewing and accepting patches, there is a ton of value in producing a custom Linux distro and controlling the release cycle. A custom Linux distro gives the GCP team the ability to: * Enable kernel features, by default, that support Docker, Kubernetes and other GCP offerings; even if those kernel features offer little value on other platforms. This ability also extends to other tools and utilities commonly found on a Linux distribution. * Provide a better security and support story. When critical patches are required, Google has full control over when, and how, we roll them out. This is not to say other Linux distros are doing a poor job, it's to say Google should be in position to support GCP customers at this level. The Container-VM simply provides GCP customers another option with deeper support from Google. So how does this not result in lock-in? Here are a few reasons: * The Container-VM is built using common open source technologies such as the Linux kernel, Docker, and Kubernetes, with minor patches for stability and performance. These patches are usually cherrypicked from upstream or being proposed for acceptance. * Just about every Linux distro must be customized for each cloud provider. For example, on AWS you'll want to optimize for Xen and ship the AWS SDK. On GCP your target will be KVM and the Google Cloud SDK. Virtual machine (VM) images have never been portable, which is one reason so many people are pushing for containers to deliver workload portability across providers. The Container-VM is all about running containers, the same containers you'd run on any platform, we're just aiming to be the best platform to do that on.
- 10y ago