
Announcing rkt v0.5, featuring pods, overlayfs, and more - TheHippo
https://coreos.com/blog/announcing-rkt-0.5/
======
krakensden
It's weird seeing all the careful description of a Pod, which is just an
explicit rollback of Docker's wishful thinking about single-process containers
to something identical to what you'd get with LXC. Which just runs /sbin/init.

The amount of wasted development effort caused by Docker's willful
intransigence on this is sort of staggering. The teams I work with using
docker are still tripping over new nonsense that would have been solved by...
I don't know, using systemd... after almost a year of trying to work through
the kinks.

~~~
wmf
I can imagine that composing a pod out of container images could have
advantages over composing a system out of packages because communication
between the containers would be more explicit.

~~~
krakensden
I see it as a hassle- I dont want to be doing a bunch or redundant
whitelisting to make the percona tools work. Worse, I don't want to ship them
separately, xtrabackup uses mysql as a library, which means separate
containers only buys you bugs.

Docker's design decisions make sense if you're shipping statically linked,
standalone binaries everywhere. Which I suspect docker.io and many other
people are doing. But that's also sort of a boring edge case where you don't
even need filesystem namespaces except for cleanliness.

------
zalmoxes
For reference: the kubernetes guys have an open proposal for pods in Docker
since October:

[https://github.com/docker/docker/issues/8781](https://github.com/docker/docker/issues/8781)

~~~
derefr
And even without them, if you develop using fig you're pretty much writing pod
manifests.

------
josh2600
As a very effective substrate for hosting containers, we at Terminal think a
lot about which of the container mechanisms will win over the long term.

My personal opinion is that the winner will be the group that successfully
gets Enterprises to change their workload design. I also don't think that
Rocket is necessarily a superior format to Docker, but I think they're both
dealing with the recognition that any big change in Enterprise behavior
represents an opportunity for value capture.

There's a real question as to where any of these abstraction layers fit in if
Docker wins (and there's some possibility docker is going to win). If that's
the case, coreos doesn't want to look back a few years down the road and wish
they'd been working on a container format.

It's 2015. One of the battlegrounds for enterprise dollars is containers. It's
going to be a delightful thing to watch.

It's also worth noting that many companies have their own cgroups
implementations which are neither docker or rocket based. I rather like the
position of dispassionate observer in this war (at Terminal we run all of the
containers and also apps without containers).

~~~
jacques_chester
> _It 's also worth noting that many companies have their own cgroups
> implementations which are neither docker or rocket based._

See for example Garden (née Warden)[0][1], which is the basic building block
of Cloud Foundry.

[0] [https://github.com/cloudfoundry-
incubator/garden](https://github.com/cloudfoundry-incubator/garden) [1]
[http://blog.pivotal.io/cloud-foundry-
pivotal/features/cloud-...](http://blog.pivotal.io/cloud-foundry-
pivotal/features/cloud-foundry-container-technology-a-garden-overview)

------
conradk
I'm still wondering what the appc spec has more than Docker (and vice-versa).
At the moment, I know Docker and find it easy to use. Why would I use Rocket
instead ?

Could anyone explain or link to non biased comparisons of the two, please ?

~~~
bryanlarsen
The enhancement I'm most looking forward to is the use of systemd for process
management. Docker handles that itself, and can lose track if the process
forks strangely and/or badly.

~~~
shazow
Like postfix. :/

People tend to wrap it with supervisord which does a better job at tracking
child processes.

------
zobzu
This is cool. Overlayfs IS a huge difference in performance due to fs level
caching amount namespaces. Hopefully btrfs will get that too, some day.

I must say however, I dont like the pod concept too much. That locks you in a
bit.

Additionally and in a different register, the deployment systems, while these
work fine when you have to the time to do things right, dont work so well in
practice.

All companies that I know of which have 1k employes or less (ie most)
basically dont update anything automatically because the redeployment might
still fail. And of course, manual labor costs a lot of human resources.

We still need a better way to separate the system update process from the
deployment, settings, and app.

~~~
jzxcv
Could you explain what you mean by "locks you in"?

~~~
jsprogrammer
You now have to run all those programs in the same namespace, on the same
machine. There is no possibility to run some of the programs somewhere else
(without building a new image).

~~~
tb93
No, pod is a collection of multiple images, not a single fat one.

~~~
jsprogrammer
Sorry, you have to rebuild the top level representation, which I guess is now
called a Pod.

~~~
tb93
No, Pod is designed for multi-containers grouped to run on the same host,
primarily for sidekick process, like syslog.

If you want to multi-host deployment, it is similar to CloudFormation. You can
still use multiple pods to compose a distributed app.

~~~
zobzu
across the network to a non-coreos container? ;)

