Yes, also it does not have data corruption issues reported with overlays (readers vs writers). Also it supports atomic rename. NO whiteouts required as in the case of a union file systems (so not to worry about deleted files coming back).
The comparison with systemd is unfair. Docker wants to be "batteries included, but swappable/removable". If you don't like host management, orchestration, build, etc., you can disable that specific component and put another one; and none of those components are strictly necessary.
Contrast with systemd, where it's impossible to use anything else, and the attitude of the maintainers is "our way or the highway" when people beg them to continue to support alternatives.
Compare Docker to frameworks like Django or Rails, which come with everything you need (templating, ORM, url mapping, etc.) but where each thing is replaceable if you don't like it; versus Rocket which would be like Flask or Sinatra, which are smaller and require to be combined with other things to be useful. Nothing wrong with either approach; but if the comparison is right, we can expect Docker to provide "reasonable defaults", and some people building some specific apps to use Rocket because they just want to run things and they don't need build/orchestration/API/etc (or they need special versions of those components).
You can use Django as swappable libraries. I worked on some projects at Google that used Django for the request routing, templates, and helpers, but completely swapped out the ORM for Google's own RPC system. Jinja2 is basically the Django templating language pulled out into its own library; before it existed, people would just use django.template. Some folks just use the ORM and request routing and then stick a JSON serializer on top to send data to an Angular SPA.
I am listening. Walk me exactly through how you think we should support alternatives, and why you think we're not. I will work it out right here with you.
I'm well-acquainted with Docker's architecture and some of the ways it's used in the field. I wouldn't call it modular. It might be well-factored and even separated into multiple modes and repos, but that's not modularity; that's just good code.
When you ship batteries, people depend on the batteries and that means you can't really swap them when you want to because things stop fitting. It doesn't help that all of this is baked by default into a single monolithically versioned binary with an API whose documentation isn't nearly rigorous or stable enough to promote alternative implementations.
I like Docker or I wouldn't be here commenting, but you know what would make me love Docker? If every piece was pipeable CLI command.
I know this is a crazy rethinking of how Docker's APIs work, but I think that fact perfectly demonstrates my point about how un-modular Docker really is as far as its users are concerned.
FWIW, as a startup cofounder with a non-technical partner who likes to do design/copyediting tweaks, the ability to do "docker up" and have it bring the whole system up on Linux, Mac, and cloud is a huge sell. I know how pipes work and can memorize a half dozen commands, but my cofounder certainly does not, and any tweaks she can do on her own is work that I don't have to.
I don't think it's crazy. I think it's cool and your points completely valid.
A good question we have to ask is how do we get from where we are, to the desired end state that you describe? There's nothing stopping it from happening, it's a fork away with a good chance of upstream contribution.
Today that's through proposals and discussions in freely available on github, irc, and mailing lists for the docker project and which we call fire hose of information symbolically.
Maybe we're missing an additional avenue for input and creativity. What do you think?
Well, I think that was my limit right there. If the above message got downvoted, I really don't see any constructive way to have a conversation here. I think I tried.
Come say hi on irc if you want to talk some more. We (the 200-ish people from all horizons on #docker-dev) don't bite.
Speaking only for myself, while I have no significant beef with Docker, I've found the general tone of your comments to be slightly off-putting. If others feel the same way, that might explain the downvotes.
I think it boils down to the tension between HN as a place for uninvolved commenters to discuss articles, and as a place for the subjects of those articles to engage in that discussion. Not to slight your intentions, but a comment like "I will work it out right here with you." comes across as an attempt to wrest control of the conversational dynamic, not to mention a little confrontational. For better or for worse, that's something that doesn't really fly when you have an obvious vested interest.
This is not meant as criticism, just food for thought that might help explain the frosty reception you've been getting around here.
"slightly off-putting" Argh, we are in a forum, this is communication deprived of non-verbal cues. Just focus on the intent and the information. I think shykes deserves more than judging of his tone. I also think it is cool he is hanging out here managing (mis)information. Are you all jealous or something? You have the chance to ask anything you want to someone who is the driving force behind a project of which the implications are hard to overestimate. And you find his tone off-putting.
I'm just a biologist but if any of the big names in my field (say, Hans Clevers, is that a stretch?) would be approachable on a forum, man that would great!!
I read it differently. I read it as: "it seems you have a key issue but I disagree with you. However, if you clarify your issue I will stay here and discuss it in the open right now."
>comes across as an attempt to wrest control of the conversational dynamic
And why shouldn't he do that? He's the one who sweated his ass to create the program, the other guy is just some random user who got it for free (and open source) and complains for something.
I think this is the kind of thing that might be at issue: https://github.com/docker/docker/issues/6791 [1] (I realize that the ticket is not closed, I just bring it up as an example of something that I see as counter to commoditization and thus counter to my goals as a user.)
One of the issues that I personally have with docker (much as I love it) is that it also wants to be a process supervision "framework" (for lack of a better word). I don't want that, I want a reliable way to supervise a docker-started process from whatever supervisor daemon that I want (whether that be systemd, runit, or whatever). This is not really for ideological reasons -- I want something that integrates properly into my distribution of choice, not something that wants to be a system unto itself.
[1] ... I'm obviously not the submitter of this issue. I just stumbled upon it during a related search.
I understand, but the problem is that to "just run a container" Docker needs to manage global system state and synchronize with other docker instances. Right now that is done with the daemon. How do I do this without? CoreOS's answer is basically "systemd should do all that". But to me that is not an acceptable answer. I don't want to tie Docker to systemd. It's already too monolithic as it is. Do we really want to absorb the docker daemon's functionality into it too? Because that's exactly what CoreOS is proposing with Rocket. I think that's a flawed design and the opposite of composable.
Docker can play with or without Chef/Puppet/Salt/Ansible/etc.:
- you can use configuration management tools to author Docker images;
- you can use configuration management tools to deploy Docker (and start Docker containers).
The following presentation has some Puppet-specific information (but the concepts map neatly to other CM tools):
FWIW, boot2docker became my favorite all-purpose, ready-to-run, ridiculously-small-and-therefore-insanely-fast-to-download VM image.
It's faster to download it (it's 25 MB) and start it with qemu, than to go through the clicky-pointy interfaces of VirtualBox etc., or go through the download of a full Vagrant box. This is game changing.
I don't know yet what will happen for Windows, but an upcoming version of Docker will run on OS X. (I say "upcoming" because I know some core maintainers have OS X support in their local branches, so it's just a matter of time before it hits master.)
It doesn't has the same isolation guarantees (yet) but it lets you use the same workflow.
Windows is different, but I can't imagine a scenario where you have to run your app on Windows. I.e. if it's your local machine, you can spin up a VM; if it's in your datacenter, you can use Linux. If your local policies are "we only run Windows on our servers, screw Linux!" chances are that you wouldn't run Docker anyway, even if it ran natively on Windows :-)
> that's actually most modern Linux systems now. Anything with a 3.8 kernel is game.
So Linux systems, that started shipping just this year?
Well but even that is not true because it was backport-ed to RHEL 6/CentOS 6 which is very cool.
Not all people live dangerously and install the very latest release on their server.
Ubuntu LTS (which is a common server platform) also doesn't natively support LXC well. It has an older kernel. So instructions for installing docker is to install a new kernel. A new custom compiled kernel on a production system. Hmm, is that still Ubuntu 12.04 LTS, some devops will argue it isn't, some will say it is fine.
Skate where the puck is going. Is it a comprehensive solution today? No. But I would rather see Docker double down on making the project great for those that have bought in than spend their resources building compatibility from people that have not. It's the difference between asking your customers what features they would find most useful and asking people that aren't your customers what features they think you need to build before they buy. The latter set of feedback is almost always useless.
> No. But I would rather see Docker double down on making the project great for those that have bought in than spend their resources building compatibility from people that have not.
I would rather see that too. So we agree there. If you read my comment, it was about making ridiculous statements about compatibility, not that I want or need more compatibility.
On a more general level it is about being dishonest and how ardent fans are enemies in disguise. They make ridiculous statements about the product that then creator of the product end up having to manage the PR.
