Containers on the Google Cloud Platform(developers.google.com)
developers.google.com
Containers on the Google Cloud Platform
https://developers.google.com/compute/docs/containers
9 comments
My slides from the talk at GlueCon: https://speakerdeck.com/jbeda/containers-at-scale
Could you upload it somewhere else please? Links don't work on speakerdeck and it's unusable on mobile. I'll never understand why people keep using speakerdeck as it has very poor usability. Your presentation looks great though!
edit: here's the direct link to pdf https://speakerd.s3.amazonaws.com/presentations/83bc6d40c41a...
edit: here's the direct link to pdf https://speakerd.s3.amazonaws.com/presentations/83bc6d40c41a...
Here it is hosted on GCS: http://slides.eightypercent.net/GlueCon%202014%20-%20Contain...
Completely superfluous comment, but those are one of the nicest slides I've seen. I really dig the extra-wide format.
Thanks -- the template was done by the Google Cloud Platform marketing guys.
Working with the extra wide format can be a little tricky. Just having text ends up looking really stark so I find myself adding a lot more supporting graphics and such.
Funny thing -- I wanted an "If it fits, I sits" picture for the LMCTFY slide but clearing copyright on any sort of meme image is next to impossible. So even though there are millions of cat pictures on the internet I had to go to a stock photo site and pay for one :)
Working with the extra wide format can be a little tricky. Just having text ends up looking really stark so I find myself adding a lot more supporting graphics and such.
Funny thing -- I wanted an "If it fits, I sits" picture for the LMCTFY slide but clearing copyright on any sort of meme image is next to impossible. So even though there are millions of cat pictures on the internet I had to go to a stock photo site and pay for one :)
Google deserves a shout-out for embracing Docker in a really constructive way. In addition to building cool tools on top of it (like the one linked here), they are also contributing real engineering effort into the upstream Docker project itself. For example Victor and Rohit from the Google LMCTFY team are now active maintainers of libcontainer (https://github.com/dotcloud/docker/blob/master/pkg/libcontai...)
I'm looking forward to digging through the agent, but I'm a bit surprised that it's in Python rather than Go, given the minimal nature of the "host" OS.
If any Google folks or other knowledgable people are around, I'd be curious to know what went in to that choice.
If any Google folks or other knowledgable people are around, I'd be curious to know what went in to that choice.
(primary author of that python here)
We have a number of things we're looking at for agents. One is derived from internal code, but has to clear some legal hurdles to OSS. One is a new codebase, but not quite up to the current spec. We're also keeping an eye on other OSS projects. We don't really want to reinvent the wheel here, but we clearly have our own ideas about how to run jobs :)
Doing it in python was a way to quickly demonstrate the ideas and make something that works, albeit minimally. I expect that we will want to do more interesting things that will really ask for a "proper" (sorry python) language like Go or C++.
Watch this space.
We have a number of things we're looking at for agents. One is derived from internal code, but has to clear some legal hurdles to OSS. One is a new codebase, but not quite up to the current spec. We're also keeping an eye on other OSS projects. We don't really want to reinvent the wheel here, but we clearly have our own ideas about how to run jobs :)
Doing it in python was a way to quickly demonstrate the ideas and make something that works, albeit minimally. I expect that we will want to do more interesting things that will really ask for a "proper" (sorry python) language like Go or C++.
Watch this space.
This could be an interesting option as well, https://github.com/virgo-agent-toolkit. It has a very small footprint, built with SIGAR for reporting metrics and a lightweight embedded lua interpreter for performing the business logic.
Thanks, I'll peek at it, too.
Python advocate here. Apology accepted, but no apology necessary. Sorry Python… :)
Fascinating, however I'm quite curious about whether they took a serious look at utilizing CoreOS over Debian 7 (and if so, why Debian 7 was chosen instead).
CoreOS is already working great on GCE http://coreos.com/docs/running-coreos/cloud-providers/google...
We also wanted to offer a way for regular Debian users to get easily started with Docker on GCE.
How about Fedora (etc.)?
Yes, we'd love to support those as well.
The agent https://github.com/GoogleCloudPlatform/container-agent and manifest format https://developers.google.com/compute/docs/containers#contai... are not distro specific, and the glue to start them on boot could be easily adapted to other distro.
The agent https://github.com/GoogleCloudPlatform/container-agent and manifest format https://developers.google.com/compute/docs/containers#contai... are not distro specific, and the glue to start them on boot could be easily adapted to other distro.
Fedora isn't really meant to be a server distro -- it's a bleeding-edge distro so it has rapid releases, a short life-cycle, and lots of new code.
As the Fedora docs say, it's "often running in uncharted innovative territory," which is great if you want the latest stuff on your desktop, but it's not what you really want in a server distro. Red Hat Enterprise Linux (RHEL) is derived from Fedora every few years so it's battle tested and stable, in the same way Debian is.
For servers in the Red Hat lineage, use RHEL or CentOS, esp now that Red Hat has officially joined forces with CentOS (http://www.redhat.com/about/news/press-archive/2014/1/red-ha...).
As the Fedora docs say, it's "often running in uncharted innovative territory," which is great if you want the latest stuff on your desktop, but it's not what you really want in a server distro. Red Hat Enterprise Linux (RHEL) is derived from Fedora every few years so it's battle tested and stable, in the same way Debian is.
For servers in the Red Hat lineage, use RHEL or CentOS, esp now that Red Hat has officially joined forces with CentOS (http://www.redhat.com/about/news/press-archive/2014/1/red-ha...).
Yep - that's why I threw the etc. in there.
And we have to use the indefinite article, "a desktop", never … your desktop.
And we have to use the indefinite article, "a desktop", never … your desktop.
My experience with containers on CentOS was not nearly as enjoyable as my experience with containers on Debian/Ubuntu. Although it was[more than]likely user–error, unless someone else can relate. Not an answer, I know… just venting.
We're certainly still evaluating alternatives, here.
Debian is much closer to what we use internally, and we wanted to start with sharing some of the internal ways we work.
What about wrt other container implementations, like your own LMCTFY?
LMCTFY is a "container" implementation by Google's traditional definition, which is very focused on isolation and less so on namespacing, filesystem, and packaging. We've added namespace support recently, but we do not have the things that make Docker really interesting to most people - the build process, the packaging, the runtime.
LMCTFY is just a piece of what Docker does. They can be made to work together, even.
LMCTFY is just a piece of what Docker does. They can be made to work together, even.
As someone unfamiliar with the differences between those OSes, could you elaborate on why you would expect them to compare CoreOS in particular and why I or someone else might also want to consider it for similar purposes?
CoreOS is essentially built for running containers, which is how Google have described the Debian 7 image deployed in this preview. CoreOS has a number of features that are really geared towards running it as a bare metal OS (won't elaborate on that here, their docs do a good job of explaining), which is not the use case here so can't really blame Google for going with something more familiar (to them).
https://coreos.com/docs/running-coreos/cloud-providers/googl...
gce is one of the providers listed in the official docs, and I assume the CoreOS guys have had some interaction with gce people.
gce is one of the providers listed in the official docs, and I assume the CoreOS guys have had some interaction with gce people.
CoreOS is a linux distro specifically created to support containerization. It has great Docker support and a built-in distributed key/value store and a container manager for orchestration and service discovery.
> It has great Docker support and a built-in distributed key/value store and a container manager for orchestration and service discovery.
Is there more to this? Most OSes have great docker support (Ubuntu et al) and etcd (the kv/orchestration tool you speak of) is open source and available to most distros as well.
Is there more to this? Most OSes have great docker support (Ubuntu et al) and etcd (the kv/orchestration tool you speak of) is open source and available to most distros as well.
CoreOS' most noteable feature is the fact that it is incredibly light weight and fosters a modular enviornment that (IMO) is less likely to be plagued by dependency hell related issues that you might tolerate from other distros' package management system (Not talking about you Portage, your still coooo).
CoreOS does this by utilizing Linux containers via Docker to easy–bake applications through individual containers of which are explictly isolated from eachother, aiding in the problem of static/dynamic shared libraries causing dependency issues.
Now you can of course utilize all of this on a distro like Debian, and even borrow the best of CoreOS like etcd (for one example).
TL;DR; CoreOS features awesome concepts and services like etcd, and fleet, and more that doesn't mean you cannot do the same with Debian, but it won't be native, and it would not be very light weight out-of-the-box compared to CoreOS.
CoreOS does this by utilizing Linux containers via Docker to easy–bake applications through individual containers of which are explictly isolated from eachother, aiding in the problem of static/dynamic shared libraries causing dependency issues.
Now you can of course utilize all of this on a distro like Debian, and even borrow the best of CoreOS like etcd (for one example).
TL;DR; CoreOS features awesome concepts and services like etcd, and fleet, and more that doesn't mean you cannot do the same with Debian, but it won't be native, and it would not be very light weight out-of-the-box compared to CoreOS.
[deleted]
Is this a way to run docker/container in a GCE/VM, or does the docker/container run on top of the base OS, so that your application can run at bare metal speed, without the overhead of of a VM.
This runs in a VM. We're not selling bare-metal (and even if we wanted to, Docker doesn't really have a co-tenancy model yet, so you'd have to buy full machines...)
Thanks for the reply. I wasn't familiar with docker, and thought that it was similar to zones in solaris/smartos. and this offer from GCP was similar to the SmartMachine offer from Joyent.
Now major players start to adopt Docker, I wonder whether they should standardized manifest format?
GCE use diff format than AWS BE, it would be good to have standard so more love for DevOps. :)
GCE use diff format than AWS BE, it would be good to have standard so more love for DevOps. :)
We're in favor of standardizing the ideas, here.
There's a lot of discussion about that on #docker-dev. I think we (Docker maintainers) might pick a default format + plugin system to swap in your own. Of course the plugin would itself be a container :)
Interesting approach. I'm very much looking forward to hashing out the details.
Impressive of Docker to gain Google's attention. I think this is a win-win for everyone involved.
Will this get amazon and others to rush to support container centric cloud infrastructure?
http://docs.aws.amazon.com/elasticbeanstalk/latest/dg/create... This seems pretty comparable, both are essentially deploying a manifest to a machine and exposing things like ports, volumes, etc.
Although at the moment the EBS setup will allow you to run just one container per instance, whereas this lets you run several.
[deleted]