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!
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 :)
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.
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++.
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.
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).
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.
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.
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.
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).
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.
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.
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.
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 :)