kelseyhightower

Disclosure: CoreOS employee; Kubernetes contributor.

After reading the title I was a bit tempted to call BS since I think Kubernetes should have the rights to "The first Datacenter OS" tagline[1]. However, after reading up on the project details at https://mesosphere.com/learn I can see how Mesosphere came to the conclusion of being a DCOS, if not necessarily the first. Mesosphere goes a bit further than Kubernetes and offers a solution to the storage problem and attempts to address other "userland" concerns by shipping Apache Spark, Cassandra, Kafka, and Hadoop. So maybe it would be more accurate to call this a datacenter distro on top of the Kubernetes kernel?

Regardless, I think the concept of a datacenter OS will be the key to commoditizing IaaS providers and leveling the playing field in terms of features and usability for those who have not given up on the dream of running a "private" cloud.

Why will the DCOS work where others have failed?

Current solutions aimed at taming the datacenter operate at the machine/VM level, which exposes the OS for each machine, and completely punts on the application. Guess who gets to stitch it all back together? A DCOS is designed to manage applications directly, commonly via application containers, which means we can treat the OS running on the underlying machines like firmware and limit our interactions to basic updates and minimal configuration -- think CoreOS.

What about PaaS?

That's a topic worthy of a lengthy discussion, but I think it boils down to the lack of control found in most PaaS platforms[2]. In order for a PaaS offering to be successful it must make opinionated decisions about how to deploy and run applications; a bit too inflexible for most people. On the other hand, a DCOS seems to hit the sweet spot between IaaS and PaaS.

[1] I'm sure you can make an argument for Joyent's SmartDataCenter (https://www.joyent.com/private-cloud) as well. [2] Deis (http://deis.io/overview) attempts to address this issue.

Again not to take anything away from consul-template or pyconfd, but confd supports "real-time" updates from both consul and etcd, the watch support was added about 2 weeks ago on the master branch.

confd also has dry run support: https://github.com/kelseyhightower/confd/blob/master/docs/no... It was apart of the initial release of confd.

These distributed K/V stores are designed to offer a minimal feature set, and the watch support is a perfect way to deliver events to clients. While HTTP call backs would be nice, I think you have to draw the line somewhere. Since these types of systems, consul or etcd, sit at a critical point in the infrastructure lets keep them lean and focused. But that's just my opinion.

confd author here.

I'm glad to see this idea validated, and I think consul-template looks pretty awesome and well integrated with consul. consul-template takes advantage of consul specific features such as the consul services API and datacenters, which is really great for consul users. These are things I did not want to add and maintain in confd, since I'm supporting consul, etcd, and environment variables as backends I felt those would be one off features, which really belong in a consul focused tool like this.

Some will ask why did Hashicorp not just contribute to confd? Well they did. They added initial support for consul to confd almost a year ago and have been very helpful with my questions around consul ever since. The contributions go both ways too. I've been a contributor to Hashicorp's Packer project -- I added Ansible and GCE support and various bug fixes.

This is just how opensource works. I'm actually pretty happy to see one of my projects get so much attention and now inspire another project. That's the whole point right?

Not to take anything away from consul-template, but that has been a feature of confd for a while:

https://github.com/kelseyhightower/confd/blob/master/docs/te...

Are you saying that compressed data should not be encrypted? We are trying to limit the amount of data we have to store in the backend K/V store. Can you provide links so I can read up on this. Thanks.

Hopefully we corrected the docs and the comments here help, but we don't encrypt before we compress. We compress before we encrypt.

Yeah, I'm open working with anyone on other client libs. Ideally we can track them in an official doc in the repo. To help others get started I'll document the data we store in etcd/consul in more detail.

Ideally clients only need to store values with the following encoding base64(gpg(gzip(data))) and do the reverse when retrieving data. As long as the public/private keys are available, everything should work.

Sorry, if I said that in the video. What we do is base64(gpg(gzip(data)))

We gzip the data first, then encrypt it, finally base64 encode it.

Many people do just that. Here is a post I wrote outlining the details, including how to handle cases where you want to disable CGO, but still need access to an SSL cert bundle. https://medium.com/@kelseyhightower/optimizing-docker-images...

I personally think they will pull this one off, mainly because CoreOS will be providing support to the DO team and help however possible to make sure DO is added to the list of supported cloud vendors.

For the next post I'm thinking about using containers and cloud-config to set up all the Kubernetes components. That would make it easy to do everything the "CoreOS" way.

I've found starting docker containers using something like systemd works really well. Basically you do something like this:

  # systemd unit file
  Description=My Service
  After=docker.service
  Requires=docker.service

  [Service]
  ExecStart=/usr/bin/docker run username/app

Notice I'm not using the '-d' flag in the docker run command. That forces all output to stdout/stderr, which will be routed to the systemd journal. Sadly this only works for apps that can log to the console instead of files.

More examples here:

https://coreos.com/docs/launching-containers/launching/getti...

libcontainer - http://blog.docker.io/2014/03/docker-0-9-introducing-executi...

Thank you!

I'm really glad to see the Go team sticking with the short release cycles. Very easy to follow what's changing and what to expect in the next release.