Kubernetes is going to support rkt
wired.com
wired.com
However, I don't really feel comfortable with Docker security and I will probably switch to rkt - more focus on security and better approach to containers imo. CoreOS is incredibly good product, these people see the future. Full disclosure: I'm very happy user of CoreOS products.
I also don't much care for etcd, because IMO Zookeeper's rep for complexity is hugely overblown and most folks end up re-implementing Zookeeper poorly in etcd, but that's a side thing.
All that said, I agree with you that Rocket is a much, much better idea and design, and that despite my misgivings about their corporate goals CoreOS is a way more serious project from a security standpoint than Docker. I'm excited to see this, if only because I think Rocket will pick up some dV from this.
I really like Ansible and I believed that Ansible could help with Docker deployments (http://www.ansible.com/docker), but at the moment I think that using Dockerfiles is faster and simpler. I'm still using Ansible for Vagrant provisioning, but don't need it for setting up production/ci anymore. Sure, Ansible/Chef/Puppet will be probably on the market and used by some big players, but I'd be very surprised if we won't see big shift into containers for most of the technology companies. Being faster, more productive and cost effectiveness (related: https://www.youtube.com/watch?v=xK0njkATf84) are good enough arguments imo.
While I'm a huge fan of Docker I will maintain that CoreOS is not ready for production in most capacities and recommend against using it in its current form.
CephFS had a similar-ish problem, where if you happened to ever own less than 3 nodes (almost always because of the above), it would have a real problem self-healing and start to get confused and re-elect bad nodes to quorum leadership, possibly clobbering all your registry data. We contributed a patch back to Deis to use S3 as a registry persistence layer because, well, having a volatile registry sucked. We were about to develop a control layer for quorum services to live on separate of the application services we were developing, and using a proxy in the quorum layer to communicate stuff like etcd. I would highly recommend this approach if you end up with any services that require a quorum.
I would prefer to avoid many disk operations in the first place. Not sure, if it's applies to your problem, but have you thought about using something like Sentry (https://getsentry.com/ || https://github.com/getsentry/sentry)? Maybe there is some other tool that could help you here, I'm often impressed by the Open Source community and the vast number of different packages for (almost ;)) every technological problem.
Often the easiest attack vector is/are security vulnerabilities in applications exposed to the public network. Containers are great here, because when application is compromised, just 1 particular container is dead (and probably other containers running that app). I can just run docker kill app && docker rm app and the rest of my containers are (probably) ok. The problem is that attacker can gain access to data in etcd, since it's not encrypted by default and has no per-user permission (but you can use HTTPS in etcd cluster, which is good), however as of now you can use something like crypt: https://github.com/xordataexchange/crypt to use gpg in etcd (with natural API).
Docker gives you root for everything in the container, which may not be the best option. Also, only lately Docker have the option to verify downloaded images. rkt already has this feature, and it's just 0.5.5. (see also: https://github.com/coreos/etcd/blob/master/Documentation/sec...). Docker is great, don't get me wrong, I think it's a very good software and I'm glad I can use it. CoreOS team has just a better vision and priorities, IMO.
I'm considering a blog post about CoreOS/Docker/rkt and similar tools, not sure if there's interest?
Docker wants to be known as a platform providing container management tools and it needs to do this quickly because Mesosphere and Kubernetes provide this type of functionality at a more mature level, albeit using somewhat different philosophies. The container format part of Docker is ultimately replaceable.
Google (Ventures) backing Tectonic is significant because Tectonic will provide a commercial enterprise-ready distribution of Kubernetes supporting Rocket. Rocket doesn't need to reach feature-parity with Docker to be a notable replacement because Docker already does too much. All Rocket needs to do is provide the much needed enterprise features that Docker is lacking and integrate well with Mesosphere or Kubernetes. If this happens before Swarm and Machine mature, we could be wondering 6 months down the road what the hype around Docker was all about.
If Tectonic succeeds in the enterprise marketplace then Google will have stealthily marginalised Docker using community efforts through rkt and kubernetes and not had to fight them directly.
I love Rocket and Docker, but I don't love misleading sensationalism in tech reporting. Maybe my mistake is thinking of wired as tech reporting?
"Google also offers cloud computing services a la Amazon, and it was the first big-name cloud company to embrace Docker. Since then, Amazon, Microsoft, and others have followed, responding to Docker’s enormous popularity among Silicon Valley developers. But now, Google is backing Rocket as well, rolling the technology into its Kubernetes cloud computing software. Google calls this “an important milestone for the Kubernetes project.”
My reco is update the title.
Doesn't Rocket also use cgroups?
Actually no. Google Ventures runs quite autonomously from the product teams; I speak to them from time-to-time but they make their own decisions and don't influence ours.
We supported the rkt/appc PR because (1) we try hard to be an open community and to not play favorites, and (2) because we think the project has good promise as an open standard and as a lightweight modular runtime.
Please note that we are trying hard not to play favorites. Docker support will continue indefinitely and we will continue to make investments in the Docker community.
Already been eyeing kubernetes, reading this just makes me want to use it even more.
Correct. We already support Docker and plan to indefinitely. This is us extending support to rkt/appc also.
We've updated the title. We can update it again if there's a better one.
(An analogy: appc=JVM, rkt=OpenJDK, CoreOS=Sun)
I think your point is fair: all technology should be reviewed strictly on its merits. We certainly don't have a magic formula that gets it right 100% of the time. I can however say we are quite committed to this area and this project in particular.
Here are the things I think about most days:
In the case of Kubernetes, we are doing is a little different to anything we have done before. We have a commercial offering (Google Container Engine) based on this project that we ultimately hope the world to consider as a great way to run containers for money (yes, we hope to create a business around this). The nice thing is we are a service provider so we just need to convince someone to use our compute services for us to benefit from an open source project we sponsor. We aren't really hiding our intentions here; we do containers well inside Google and have some whizz-bang container hosting infrastructure and services. The problem is that people are not likely to use it unless there is a 100% open, fully compatible alternative available for off-Google use. By way of background I was the product lead for Google Compute Engine (our infrastructure-as-a-service product) for several years. The product is going really well now, but I learned the hard way that big customers like choices and no-one likes to be locked in. This isn't just us being Googley (though I have a personal predilection to openness); this is a simple fact of the marketplace today. We could not convince someone to bet on a disruptive technology if an open and credible alternative does not exist.
The second thing is that we see tremendous power in the open source community that we want to tap into, both for our cloud product line, and for our own internal use (it is no secret we use a lot of OSS internally). Kubernetes has achieved an almost ridiculous velocity (check out our PR acceptance rates) because the community is supporting it. It is a better product because we benefit not only from having a bunch of Google engineers working on it, but because we also get engineers from Red Hat, CoreOS and others who bring different perspective and capabilities. We aren't enterprise guys for example, but the Red Hat folks are -- the combined team is way better than the sum of the parts. Our service (Google Container Engine) is stronger for it, and in the limit we expect to use Kubernetes to run a lot of our internal services too.
Cheers, -- craig