Announcing Docker Machine, Swarm, and Compose for Orchestrating Distributed Apps
blog.docker.com
blog.docker.com
- The meme that we are adding more and more features into the docker binary is unfounded. Please, please, I ask that before repeating it you do your homework and ask for actual examples. For example 1.4 is coming out next week: it has 500+ commits and basically no new features. It's all bugfixes, refactoring and a general focus on quality. That's going to be the trend from now on
- Swarm and Machine are separate binaries. They are not part of the core docker runtime. You can use them in a completely orthogonal way.
- Swarm follows the "batteries included but removable" principle. We are not doing all things to all people! There is a default scheduling backend but we want to make it swappable. In fact we had Mesosphere on stage today as part of a partnership to make Mesos a first-class backend.
- there is an ongoing proposal to merge compose into the docker binary. I want to let the design discussion play out, but at the moment I'm leaning towards keeping it separate. Now's the time to comment if you care about this - that's how open design works :)
Yes, our blog post is buzzwordy and enterprise-sounding. I am torn on this, on the one hand it helps make the project credible in IT departments which associates that kind of language with seriousness. We may find that strange but if it helps with the adoption of Docker, then it benefits every Docker user and that's ok with me. On the other hand, it is definitely not popular on HN and has the opposite connotation of dorky pencil holder suit douchiness. Being from that tribe I share that instinctive reaction. But I also realize it's mostly psychological. I care less about the specific choice of words than the substance. And the substance here is that we launched a lot of new stuff today, and put a lot of effort in keeping the focus on a small, reliable runtime, composable tools which do one thing well, pluggability, open APIs, and playing nice with the ecosystem. Basically everything the community has been worrying about recently.
Does Docker's expansion into orchestration and clustering endanger CoreOS and maybe other players? Certainly. Is it the same approach? Definitely not. The CoreOS approach to containerization using Docker, and now Rocket, is novel. I haven't considered it for any of the architectures I'm presently building for companies - I prefer to let the operating system do what it does best, and build my services on top using containerization.
I was worried about what Docker's plans for clustering entailed leading up to today. I have been using Mesos for the better part of a year, and see it answering many problems that reach beyond the container model. I think people should do as you suggest, and re-evaluate this on two fronts: 1) Swarm is separate from Docker, so we can continue to deploy Docker through Mesosphere Marathon onto Mesos as we've been doing. 2) Because scheduling is pluggable - as the source code validates for us - we can work in Mesos as we see fit.
As for the proposal, I vote to keep Compose (and the fig codebase ;) ) separate. It will be much easier to add the hooks necessary to do cluster management between Compose and Swarm without risking regressions to Docker.
Also - what has become of the Docker Governance Advisory Board? I think the ratification of a standard / specification would go a long way to solidify trust in the industry (much like CoreOS is trying to do with their App Container proposal).
- Paul
It is worth reading through the notes from the last/only meeting: https://docs.google.com/document/d/1JfWNzfwptsMgSx82QyWH_Aj0...
As an aside - I've watched headless projects devolve into anarchy... here's a good read from years ago - http://ariya.blogspot.com/2008/03/common-characteristics-of-...
I'm glad to see the new projects (swarm, at least) layered on top of Docker. It is good to see those sink/swim on their own. I was uncomfortable when Docker was (last week) going down the path of building everything into their existing binary.
The good thing is that this is open-source Apache-licensed code. Easy enough to fork it if necessary, even if just temporarily while we wait for another project to mature and replace it.
Hudson -> Jenkins
Mysql -> MariaDB
Docker -> ???Joe I can appreciate the drive to aggressively monetize a specific business model ;) but if you really feel what you've seen at Google should win, you'll have much more leverage taking a pedagogical approach. Appreciate that you have certain duties.... perhaps you might have had more agency at Facebook?
From reading the minutes, it seemed to me like one of the clear conclusions (based on concerns raised by big stakeholders) was that Docker Inc. was going to be firewalled from the Docker open-source project and that development work going forward was going to be done in a more open fashion.
I gave a presentation on this topic at Dockercon today, it talks about how the project is organized, how the company is firewalled, and recent improvements we're working on since the DGAB. I will share the link with you once the video is available.
The advisory board met last month. Here is a writeup http://blog.docker.com/2014/11/docker-governance-advisory-bo...
There is also a link to full minutes.
JB (Google): Docker is an anchor of a large ecosystem of projects. Docker Inc
bought Fig, is it a separate project or is it going to be in Docker?
SH: it should be explicit. The Fig guys make proposals and those are reviewed
as every body else's.
JB (Google): The idea is we will be more comfortable if we know how to
contribute both to Docker and the larger ecosystem.
SH: The day after Docker Inc. acquired Fig nothing changed at all, everything
is still in the Open. The reason for the acquisition was to make Docker more
user friendly. The experience should be awesome. The more people we can throw
at the problem the better.
VL: Understanding what is off limits or at least where the limits are would
be helpful. This is entirely driven by technology? We can collaborate "here"
but maybe we can compete "there".
BG: It's absolutely right, there is a large number of projects competing with
Docker Inc. and that's fine. Some folks want Docker to remain a packaging
format. We should add a statement there on clarifying this.
https://gist.github.com/inthecloud247/00eb3130f728b635db9e
https://docs.google.com/document/d/1JfWNzfwptsMgSx82QyWH_Aj0DRKyZKxYQ1aursxNorg
The Docker team needs some space to execute on the opportunity before them. Space to try, fail, innovate. The end product will be better if they have that space and don't have to achieve equilibrium with too many stakeholders or worry about political microfriction when attempting big leaps.
The bleeding edge is bloody; if you need full-featured orchestration TODAY, your best bet is probably something older than Swarm, Fig, etc.
Docker Machine is separate from Docker. Once Machine was released, what was the point of talking about integrating the functionality into Docker?
They've repeatedly stated that they want Machine and Swarm to be totally separate tools.
Why then is there all this fuss about how these projects are organized? If its a good idea (which it is) won't Linus just reimplement(conform) all of these projects and move them into the kernel anyways?
That is not true. It can be just one process. It does not have to be.
> So its just a better Operating System process
No. That's just a tiny bit of what Docker provides, and even that part of what Docker provides is largely "packaging" of cgroups functionality. That was largely there with tools like LXC
The real value Docker provides is a means of building and managing images, and mediating things like capabilities and port mapping in a user friendly way
> won't Linus just reimplement(conform) all of these projects and move them into the kernel anyways?
Not a chance. There's no reason why these things needs to be done in kernel space. Some features that they may want, such as improvement to filesystem overlay support, or low level "plumbing" to make overlay networks more efficient, could end up in the kernel if someone comes up with something good, but there'd still be plenty to do for the userspace tools.
By defining a standard way of orchestrating you make life easier for users that can deploy with confidence the same environment across multiple clouds, etc. BUT the tradeoff is that you alienate another set of parties (providers are commoditized, ecosystem partners offering alternate orchestration tools feel marginalized). Secondarily, there are concerns whether your approach is better than others and that is too early to tell.
I am curious to see how all this plays out, lots of things at stake here and a very thick fog of war :)
By creating these orthogonal solutions, Docker isn't taking the air out of anything. Do these solutions hurt Amazon's proprietary use cases? Or Google's? Or [insert managed Docker platform here]? No.
If anything, they just make it possible to use Docker without third parties. Maybe that's scary to third parties, but there's no reason a company shouldn't compete in its own ecosystem as long as it doesn't unfairly punish competition.
So if Docker acts like modern-day Microsoft for enterprise, where solutions are sold from many vendors with many mixes of products, then great.
If they act like Apple, where they crush and eliminate overlapping services, then I guess we'll all be switching to the CoreOS containers someday...
At the moment I have to choose between multiple competing solutions. Competition is good when there are strong differentiating features.
In the "Orchestrate Docker" field the requirements are so clear after using it for your first project that it isn't at all clear what benefit competition, or solutions outside of the core Docker product suite gives.
As the ecosystem is recent and evolving quickly, we are looking at ways to handle multiple containers and deploy them at scale. And often, there are several solutions.
Having docker provide the set of components (and it's great to have multiple components for that) helps in defining a standard direction.
And as long as all the components are open source and can be deployed on our end, we are glad to use them. We would consider switching if somehow the docker tools become tied to a proprietary service or tool, which is unacceptable for our customers.
Also, I filed an issue on the Github repo for this, but "machine" is already used by a command line tool on OS X and other BSDs.
Perhaps "docker-machine" and "docker-compose" are good compromises in both cases.
So with docker-machine binary on the path, "docker machine" would just delegate to that.
Similarly, if I had a docker-flynn binary, "docker flynn" would just magically work.
This means that the main binary is composable from multiple parts and its easy to write plugins for other systems.
There are always symlinks and/or shell aliases if you want to override that locally.
Well, first of all, thanks for Docker, it is a great product, love using it!
My only criticism is:
I find it scary and kind of shortsighted that docker (and even more so rocket) seem to neglect basic networking features. From what i can tell everything is based on the approach that you write your webapp with docker in mind, but i for one, would like to use my legacy applications with docker and i would like to write applications with full networking in my control. I really, really don't want docker to choose some IP for me. And i really really don't want my apps to talk over some random ports. I want control.
So far everything is still based on some random interfaces and ports that are passed around.
We hear you and we already started working on addressing just that. The goal is to define a networking interface (a set of functions) that networking plugins would satisfy. Again: "batteries included but removable". There's a lot of work to be done and details to be figured out, but I can assure you that networking is not left out, and is going in the right direction as well.
We will send out a proposal on Github as soon as we can. Stay tuned!
apt-get install docker.io-platform
My vote (not that it gets counted here) compose should definitely be merged.
Great job on all the rest, ignore the haters, they just prove you've made it!
They appear to enjoy first-class support in the docker CLI. Is that right?
Pluggable scheduling and placement is a good move. It all looks like a straightforward operations research problem ... until you discover that you built a SPOF subject to the network fallacies.
The `-m` flag was already present in docker run. Swarm makes use of that flag to decide on which host to put a container. The `constraint:` setting is indeed new, but (afaik) the values behind it are not pre-defined, so if someone develops an alternative clustering-backend they should be able to make use of that for their needs.
In any case, Swarm will be pluggable, so other back ends are possible and can be developed by other parties.
"""In 2013 Dawkins characterized an Internet meme as being a meme deliberately altered by human creativity—distinguished from biological genes and Dawkins' pre-Internet concept of a meme which involved mutation by random change and spreading through accurate replication as in Darwinian selection. Dawkins explained that Internet memes are thus a "hijacking of the original idea," the very idea of a meme having mutated and evolved in this new direction."""
Someone below compared this to systemd - it's really more like your entire containerization operating system. And since you run everything via containers, it effectively is your operating system/platform.
So, clearly they (and CoreOS, etc.) will want to monetize their container operating system/platforms. But is it really a good idea to build the entire industry's concept and implementation of containers themselves on the back of a single company's implementation, when we know a healthy ecosystem would see a number of companies with competing implementations of container OS with varying degrees of compatibility, and hopefully eventually open standards.
I really am beginning to see the CoreOS guys point here - if Docker could have just stuck to running containers and doing that awesome, there would have been space for other companies to build out the ecosystem around that shared interoperable container format. But if Docker is now set on tightly bundling a toolchain for the container operating system around their format, suddenly it looks a lot more like they took a Microsoft embrace-extend-extinguish approach to LXC.
And thus the need for Rocket.
That's overstating things slightly, since it appears no Docker employee has ever contributed a single line of code to the LXC implementation itself (that would be hard work, rather than bikeshedding userspace tools, after all). The kernel tree contains only one reference to a Docker bug, fixed by a Red Hat employee, while the LXC tree contains a single reference to a Docker bug, fixed by a Canonical employee who looks to be one of the LXC maintainers.
The reality is replacing Docker isn't all that hard, as we're now seeing with Rocket. The kernel interfaces aren't tied to it (hell, its clear from Git logs the LXC devs are barely even aware of it).
edit: It's simpler to look at Docker and Rocket for what they both are: commercial plays built on the work of others. That work hasn't magically disappeared somewhere, it still exists and is in use (albeit by a slightly less PR/buzz-aware side of the community).
A vendor-independent implementation of containers already exists, as it did long before Docker did. If people are serious about seeing the "container ecosystem" flourish, they should be contributing cash, employment offers, or employee time to the real people and projects doing the work (as opposed to publishing upset blog posts and writing fashionable Go code)
I think the strong interest in Docker demonstrates there's a need for a layer on top of LXC. It's open source, so what's the problem?
There is undeniable confusion about LXC and Docker with a lot of folks whose first introduction to containers is via Docker who seem to think LXC is 'low level kernel capabilities' as it is mistakenly referred to on the Docker website, and since Docker was based on LXC they at least should be clear what LXC is.
The fact that LXC is an advanced project baking since 2009, supported by Ubuntu since 2012 which provides perfectly usable Linux containers, wide choice of OS templates, features like unprivileged containers and is easier to use than Docker is often lost in the noise.
LXC provides you system containers, Docker takes that base that to provide app containers, and there is definitely interest and value in that but it's a single use case of Linux containers. Would you want to reduce a container to an app for all use cases?
To conflate a single use case to container technology itself is a mistake, apart from the fact that once you go down a custom container format you will need to expend engineering resources to figure out how to make a lot of things like clustering, services, apps, networking that expect a normal OS environment work with the constraints.
Yes, I would. At least for the work I do, it's exactly what I require, and takes a lot of the work and thinking out of what I need to achieve. That's not a bad thing, and I'm not arguing that it's how it should be for everybody, but that's the best part about open-source, you can choose a different implementation or write your own on the same tooling :)
You keep using this word, bikeshedding. I don't think it means what you think it means.
http://en.wiktionary.org/wiki/bikeshedding
http://www.urbandictionary.com/define.php?term=bikeshedding
TL;DR; it's about discussing/debating trivial details instead of the important characteristics of a system, not about working on easy stuff vs more hard programs.
I think what hosay123 is trying to say is that LXC is the power plant and the tooling around it is Docker, which runs in userspace. Note I'm not trying to say that, I'm just saying things.
But the first difference (with bikeshedding) is that bikeshedding is not "doing the tooling around the power plant instead of the plant itself" but spending time discussing and designing some insignificant detail instead of the power plant.
(That is: bikeshedding is getting lost in DEBATING the easy and incosequential details of an implemntation).
Docker is neither "lost in discussion" (they're building things, and a lot, and fast), nor a trivial detail (that would be e.g. LXC code's tabs vs spaces convention etc).
Actually, I'm going to say: thus the need for Cloud Foundry.
I work for Pivotal Labs and I'm secondment to the CF Buildpacks team, so I'm biased. And this shouldn't be construed as official opinion, it's just mine.
Cloud Foundry is led by Pivotal, but we run it openly. Anyone can follow our repos[1][2] and our Tracker projects. The entire platform is being signed over into an independent Foundation with more than 30 paid members[3] (including Docker Inc). The whole project is being written the Pivotal Labs way. Everything is TDD, everything is pair programmed.
If I had to bet a company on a platform, I'd bet it on us. We're building the first and only truly independent, truly open source, truly open core, truly multi-company PaaS that is available.
You can buy support and hosting from us, IBM, HP and a series of mid-tier providers right now. You can do it in the public cloud or in a disconnected datacentre.
Oh, and we're going to have baked-in Docker support with our next-gen executor (Diego), in addition to Warden system we developed before Docker was released.
[1] https://github.com/cloudfoundry/
[2] https://github.com/cloudfoundry-incubator/
[3] http://cloudfoundry.org/about/index.html#the-cloud-foundry-f...
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).
Systemd is a modular system, and it's also possible to not install different components if you want. Most of the components aren't strictly necessary.
I think your community is begging you to continue to support alternatives. You just aren't listening.
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.
Like...
docker-listen tcp://,... | docker-run --image-tar=blah --container-tar=blah | docker-monitor --log-file=blah | docker-swarm --orchestrator-socket=orch.sock | docker-link --port=some.other.machine:port
[1] http://git-scm.com/book/en/v2/Git-Internals-Plumbing-and-Por...
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?
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.
Happy hacking everyone.
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.
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!!
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.
Ideally in the future, Docker will become an HTTP for servers, with standardized and competing servers/clients/services. I like the idea of that future. Publically, the Docker folks seem open to it.
However, I do see where you're coming from. As a for profit Docker has every incentive (perhaps even fiduciary duty) to pull the good ol' technology bait-and-switch: get Docker on every server, and the create a Kafkaesque technology dilemma to squeeze the dollars out of everyone who bought in. Microsoft's playbook has plenty of tips on how to do this.
I guess the only solution as a Docker user is to be hypersensitive to any sign that Docker wants to start locking the technology to the company. When you can imagine the day you can't use Docker (the containers) without Docker (the company), it's time to run the other way fast.
But I can't see that day yet, and I hope I never do. And I hope Docker as a company can find a way to grow without using that oldest, sleaziest trick in the book.
I'll leave you to decide what that means...
Frankly I'm not sure what the sockpupperty accusation is about, since I'm not particularly promoting any direction.
Regardless -- Your twitter post came almost 30 minutes after the account above was created and 30 minutes after this article was submitted to HN.
You mean like the conferences they held before they even had a viable product?
Docker has stampeded onto the scene with zero competition, and the Parent comment is totally right -- we should take a good minute and consider that we are head-first rushing to implement everywhere a product made and perpetuated by a for-profit company who's end goal is literally to be on every server and be the de facto implementation so that once they start to monetize the product, you will have little choice but to funnel support funds into their company.
That's petrifying to me, because it means if realized, my company will be at the whims of Docker, not the other way around.
Furthermore, the backlash from the Docker creator himself the other day on the announcement by CoreOS, it really seems Docker never anticipated ever having any competition in this space, and have taken active steps to ensure they are their own custom thing that is not compatible with other existing or future container implementations.
Perhaps this will change now, and they will work with CoreOS to clearly define a universal specification for a container which can be portable between any implementation, but signs show they don't feel it's in their company's best interest to do so (and honestly it isn't in their best interest, but it's in the community's best interest for sure).
The conference was awesome and there was plenty to announce at that point. It certainly helped drive home the conceptualization of containerization for many.
> we should take a good minute and consider
You're right we should consider - except what you're doing is making charges like;
"we are head-first rushing", "perpetuated by a for-profit company", "my company will be at the whims of Docker"
And other fear in this thread without providing your audience with the context of: - for profit companies backing an innumerable number of major technologies in a variety of fields since technology was a thing - most of the development of Docker happens outside of Docker Inc - the project has an independent governance board - the project has been nothing but the epitome of successful transparent open source
If Docker ends up achieving a cohesive ecosystem of holistically designed pieces solving one of the most difficult unsolved problems (a class of problems, really) in modern computing benefiting so many then is it really a problem paying Docker Inc for first class support to all of that? I imagine there are already companies selling support for Docker other than Docker Inc
It seems like you're the one imagining there is going to be no competition, honestly.
> if Docker could have just stuck to running containers
Full disclosure: I say this as a founder of a higher-level cloud service (Zencoder) that Amazon decided to compete with head-on. We're doing just fine, thanks (growing quickly, differentiated product), but Amazon is aggressively expanding upstream and is going to continue to do so.
Recent post by Docker CEO Golub:
There are over 650 contributors (95% of whom do not work for Docker, Inc.).
It blows my mind that on Hacker News of all places, people are suggesting that the Docker folk should not compete because it might upset some other companies. That's crazy.
The 'future' of compute is ubiquitous trustworthy compute for all. A federation where no one entity controls a pool of power over a given layer of the stack. The layers that run on top of that layer will continue to divide and stratify themselves, as it always has been. They will also assuredly be owned by someone or something. My vote is the something.
I don't feel like I can depend on any of these things, so I stick with the absolute bare minimum of what will build me a container. Which of these technologies will stay? Which will go? What will change as time passes? What will be deprecated?
In all honesty with Kubernetes talking about supporting Rocket and probably any other container technology that creeps up in the next few years, I'm leaning towards using that as the point of stability which I can deploy anywhere and know that I get the exact same API. Google, the leader in cluster management writing open source orchestration technology, think that's where I'll keep my focus.
This whole "wheres docker going" thing is getting blown way out of proportion. Docker Swarm was built by ONLY 2 people on the docker team (https://github.com/docker/swarm/) and they are totally separate binaries. Thats like saying I cant use Google X anymore because Google is building Google Y...
Some of these considerations are valid (vendor lockin, etc), but they've been valid for a long time. Nothing changed today or the day rocket was launched.
Disclaimer: I like docker but I have no horse in this race, my only affiliation is using docker.
I have quite a bit of experience in the microservice and cluster management space and have started to prototype something much more accessible to the masses. I'll know within the space of 6-8 weeks whether it's actually going to work or not but nonetheless we need people who understand and use these technologies on a day to day basis in the general tech space.
Cloud Foundry already has a container-based PaaS and it's only getting better. And it's not tied to a single vendor.
Disclaimer: I'm biased as hell, I work on CF for my dayjob.
I'd love to see what you're doing if you're open to sharing.
Building a microservices ecosystem. Starting with one click Cluster as a Service with Kubernetes on multiple cloud platforms. Then leveraging that to offer a microservices platform which gets you started extremely quickly much like Heroku but with the idea of deploying multiple services that coordinate to create something much larger.
I'm not so sure Redhat will make things simple enough and "just work" for non-corporate clients.
Now what?
Flynn? Deis? Kubernetes? Mesos? Shipyard? Pure Fig instead? CoreOS, Serf, Maestro? Rather stay on AWS with Elastic Beanstalk or the new docker service?
Welcome to the party, Swarm and Compose. By now we are not even sure anymore if Docker itself is still the way to go, now that Rocket and LXD have arrived. I don't even have the time to compare all these options, respectively get a deeper look into architectural considerations.
What to decide by? Company backing? Because it's good or bad? Github stars? Deis for self-announcing it's 1.0, even if it's based on pre1.0 components or Flynn for being honest they're still in beta?
Honestly, I've rarely been as tired of new technologies as I have been by now. I could roll a dice as well. If you have a good and reasonable choice for me, let me know (I'm actually serious)
Basically, we're going to let Amazon do it for us. Makes it easier that way :)
If I were Docker, I would organize the ecosystem for the end user on a nice clean website that explicitly lists the specific layers and technology options, some of which are from Docker, and some of which are from third-parties. Yes, they'll give mention to competitors, but at least it creates clarity and puts some meat behind their claims of "Open".
At present, I'm thinking of the following:
* CONTAINER: Stick w/ Docker since until a competing standard like Rocket is mature, everyone has to support Docker, even CoreOS
* CONTAINER MANAGEMENT: Use CoreOS. Per above, they have to support Docker until Rocket is fully baked. Then Rocket and CoreOS will probably have synergies you can't get with Docker / CoreOS. Also, from [1]:
These three [Docker] orchestration services are targeted
for general availability in Q2, 2015.
[1] http://blog.docker.com/2014/12/docker-announces-orchestratio...
1. reviewing our immediate requirements 2. doing a quick paper research for those that match 3. selecting a top five based on GitHub stars and helpful resources on the web that we can find 4. proceeding with a more complete technology assessment
We plan to make things as agnostic as possible so we can keep a watch on the space as things progress and if things change we can swap out a component for something else which may better meet our future requirements and/or have better long term mindshare or traction.
From the announcement: "Docker Swarm provides high-availability and failover. Docker Swarm continuously health-checks the Docker daemon’s hosts and, should one suffer an outage, automatically rebalances by moving and re-starting the Docker containers from the failed host to a new one.".
Does anyone know how they'll handle the data? Both Redis and MySQL have various ways to deal with high availability e.g. Redis Sentinel, MySQL master / slave or MySQL multi master with Galera.
Ultimately, I gave up and created a separate Ubuntu VM to run as an NFS server. Every CoreOS instance mounts it, and then my data-only containers now map back to the NFS mount. This way, when CoreOS moves the Redis or PostgreSQL containers, it has the data available to it.
It's not my favourite setup, but it's worked well-enough this past week that I haven't had to manually correct things while on vacation.
I'm hopeful that someone smarter/more experienced can share a better solution.
http://www.time-travellers.org/shane/papers/NFS_considered_h...
The tl;dr basically boils down to the fact that PostgreSQL and MySQL (or really any good database engine running on *NIX systems) make very strong assumptions about the POSIX-ness of their underlying filesystem: flock() is fast, sync() calls actually mean data has hit disk, etc.
Docker/CoreOS/etc. aren't a replacement for a good SAN or other reliable storage. If you value your data I'd suggest keeping your core database(s) on dedicated machines/VMs (ideally SSD-equipped and UPS-backed). If managing those is too much work, consider a managed cloud database; DynamoDB and RDS can stand in for Redis and Postgres, respectively.
Oracle runs just fine on NFS. In fact, some of the largest implementations in the world utilize the protocol.
As it stands, the VM server is UPS-backed, but does not run on SSDs. There is no SAN. If I were to fix the existing implementation, I would: a) Add a secondary VM server as a redundant backup. b) Add a SAN
However, I don't think I can justify the capital expenditures for that. So what I'll likely do is replace the NFS server with a dedicated PostgreSQL server (VM), and perhaps start thinking about moving the majority of the infrastructure out of the building and into the cloud to take advantage of things like RDS. The latter is even more important for scalability as we add more customers.
We are super interested in building this as a plugin for Swarm, and are trying to work with Docker to make sure the plugins system is suitable for us to be able to contribute it for Swarm users in general.
GitHub repo for Swarm: https://github.com/docker/swarm
Compose is still being designed in the open. If you want to have a say about how it works, check out the proposal: https://github.com/docker/docker/issues/9459
Does any one agree it's still too hard for dumb dumb developers like me? I'm on windows (boo hiss) so in the past I've tried to use boot2docker, but you can't just point your webserver container at a place on your local file system and say serve that please
You have to bring in some crazy storage file container which will serve it all via samba or something and then you need to figure out linking those containers together and then how the hell do you tell a web server "hey you, document root is over here on another container"
At this point I'm usually like fuck it we'll use some bad idea .exe web stack and develop as normal I like the idea of containers, quicker smaller than vms, nice file system history going on but in practice it isn't easy enough in my opinion
1. Statically compile your application so that it can run standalone. For ruby, python or java that means including the interpreter and any dynamic libraries. Hard at first, but once you have a build setup it's pretty straightforward
2. Bundle your application with its assets in a zip file or tarball
3. Make it so that your application has a well defined set of resources it uses that are isolated from other applications. For example with a database you might have a `your-app\data` folder where it stores the actual database. Also make sure you are careful with ports
4. Pass around configuration via environment variables that you hand to your application (ie: DATABASE_HOST=127.0.0.1)
With a setup like that you can build a sensible stack that runs anywhere. You don't need containers:
1. You don't need the protection: just don't write processes which clobber other processes. It's not that hard.
2. The reuse mechanism seems cool, but it comes with baggage. Which version of ubuntu are you starting with? Does it include the latest updates to shared libraries? If it does how do you know that your application will still run down the road? And if it doesn't, how are you keeping on top of security updates?
3. Containers, as envisioned by docker, are way overkill. Why do you need an entire ubuntu to run a simple web app?
edit: Also, its inefficient to build this Dockerfile every single time on every single host, which is why I'm talking about shipping tars. You could have 30 hosts with these 12 containers running on each one.
Any plans on dealing with something like this in the future?
In practice, running a private registry is a pain (last I checked the official Docker image for it crashed on startup). I like what Rocket is doing here with filesets and plain old URLs.
It will take an arbitrary rootfs (tar file) and turn it in to a docker image.
Docker can import arbitrary layers from a tar file either via the command line or the api. The problem is there is no official way of getting a set of arbitrary layers.
That might not seem like a big deal, but when your image has something heavy like mono or java and pushes upwards of a gig or more running on a relatively puny cloud instance with poor I/O that adds up.
If you want to have a much more efficient workflow, you have to roll this yourself like we did by going direct to the file system (at least for export). This is a messy pain in the ass and I would not expect most people to do it.
I would be very happy if Docker stopped trying to shove the registry down our throats and gave us a model where we could substitute our own push/pull code that better utilized our existing infrastructure.
This is a case where Docker feels more monolithic than it needs to be and I would be happier if it was broken up into a set of smaller more independent tools (e.g. docker, docker-push, and docker-pull).
Leading questions, I know, but I couldn't agree with you more and I know I'm not alone.
If you don't know the truth - open source works a lot like other software projects. You gather feedback in as many different forums as possible make a guess at how to solve that, work with your developer communities and vested parties to come up with a solution iterate a bunch of times and hopefully get something out in users hands that doesn't completely suck.
So the question is - Who's going to work on what and in what order? The feedback is important and with enough it would get higher on the list. But someone has to make it happen. Or make a proposal on how it would work. That would be truly welcome. Let me know how I personally, and we collectively, can help.
> So the question is - Who's going to work on what and in what order? The feedback is important and with enough it would get higher on the list. But someone has to make it happen. Or make a proposal on how it would work. That would be truly welcome. Let me know how I personally, and we collectively, can help.
The community clearly desires a more stable and pluggable core, doesn't like the registry workflow, and desires a daemonless mode. If the discussion over the last few days hasn't woken the Docker team up to that fact, then I don't know what to say.
The new features are big and flashy so they get the big announcements, however, you should not be surprised that when a new announcement is dropped the community collectively responds "what about x y and z?"
I think a Roadmap to 2.0 is what is missing and would give the community the confidence that is currently lacking.
Also familiarity with how union FSes work and using 'docker history' to trim container size makes it a lot easier.
You can build your docker image, push it to your registry, and all the production machines will only have to pull the new layers.
There's a lot to be said for making something only do one thing and doing it well, but it starts getting tough to keep track of when you've got a bunch of somethings.
You don't have to. It really depends on what you're trying to do. Using Docker alone, you'll be able to build and run containers, link them together to build a "stack" etc.
If you want to make building a stack (a group of containers that together form your application) easier, you can use an orchestration tool to automate this, for example, Fig, Crane, or now Compose. Or, create a bash script to do this; it's up to you.
If you want to build a cluster (run your containers distributed over several servers), you can do that with docker alone, but it will get hard to manage. You can build a tool for that (making use of the Docker API), or use an existing tool, like Flocker, Shipyard or now Swarm.
So if all you need is running a few containers on a single host, Docker alone may be enough for you, in that case you can safely ignore the other stuff for now.
I should have clarified on that earlier, but I'm interested in Docker for the more clustered approach. I don't really want to re-invent any wheels if I can't help it, so I'd be using existing tech.
Just in your reply, you mentioned:
* Fig * Crane * Compose * Flocker * Shipyard * Swarm
Whew. That's kind of what I'm chaffing on. I could learn all of this, but it's a lot harder to casually understand how it all would potentially fit together.
This is part of what the things mentioned in the announcement should help with. There's a clear need for clustering and linking, and so lots of people have built different tools to solve it. That's grand, but it's incredibly confusing coming into it. Particularly since tools vary from production ready to beta to "not actually implemented yet".
The aim here is to still allow people to come up with all kinds of different approaches but to have a set of components that work and are supported by docker. So that you can just get it and it works, and then start swapping bits in and out for the new hotness or some ultra-performant component/etc.
There could be some simple solutions to this, mostly centering around education and the promotion of the most popular components. I don't have answers, here, but figured I'd share that it's getting a little confusing in case someone had ideas.
I fully agree, I find the whole ecosystem really confusing. Every time I look at it there's some new combination of things, but then one turns out to be alpha/beta ...
What I hope is that the production of these new docker 'blessed' tools will allow me to go to their homepage and see a series of "getting started" tutorials and easily installable tools so I can at least get going.
Baking these features into Docker is the beginning of the end of Docker's Enterprise story. Moving forward with these proposals guarantees the rise of Rocket and other Enterprise focused containers. Docker is forking its own community here.
https://github.com/docker/machine
https://github.com/docker/swarm
Compose is still in the design proposal stage. We want to hear whether you think it should be built into Docker or not: https://github.com/docker/docker/issues/9459
The proposal discussion: https://github.com/docker/docker/issues/8681
Rename "docker hosts" to "docker machines": https://github.com/bfirsh/docker/commit/e6abec4033f48d1cad31...
2 days ago, from you:
I have now rebased the host management branch on top of #8265 and squashed it:
https://github.com/bfirsh/docker/compare/host-management
Any pull requests should now be based on top of that. The driver interface hasn't changed, so it should be a trivial matter to rebase any existing pull requests. The main thing which has changed is that drivers are expected to set up identity auth for communication with the host. See this commit for an example of how to do so.
The old branch is here for reference.
Full update and preview builds coming soon."
Has there been any progress on splitting the actual driver implementations out of the core binary?
So unless I misread the thread, your timeline is a bit off.
In fact they announced a partnership with Mesosphere that will swap Swarm out and replace it with Mesos as an example.
- the former is managed by the Docker Governance Advisory Board with people from many companies and individuals, see minute of the first meeting here for example: https://docs.google.com/document/d/1JfWNzfwptsMgSx82QyWH_Aj0...
- the latter is a company that naturally needs to be profitable.
In fact I'm surprised so many people find Docker Inc. developing a "platform" around Docker a change of direction, let alone unexpected.
It's nothing new and in fact I feel like Docker Inc choice is the "right" one: historically Commercial Open Source companies have had only a handful of choices to monetise: 1) selling support and services around the open source product, 2) going Open Core, 3) developing orthogonal, complementary commercial products around the main open source one and 4) be acquired :-D
RedHat is really the only one that managed to make option 1 work at scale and it looks like a black swan the longer time goes by. Option 2 was a bad idea to begin with a few years ago and I'm still surprised there are companies going for it today (I experienced it on my own skin). Option 4 is what it is.
So Option 3 is really the only reasonable way to go: keep the open source product really open source and make money with complementary products. I kind of expected this to be the way to go for Docker Inc all along, with a little niggle at the back of my mind fearing they would go for Open Core instead.
Examples:
* The docker hub gets special privileges in the image namespace. It isn't built on DNS but instead rooted in a namespace owned by Docker, Inc.
* The newly announced swarm depends on a discovery endpoint that (as far as I've seen) is closed source and undocumented.
I'd love to see the online parts of the OSS docker project have the same "firewall" as Solomon believe he holds for the OSS components.
The reason more people aren't paying for private indexes at this point is because the service is still slow and unreliable, and the UI needs serious work. With their current funding levels, fixing those items shouldn't be a problem. For comparison, Quay.io was able to do it with just a few engineers.
They're just being greedy and overreaching at this point.
To me, that actually shows that you don't have to rely on Docker Inc online services and are free to choose other options (that perhaps are better?)
1) Money is definitely not the case - docker is well capitalized. A special benefit of being in that situation is you don't have to do unnatural things like partner for money.
2) We welcome contributions from everyone, partners or not. Influence is gained by real contribution.
The reason we build partnerships is to ensure a few main things
#1 (and the biggest) Docker is made available on a wide variety of platforms, allowing developers and admins to work in native environments instead of fork-lifting to another just to try it out.
#2 Enable a network of services, products, systems integrator, IT vendors, etc. to have support, training, and other necessary things as they offer docker features in their products. This allows those who do not make containers and container services the core of their business, and instead focus on making/solving different problems.
I am more than happy to walk you or anyone else through partner strategy at any time. I'm easy to find.
Are you willing to share the contract details involved in these partner agreements? What do partners have to agree to in order to be an official partner?
Of course I can't do that, but I can talk about the different contract types thematically in an appropriate forum, absolutely.
> What do partners have to agree to in order to be an official partner?
1) Not to fork the Docker project (in the negative context, i.e use Docker but call it something else) 2) To use the Docker API (and not a derivative implementation)
As a general, official technology partner, that's pretty much it. And, most of the time, we're more than happy to promote (especially smaller partners) to that status in good faith without any paper work.
> What about prioritization, you may ask?
The list I provided above in terms of recruitment/opportunity criteria? That's prioritized.
My team has to prioritize the tremendous interest from some of the largest as well as some of the smallest companies in the world
A guiding principle is that special attention paid to those who make a commitment (and have shown ) to contribute their learning upstream - either via code contribution, proposal, activity on IRC, etc. I/we spend a tremendous amount of time on all of the feedback channels (like this one) to know who is active and from there form a relationship. If you follow my activity on any of these forums, you'll probably see a lot of "hey what you're doing is awesome. lets chat more" That's usually how it starts.
I hope that helps, and my inbox/calendar/time is always open for a conversation. If this is interesting to you or others, I'm a pretty open book. Don't hesitate.
github.com/docker/machine github.com/docker/swarm
Each one is implemented with a “batteries included, but
removable” approach which, thanks to our orchestration
APIs, means they may be swapped-out for alternative
implementations from ecosystem partners designed for
particular use cases.
Just 'cause it's open-source doesn't mean there aren't any politics involved in what gets merged or not.
An example:
lmctfy support was added by the Google GCE team a long long time ago and I attended a meetup where the GCE team submitted the pull request right there... it was never merged. Languished for months without any public review comments from Docker maintainers.
I'd never seen anything like this before. Here we have Google engineers integrating their work with Docker on their own time and being completely ignored. Embarrassing is a nice way to put it.
There may have been outside discussions and real issues that made merging a bad idea, but as an OSS project I expect those discussions to happen in the pull request, not in some business meeting. I'm sure any technical issues would have been addressed if there had been any. I'm also sure that the GCE team would have been more than happy to maintain their driver. Politics and open-source are a happy mix.
sources:
https://github.com/docker/docker/pull/4891
https://github.com/docker/docker/issues/4874Yeah, and Eric Brewer got on stage at DockerCon June and stated that pretty publicly. So your instinct was right.
I'm not able to find any details that support what you're saying. It seems that in June Eric Brewer was still publicly asking for libcontainer to merge in LMCTFY support.
I definitely could be wrong, but looking at this screenshot from Eric's June talk it looks like they were still trying to get it merged:
https://pbs.twimg.com/media/B4DKb51CYAA687s.jpg:large
In June, Eric Brewer posted this:
We’ve released an open-source tool called cAdvisor that
enables fine-grain statistics on resource usage for containers.
It tracks both instantaneous and historical stats for a wide
variety of resources, handles nested containers, and supports
both LMCTFY and Docker’s libcontainer. It’s written in Go with
the hope that we can move some of these tools into libcontainer
directly if people find them useful (as we have).
That's just Compose, though. The other two are completely different beasts.
EDIT -- link to compose proposal https://github.com/docker/docker/issues/9459
Users can either launch a Docker image as a Task, or as an Executor. The Docker Containerizer is translating Task/Executor Launch and Destroy calls to Docker CLI commands.
If that is being filled by Ansible for you today, fantastic !
What other parts would you like to see?
Look at Microsoft for Windows and HyperV, Joyent for SmartOS.