Fantastic! I really appreciate btrfs but ZFS has a longer, more battle-tested history. The pace of Docker improvements is impressive, and additions like this will help prove its longterm viability and encourage adoption by the enterprise.
That will probably never work the way you expect, if it does happen. While containers are awesome, and I love docker, it doesn't magically solve the difference between operating systems. Linux ELFs will not work in BSD, so if it does end up happening, it'll be with docker containers built for BSD.
Which is why Docker is an ultimately bad idea; OS-specific binary images are the wrong level of abstraction for managing the deployment of code that's otherwise completely portable.
I disagree. I think not having a continuous build pipeline for your containers is a bad idea. As a large enterprise I want to make sure that my software builds on all platforms my organization supports even if I don't _yet_ have any clients requesting compute there yet. Implementing the pipeline is risk mitigation against that and a whole other class of problems (namely not being able to rebuild containers, compliance/audits, etc).
That's a false dichotomy. One can certainly have an automated build pipeline and use a higher level of abstraction, thereby ensuring portability. Also, if you think docker style containers cancel the risks of unreproducible builds, I believe you are wrong... since in many cases, they depend on external network resource availability.
That's a false dichotomy. One can certainly have an automated build pipeline and use a higher level of abstraction, thereby ensuring portability.
I don't think that we are in disagreement here. In fact I believe in order to ensure portability that both are necessary. I don't see it being feasible to use a Dockerfile to build a container and just expect it to simply work on a different processor architecture. A higher level of abstraction, in my opinion, is an absolute necessity.
That is an ongoing topic among the maintainers: support for multiple hardware architectures and OS flavors is a defining feature of Docker, and we need to get better at it.
Within Linux-land we already deal with a multitude of storage and sandboxing backends, networking topologies, kernel versions and builds, packaging and dylib versions across distros, underlying supervisors etc. We've made good progress in wrangling that "matrix from hell" so that the upper layers of the stack don't have to. But things are about to accelerate exponentially on this front: in just the last 6 months we've seen 1) Microsoft engineers get hugely involved in adding Windows support, 2) Joyent "betting the farm" on making Docker a first-class citizen on SmartOS, 3) A big influx of new Linux distros: CoreOS, Boot2docker, Atomic, Ubuntu Core - not to mention the whole schism of traditional distros over "the systemd wars". 4) more and more unofficial builds of Docker for Arm and Power (not to mention x86_32), being deployed in production today!
Meanwhile we are getting the first mergeable patches to move Docker towards fully content-addressable storage and distribution - which once complete will give us the building blocks for real repeatable builds, a-la Nix or Gitian. Yes, fetching external content over the network and executing arbitrary code will always introduce side effects, but with better tooling there are lots of great ways we could manage those side effects. This is one of my favorite areas of the project, and there are lots of awesome ideas and prototypes floating around. Ping me on irc if you're into that sort of thing!
Obviously there is no silver bullet to make computation more repeatable and portable across a variety of machines and operating systems.. But the community is scratching its own itch, which means it will happen no matter what. There will be plenty of trial and error, but I think we collectively have an opportunity to improve the state of the art. That's the beauty of open-source :)
And, to state the obvious: the solution is certainly not to pretend that every binary can execute anywhere, unmodified, with the same behavior. Machines and operating systems are heterogeneous, that is a fact. Trying to hide that heterogeneity will not make it go away. Rather, we should embrace it, and define a portable set of commands and properties which have a clear and predictable definition everywhere. Sure, the property "I require a Linux kernel later than 3.8 on x86_64 to start" will not be handled in the same way on every installation of Docker - some may present an error because they are running on another arch. But that property still has a precise and portable definition, and all Docker installations will understand the same thing. Now they can choose to process that property in the most appropriate way: perhaps they will present an informative error message to the user. Perhaps they will look for an "other architectures" field in the image manifest and point the user there. Perhaps they will redirect the request to another host which matches the requirement (hint: that is what Docker Swarm does when it receives a 'docker run'). With this kind of design we can greatly improve our daily flow as developers and sysops, and we can do it on top of the systems which are installed in the real world, today.
I don't see this as that much of a hurdle to exclude BSD entirely. The same situation exists even with Linux. EL7 supports POWER7 and in the future ARM server clusters may even be a reality. I don't think we are ever going to be in the nirvana where a single runtime is going to be portable across the breadth of platforms a large organization needs to support. This is precisely why more focus needs to be on continuously building container dependencies in the same way upstream packages are.
The same organizations that are interested in deploying on POWER/ARM are likely the same that would like to see BSD/Solaris support.
The right base image could provide the same package tools for linux and BSD. A base image with pkg-src could work on linux and BSD.
I'm more concerned that the rampant success of docker on linux and the growing adoption in market segments who will demand first party support as a prerequisite for using it, is going to prevent Docker Inc from fulfilling their originally stated goals of supporting alternative container mechanisms on other operating systems. For instance RHEL customers.
I am working on a docker alternative called cims which allows 'services' targeting arbitrary 'platforms' to be deployed, managed and stored in any way decided by the 'cloud provider' in question. Currently, unixish 'Cloud providers' have an optional storage abstraction interface in place (to make writing them easier), though windows, erlang VM, or embedded platforms (qemu or android) could similarly be implemented as 'cloud providers'. The scope is therefore more of a generic building, packaging, distribution and infrastructure abstraction/management paradigm than an OS-specific virtualization workflow tool (like docker). Right now the main unixish storage provider is ZFS, but we've also tested linux loopback and linux md. I'm currently hiring a bit of a BSD enthusiast so we may just wind up adding jails (which I've used before). One benefit of the approach is that services can be benchmarked across different platforms and infrastructure can be operating system heterogeneous (security benefits). Docs at http://stani.sh/walter/cims/ ... background at http://stani.sh/walter/pfcts/ ... hoping to get the OK to open source it real soon now.
Note from the Docker guy: I look forward to reviewing this PR, I agree zfs support would be an awesome addition. However, note that this PR is not against the actual Docker repo but against a contributor's fork. I suppose it's because they don't yet feel it is ready to be contributed upstream. Except it's not marked as a fork in github so not sure if the usual PR system will work? In any case, we are happy to help if we can.
Also note that we have merged experimental overlayfs support in the upcoming 1.4 release candidate.
18 comments
[ 5.1 ms ] story [ 48.8 ms ] threadother than that: awesome!
What about the Linux compatibility layer?
Within Linux-land we already deal with a multitude of storage and sandboxing backends, networking topologies, kernel versions and builds, packaging and dylib versions across distros, underlying supervisors etc. We've made good progress in wrangling that "matrix from hell" so that the upper layers of the stack don't have to. But things are about to accelerate exponentially on this front: in just the last 6 months we've seen 1) Microsoft engineers get hugely involved in adding Windows support, 2) Joyent "betting the farm" on making Docker a first-class citizen on SmartOS, 3) A big influx of new Linux distros: CoreOS, Boot2docker, Atomic, Ubuntu Core - not to mention the whole schism of traditional distros over "the systemd wars". 4) more and more unofficial builds of Docker for Arm and Power (not to mention x86_32), being deployed in production today!
Meanwhile we are getting the first mergeable patches to move Docker towards fully content-addressable storage and distribution - which once complete will give us the building blocks for real repeatable builds, a-la Nix or Gitian. Yes, fetching external content over the network and executing arbitrary code will always introduce side effects, but with better tooling there are lots of great ways we could manage those side effects. This is one of my favorite areas of the project, and there are lots of awesome ideas and prototypes floating around. Ping me on irc if you're into that sort of thing!
Obviously there is no silver bullet to make computation more repeatable and portable across a variety of machines and operating systems.. But the community is scratching its own itch, which means it will happen no matter what. There will be plenty of trial and error, but I think we collectively have an opportunity to improve the state of the art. That's the beauty of open-source :)
And, to state the obvious: the solution is certainly not to pretend that every binary can execute anywhere, unmodified, with the same behavior. Machines and operating systems are heterogeneous, that is a fact. Trying to hide that heterogeneity will not make it go away. Rather, we should embrace it, and define a portable set of commands and properties which have a clear and predictable definition everywhere. Sure, the property "I require a Linux kernel later than 3.8 on x86_64 to start" will not be handled in the same way on every installation of Docker - some may present an error because they are running on another arch. But that property still has a precise and portable definition, and all Docker installations will understand the same thing. Now they can choose to process that property in the most appropriate way: perhaps they will present an informative error message to the user. Perhaps they will look for an "other architectures" field in the image manifest and point the user there. Perhaps they will redirect the request to another host which matches the requirement (hint: that is what Docker Swarm does when it receives a 'docker run'). With this kind of design we can greatly improve our daily flow as developers and sysops, and we can do it on top of the systems which are installed in the real world, today.
The same organizations that are interested in deploying on POWER/ARM are likely the same that would like to see BSD/Solaris support.
I'm more concerned that the rampant success of docker on linux and the growing adoption in market segments who will demand first party support as a prerequisite for using it, is going to prevent Docker Inc from fulfilling their originally stated goals of supporting alternative container mechanisms on other operating systems. For instance RHEL customers.
Also note that we have merged experimental overlayfs support in the upcoming 1.4 release candidate.