Containers on the Google Cloud Platform(developers.google.com) |
Containers on the Google Cloud Platform(developers.google.com) |
edit: here's the direct link to pdf https://speakerd.s3.amazonaws.com/presentations/83bc6d40c41a...
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 :)
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++.
Watch this space.
GCE use diff format than AWS BE, it would be good to have standard so more love for DevOps. :)
LMCTFY is just a piece of what Docker does. They can be made to work together, even.
gce is one of the providers listed in the official docs, and I assume the CoreOS guys have had some interaction with gce people.
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 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.
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.
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...).
And we have to use the indefinite article, "a desktop", never … your desktop.