Introducing Google Container-VM Image | Hacker News Reader

Introducing Google Container-VM Image

cloudplatform.googleblog.com

88 pointsingve31 comments

Seems like good alternative to CoreOS. Maintained by Google. More details [1][2]

[1] https://cloud.google.com/compute/docs/containers/vm-image/

[2] https://cloud.google.com/compute/docs/containers/vm-image/re...

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

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.

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.

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

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.

I'm also at Google, so I'm biased.

We're working on releasing the source code for this as well - nothing proprietary about it. Kelsey's hit the nail on the head - it's just an OS that's optimized to run on Google Cloud.

https://cloud.google.com/compute/docs/containers/vm-image/fa...

I've been using this in CI to build and test my Dockerized app. On GCE billing is by the minute (after a 10 minute minimum) so it hasn't been too expensive.

Do you have any trick for spinning up/down CI VMs on-demand?

I use gitlab multi-runners. It's a privileged mode docker container that spins up other containers on the host machine to run its builds. I have them sitting in an autoscaling group where if it hits 40% cpu usage another server running gitlab multi-runner starts and automatically registers to do more builds.

You can do this with any ci system though, not specific to gitlab.

I use gcloud compute instances create ... in a shell script.

Disclosure: I work at Google.

You may also want to look at using Preemptible VMs [1] which are up to 50% cheaper as well.

[1] https://cloud.google.com/preemptible-vms/

Anyway to download the image for use in a private cloud?

No, it's specifically built for Google Cloud and not tested anywhere else, so they don't distribute it.

I was wondering the same exact thing

I imagine it would be trivial: start an image, then capture the filesystem image, then patch up anything where the image depended on Google Cloud.

Just to be clear, the "would be trivial" part was a joke, right?

Since you can SSH into the running image you can just use rsync to clone the entire disk. Is there something you know that is being missed here ?

I'm thinking they're expecting it to be heavily reliant on Google infrastructure through a variety of API calls.

Every time I've cloned a Linux image from one infrastructure provider to another, I've always had to identify 5-10 locations where it was customized for the infrastructure. Typically finding those is a matter of reading log files and knowing how linux works. To me, that's "trivial" because it's something I've been doing for decades. It may not be so for other people.

You can download an image easily [0], but I don't know how easy it would be to run it anywhere else.

[0] https://cloud.google.com/compute/docs/images/export-image

Disclosure: I work at Google.

Both downloading the image, and the source code, will be available soon(-ish)!

https://cloud.google.com/compute/docs/containers/vm-image/fa...

As others have said, it's still pretty likely you'll need to do some configuration changes, as this is fairly customized to run on Google Cloud (e.g. there's no package manager, file system is read-only by default, etc).

How is actually Google compared to other cloud hosting providers in pricing? Is there any independent site that compares cloud hosting providers?

There are many comparisons, but you should find them yourself so you know where they came from.

IMO, big benefits in billing per minute rather than hour, discounts applied automatically when running longer instances, up to 30% off for a whole month, rather than having to reserve it up front for discount, and instances that can be preempted vs the spot market(can save something like 70% off normal price). There's also the ability to customize proc and memory to your workload, so you're not paying for one or the other if you don't need it. They also recently added a feature that tells you if your vms are oversized for the work they've been doing, and what size would be most cost-efficient.

I've been using it for a dozen or so personal projects, and never paid more than $30 or so per month. That's probably about 50% less than what I was using at AWS, and I would never have had the ability to use tools like bigquery (redshift on AWS), hadoop, etc, just because I wouldn't want to spin up a cluster for hours. All the logs from all those projects are costing a few cents per month in bigquery.

Depends on your usage.

If you just need a few servers for your side projects. You should use one of the cheap providers: Digital Ocean/Linode/OVH/Hertzner. They're just a lot cheaper.

If you need all the fancy features, typically because you're running a company (VPC, SAN drives, S3/cloud storage, load balancers...). You should use GCE instead of AWS. I'd say it's 20-50% cheaper in average.

The cheapest GCE server is $4 something a month. How much us that $5 digital ocean server saving you?

Yes the DO has better specs but for most projects you won't notice (for example local sad)

GCE/AWS: $n for the server + $2 for the hard disk + $y for the bandwidth + some other surprises we'll only find out later.

Digital Ocean really is $5, fixed, all inclusive.

That's the difference ;)

I hosted a WordPress site on GCE for under $5 all in. Then when I wanted to move to hosted SQL.... Took 3 clicks.

[deletion because HN doesn't have strikethroughs for dramatic effect]

In which our complainant learns to read.

It says ChromiumOS, which amusingly, is the same base as CoreOS.

Thanks.

Reply on news.ycombinator.com