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?
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.
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.
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...
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).
> 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.
- 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...
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.
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...
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.
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?
"""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."""
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.
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.
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.
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.
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?
In fact they announced a partnership with Mesosphere that will swap Swarm out and replace it with Mesos as an example.
github.com/docker/machine github.com/docker/swarm
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.
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.
What other parts would you like to see?
Look at Microsoft for Windows and HyperV, Joyent for SmartOS.
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?
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/4874There'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.
That's just Compose, though. The other two are completely different beasts.
EDIT -- link to compose proposal https://github.com/docker/docker/issues/9459
If that is being filled by Ansible for you today, fantastic !
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
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.