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.
I must say however, I dont like the pod concept too much. That locks you in a bit.
They didn't make it up, it's straight from Kubernetes. Presumably the Docker team will wind up incorporating something similar soonish, as well.
That said, it's basically a fancy pants way of saying "we are going to run multiple processes in the same namespace", and if you're using runit like so many people are, you're already doing it.
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).
Comments
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.
They didn't make it up, it's straight from Kubernetes. Presumably the Docker team will wind up incorporating something similar soonish, as well.
That said, it's basically a fancy pants way of saying "we are going to run multiple processes in the same namespace", and if you're using runit like so many people are, you're already doing it.
Could you explain what you mean by "locks you in"?
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).
No, pod is a collection of multiple images, not a single fat one.
Sorry, you have to rebuild the top level representation, which I guess is now called a Pod.
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.
across the network to a non-coreos container? ;)