13 ms·

Announcing Docker Machine, Swarm, and Compose for Orchestrating Distributed Apps

370 points by KenCochrane 12y ago

preillyme 12y ago
Mesos 0.20.0 adds the support for launching tasks that contains Docker images, with also a subset of Docker options supported while we plan on adding more in the future. 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.
skrebbel 12y ago
Can anyone who understands this better than I do explain whether this replaces Fig, and if so, which parts of it?
- shingler 12y ago
  Yes, and all of it. It's largely the same thing, in Docker core. That's just Compose, though. The other two are completely different beasts.
  - bfirsh 12y ago
    It's also worth pointing out that Compose is a proposal for a new feature to Docker. If you don't think the design is right, make your voice heard. :) https://github.com/docker/docker/issues/9459 https://github.com/docker/docker/issues/9459
  - deleted 12y ago
    [deleted]
geerlingguy 12y ago
I think this sheds a little more light on the reasons CoreOS decided to start building the Rocket container runtime[1], and not tie it's destiny to being paired with Docker. [1] https://coreos.com/blog/rocket/ https://coreos.com/blog/rocket/
gtaylor 12y ago
I'm excited to see Docker continue to progress so quickly, but I'll admit to being more and more confused over how many components and services you have to contend with now. I'm sure I could sort out all of these names if I spent more time playing, but it's getting a little confusing to me. 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.
- thaJeztah 12y ago
  > confused over how many components and services you have to contend with now 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.
  - gtaylor 12y ago
    > 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.
    - IanCal 12y ago
lclarkmichalek 12y ago
Pretty amazing. Is there anything the docker binary doesn't do now? The comparisons with systemd (I like systemd) are becoming more apt.
- cpuguy83 12y ago
  swarm and machine are separate binaries. Compose is still a proposal. EDIT -- link to compose proposal https://github.com/docker/docker/issues/9459 https://github.com/docker/docker/issues/9459
bfirsh 12y ago
GitHub repo for Machine: https://github.com/docker/machine https://github.com/docker/machine GitHub repo for Swarm: https://github.com/docker/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 https://github.com/docker/docker/issues/9459
dmritard96 12y ago
This is all cool, but I really am I excited for better ARM support one day...
- nickstinemates 12y ago
  Let's work on a proposal with an initial pov to make it happen. It won't come unless someone steps up to build it. Look at Microsoft for Windows and HyperV, Joyent for SmartOS.
  - alexandros 12y ago
    Hi Nick, I'd love to get more info on how to get this conversation started. We've been doing quite a bit with Docker on ARM for a while now, have experience with systems in production, and we're even making early research into MIPS.
    - nickstinemates 12y ago
      That's really great. I'd love to hear more about it. I'll send you an email.
- alexandros 12y ago
  The Raspberry Pi installation you get at Resin.io uses Docker on ARM and it works great! We also cross-compile containers in the cloud. Docker for ARM standalone is now available in several Linux Distro repos, Arch Linux is one I am aware of. What other parts would you like to see?
  - dmritard96 12y ago
    have used the resin.io docker images on arch on my pi. What I would love is a raspbian version as its just a super popular distro on raspi. I know its a bit of gridlock right now. It seems that its going into the jesse version of debian but the raspbian release of jesse isn't out the last time a checked (a couple weeks ago). I did try out lessbian - awesome name - on raspi and I am not recalling specifically why it didn't work out for me. I had some issue with the filesystem dependencies not being there and getting them was a pretty large undertaking (so much so that it would have been just as easy to do it on raspbian). Would love to contrib myself but right now i'm swamped and don't really have much expertise in either docker or arm. At least my experience should bring some clarity/insight into what I encountered.
scanr 12y ago
The 2 examples in Docker Swarm were Redis and MySQL. 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.
- cpuguy83 12y ago
  I believe to start off with, anything with volumes won't be moved... at least this was what was said during the POC demo given for hack day last month.
- HorizonXP 12y ago
  I'd like to see a reasonable answer to this. Because up until now, I've been using data-only containers to mount directories into these app containers (i.e. Redis and PostgreSQL). The fail over handling has been horrendous for me, because there's no easy way to migrate the data across machines, unless you setup multiple hot slaves or something. And this happens often with CoreOS updates on the alpha channel. 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.
  - lclarkmichalek 12y ago
    So kube doesn't have this atm, but is looking at introducing some kind of support with a forgiveness based system, along with hooks for services that require data migrations: https://github.com/GoogleCloudPlatform/kubernetes/issues/598 https://github.com/GoogleCloudPlatform/kubernetes/issues/598
  - 12y ago
saryant 12y ago
I'm excited to watch this battle between CoreOS and Docker heat up. I recently took a CoreOS/Docker-based system into production on AWS and there are definitely still some missing pieces. Swarm appears to be a slightly higher-level version of fleetd. Compose is something CoreOS is missing though.
- lclarkmichalek 12y ago
  Compose seems to be coming straight out of Kubenetes' pod design, which the CoreOS people have quite a stake in.
chuhnk 12y ago
I'm a little bit afraid about the fragmentation occurring in the container world right now. I felt like in the beginning I could rely on Docker being focused on containers and really making that a stable building block and utilise tools around that provided by industry leaders. Now Docker have thrown their own hat in the ring, creating a monopoly for themselves. Do you choose docker and their whole ecosystem? Do you pick something else off the shelve? How about Amazon ECS container service, CoreOS with their array of tools. 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.
- SEJeff 12y ago
  My bet is on Redhat's project atomic, which uses Kubernetes under the hood and will eventually support Mesos for scheduling (via kubernetes).
  - chuhnk 12y ago
    I think what Redhat is doing with Atomic and OpenShift is really great. They are building some awesome stuff around Kubernetes however I feel like that is going to be entirely geared towards the enterprise space. Much like OpenStack it's very complicated and the barrier to entry is still quite high. When I looked at the docs I immediately had to go look at reference info for all this new terminology they had introduced. They'd basically ignored what had come out of industry usage and naming. But in saying that, I do hope they cause massive shifts in the enterprise game. 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.
23david 12y ago
These aren't new projects... just rebranded versions of half-baked feature proposals that I thought were still being reviewed/discussed. I guess somewhere a decision was made to move forward regardless of community concerns? 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.
- bfirsh 12y ago
  Both Machine and Swarm are not baked into Docker – they are separate projects and binaries: https://github.com/docker/machine https://github.com/docker/machine https://github.com/docker/swarm 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 https://github.com/docker/docker/issues/9459
  - 23david 12y ago
    Docker Machine looks to be a revision/rebrand of your docker hosts proposal made in the last 1-2 days or so. Very confusing. The proposal discussion: https://github.com/docker/docker/issues/8681 https://github.com/docker/docker/issues/8681 Rename "docker hosts" to "docker machines": https://github.com/bfirsh/docker/commit/e6abec4033f48d1cad31380f3c94da137b64ae74 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." 1 day ago, a message from tianon, core Docker maintainer: Has there been any progress on splitting the actual driver implementations out of the core binary? And now this. Color me confused.
    - 12y ago
themgt 12y ago
I think the community really ought to take a good minute to consider, beyond technical reasons, whether it really makes sense to so tightly tie the future of computing to a single for-profit company's quickly enlarging platform. 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.
- numair 12y ago
  Docker's overreach seems to resemble the overreach of Joyent in the io.js world. It's really hard to regain trust and momentum once the community starts to question you; in economic terms this would be termed as "a spike in transaction costs." If I were Docker, my next project would be a meetup/presentation/etc explaining how my new initiatives are for the benefit of the community, rather than just self-serving wheel reinvention. This isn't a consumer-facing business; the opinions of concerned developers can make or break them.
  - Alupis 12y ago
    > my next project would be a meetup/presentation/etc explaining how my new initiatives... 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).
23david 12y ago
They sound like a closed-source vendor at this point. I'm surprised to see an open-source project mention "ecosystem partners": 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. So if I have a startup working on an orchestration solution, what is the process to become an approved 'ecosystem partner'. Do I need to sign a NDA and pay for an approval process to get my stuff merged in?
- shykes 12y ago
  How about sending a pull request on github/docker/swarm or github.com/docker/machine
- potto 12y ago
  Why would you have to sign a NDA to create an open source ecosystem around an open source project with an Apache 2.0 license?
  - 23david 12y ago
    Not sure. Never heard of an official partnership program either, so I'm interested to know details about how this partnership program works. Could be innocent, but something about it smells like a OSS shakedown to me. 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/4874
shykes 12y ago
Hi all. A few clarifications. - 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.
- potto 12y ago
  While it is scary when a company takes its initial success in the technology scene and uses it to expand into its verticals, this is not quite the same case as the Microsoft analogy...Docker is open source, after all. I think the backlash that CoreOS started with its Rocket / AppContainer announcement ahead of DockerCon has caused some knee-jerk reactions. 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
dingdingdang 12y ago
With this amount of buzz words needed to install and run an app I see a bright future for Go and its "all compiled in one, web-server included, ready to go" executable structure. I mean sure: you get automation and repeatability of installs but at what cost? You have to maintain all the buzz-word hoops that your app needs to be wrapped into - requiring what amounts to a full new job in medium sized software company. And you still need the sysadmin to actually make the servers work.
RemoteWorker 12y ago
I haven't been reading Docker related news lately. Is there anything I should know if I already have my own working continuous deployment system made with Ansible, Jenkins and Docker? For example, it seems like I don't need Docker Machine if I already have my own Ansible recipes for provisioning.
- nickstinemates 12y ago
  If it's already working and you're happy, awesome. Machine is just a convenient way to provision new Docker hosts, in a separate project/binary. If that is being filled by Ansible for you today, fantastic !
deeviant 12y ago
Begun, these docker wars have.
fndrplayer13 12y ago
Maybe I'm just thick in the head, but one of the thing that continues to disappoint me about Docker is the size of the binaries. Wouldn't it be good if we could build the container a single time, and then ship that top-level changeset around? For example. If I build a 200mb binary on top of `ubuntu:latest` I would like to be able to just ship that 200mb around, instead of 200mb + ubuntu:latest (another ~167mb?). If you colocate many services in a single machine (say 10-12) the network of grabbing those tarballs makes Docker less appealing. 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?
- xnxn 12y ago
  The idea is that you build the image and push it to a registry. The service hosts then only pull the layers they don't already have. 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.
  - nickstinemates 12y ago
    Specifically about filesets - take a look at the docker import command. It will take an arbitrary rootfs (tar file) and turn it in to a docker image.
    - bmurphy1976 12y ago
      I've been down this path, far down this path. 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).
slifin 12y ago
Talking about Docker as we are 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
- cdoxsey 12y ago
  Completely agree. You can do something like this: 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?
  - Gigablah 12y ago
    In regards to (3), you don't... people have made functional containers with the scratch or busybox images that are less than 10mb in size.
endymi0n 12y ago
Wonderful. We just containerized all of our apps and are in the process of choosing our approach for running and deploying them in a cluster. 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)
- cgswong 12y ago
  We are in a similar position as yourself and share your opinion. What we are essentially doing is: 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.
- borjaburgos 12y ago
  I'd invite you to check out http://tutum.co http://tutum.co , but then again, I'm one of the cofounders, so I'm 100% biased. Take my invitation with a grain of salt. Feedback welcomed. Cheers,
  - thomasfromcdnjs 12y ago
    Was reading this earlier and saw your comment. A few hours later while Googling you came up number one in results =D Giving it a shot now.
- 12y ago

370 points by KenCochrane 12y ago

Mesos 0.20.0 adds the support for launching tasks that contains Docker images, with also a subset of Docker options supported while we plan on adding more in the future. 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.

skrebbel 12y ago

Can anyone who understands this better than I do explain whether this replaces Fig, and if so, which parts of it?

shingler 12y ago
Yes, and all of it. It's largely the same thing, in Docker core. That's just Compose, though. The other two are completely different beasts.
- bfirsh 12y ago
  It's also worth pointing out that Compose is a proposal for a new feature to Docker. If you don't think the design is right, make your voice heard. :) https://github.com/docker/docker/issues/9459 https://github.com/docker/docker/issues/9459
- deleted 12y ago
  [deleted]

geerlingguy 12y ago

I think this sheds a little more light on the reasons CoreOS decided to start building the Rocket container runtime[1], and not tie it's destiny to being paired with Docker. [1] https://coreos.com/blog/rocket/ https://coreos.com/blog/rocket/

gtaylor 12y ago

I'm excited to see Docker continue to progress so quickly, but I'll admit to being more and more confused over how many components and services you have to contend with now. I'm sure I could sort out all of these names if I spent more time playing, but it's getting a little confusing to me. 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.

thaJeztah 12y ago
> confused over how many components and services you have to contend with now 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.
- gtaylor 12y ago
  > 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.
  - IanCal 12y ago

lclarkmichalek 12y ago

Pretty amazing. Is there anything the docker binary doesn't do now? The comparisons with systemd (I like systemd) are becoming more apt.

cpuguy83 12y ago
swarm and machine are separate binaries. Compose is still a proposal. EDIT -- link to compose proposal https://github.com/docker/docker/issues/9459 https://github.com/docker/docker/issues/9459

bfirsh 12y ago

GitHub repo for Machine: https://github.com/docker/machine https://github.com/docker/machine GitHub repo for Swarm: https://github.com/docker/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 https://github.com/docker/docker/issues/9459

dmritard96 12y ago

This is all cool, but I really am I excited for better ARM support one day...

nickstinemates 12y ago
Let's work on a proposal with an initial pov to make it happen. It won't come unless someone steps up to build it. Look at Microsoft for Windows and HyperV, Joyent for SmartOS.
- alexandros 12y ago
  Hi Nick, I'd love to get more info on how to get this conversation started. We've been doing quite a bit with Docker on ARM for a while now, have experience with systems in production, and we're even making early research into MIPS.
  - nickstinemates 12y ago
    That's really great. I'd love to hear more about it. I'll send you an email.
alexandros 12y ago
The Raspberry Pi installation you get at Resin.io uses Docker on ARM and it works great! We also cross-compile containers in the cloud. Docker for ARM standalone is now available in several Linux Distro repos, Arch Linux is one I am aware of. What other parts would you like to see?
- dmritard96 12y ago
  have used the resin.io docker images on arch on my pi. What I would love is a raspbian version as its just a super popular distro on raspi. I know its a bit of gridlock right now. It seems that its going into the jesse version of debian but the raspbian release of jesse isn't out the last time a checked (a couple weeks ago). I did try out lessbian - awesome name - on raspi and I am not recalling specifically why it didn't work out for me. I had some issue with the filesystem dependencies not being there and getting them was a pretty large undertaking (so much so that it would have been just as easy to do it on raspbian). Would love to contrib myself but right now i'm swamped and don't really have much expertise in either docker or arm. At least my experience should bring some clarity/insight into what I encountered.

scanr 12y ago

The 2 examples in Docker Swarm were Redis and MySQL. 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.

cpuguy83 12y ago
I believe to start off with, anything with volumes won't be moved... at least this was what was said during the POC demo given for hack day last month.
HorizonXP 12y ago
I'd like to see a reasonable answer to this. Because up until now, I've been using data-only containers to mount directories into these app containers (i.e. Redis and PostgreSQL). The fail over handling has been horrendous for me, because there's no easy way to migrate the data across machines, unless you setup multiple hot slaves or something. And this happens often with CoreOS updates on the alpha channel. 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.
- lclarkmichalek 12y ago
  So kube doesn't have this atm, but is looking at introducing some kind of support with a forgiveness based system, along with hooks for services that require data migrations: https://github.com/GoogleCloudPlatform/kubernetes/issues/598 https://github.com/GoogleCloudPlatform/kubernetes/issues/598
- 12y ago

saryant 12y ago

I'm excited to watch this battle between CoreOS and Docker heat up. I recently took a CoreOS/Docker-based system into production on AWS and there are definitely still some missing pieces. Swarm appears to be a slightly higher-level version of fleetd. Compose is something CoreOS is missing though.

lclarkmichalek 12y ago
Compose seems to be coming straight out of Kubenetes' pod design, which the CoreOS people have quite a stake in.

chuhnk 12y ago

I'm a little bit afraid about the fragmentation occurring in the container world right now. I felt like in the beginning I could rely on Docker being focused on containers and really making that a stable building block and utilise tools around that provided by industry leaders. Now Docker have thrown their own hat in the ring, creating a monopoly for themselves. Do you choose docker and their whole ecosystem? Do you pick something else off the shelve? How about Amazon ECS container service, CoreOS with their array of tools. 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.

SEJeff 12y ago
My bet is on Redhat's project atomic, which uses Kubernetes under the hood and will eventually support Mesos for scheduling (via kubernetes).
- chuhnk 12y ago
  I think what Redhat is doing with Atomic and OpenShift is really great. They are building some awesome stuff around Kubernetes however I feel like that is going to be entirely geared towards the enterprise space. Much like OpenStack it's very complicated and the barrier to entry is still quite high. When I looked at the docs I immediately had to go look at reference info for all this new terminology they had introduced. They'd basically ignored what had come out of industry usage and naming. But in saying that, I do hope they cause massive shifts in the enterprise game. 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.

23david 12y ago

These aren't new projects... just rebranded versions of half-baked feature proposals that I thought were still being reviewed/discussed. I guess somewhere a decision was made to move forward regardless of community concerns? 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.

bfirsh 12y ago
Both Machine and Swarm are not baked into Docker – they are separate projects and binaries: https://github.com/docker/machine https://github.com/docker/machine https://github.com/docker/swarm 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 https://github.com/docker/docker/issues/9459
- 23david 12y ago
  Docker Machine looks to be a revision/rebrand of your docker hosts proposal made in the last 1-2 days or so. Very confusing. The proposal discussion: https://github.com/docker/docker/issues/8681 https://github.com/docker/docker/issues/8681 Rename "docker hosts" to "docker machines": https://github.com/bfirsh/docker/commit/e6abec4033f48d1cad31380f3c94da137b64ae74 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." 1 day ago, a message from tianon, core Docker maintainer: Has there been any progress on splitting the actual driver implementations out of the core binary? And now this. Color me confused.
  - 12y ago

themgt 12y ago

I think the community really ought to take a good minute to consider, beyond technical reasons, whether it really makes sense to so tightly tie the future of computing to a single for-profit company's quickly enlarging platform. 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.

numair 12y ago
Docker's overreach seems to resemble the overreach of Joyent in the io.js world. It's really hard to regain trust and momentum once the community starts to question you; in economic terms this would be termed as "a spike in transaction costs." If I were Docker, my next project would be a meetup/presentation/etc explaining how my new initiatives are for the benefit of the community, rather than just self-serving wheel reinvention. This isn't a consumer-facing business; the opinions of concerned developers can make or break them.
- Alupis 12y ago
  > my next project would be a meetup/presentation/etc explaining how my new initiatives... 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).

23david 12y ago

They sound like a closed-source vendor at this point. I'm surprised to see an open-source project mention "ecosystem partners": 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. So if I have a startup working on an orchestration solution, what is the process to become an approved 'ecosystem partner'. Do I need to sign a NDA and pay for an approval process to get my stuff merged in?

shykes 12y ago
How about sending a pull request on github/docker/swarm or github.com/docker/machine
potto 12y ago
Why would you have to sign a NDA to create an open source ecosystem around an open source project with an Apache 2.0 license?
- 23david 12y ago
  Not sure. Never heard of an official partnership program either, so I'm interested to know details about how this partnership program works. Could be innocent, but something about it smells like a OSS shakedown to me. 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/4874

shykes 12y ago

Hi all. A few clarifications. - 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.

potto 12y ago
While it is scary when a company takes its initial success in the technology scene and uses it to expand into its verticals, this is not quite the same case as the Microsoft analogy...Docker is open source, after all. I think the backlash that CoreOS started with its Rocket / AppContainer announcement ahead of DockerCon has caused some knee-jerk reactions. 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

dingdingdang 12y ago

With this amount of buzz words needed to install and run an app I see a bright future for Go and its "all compiled in one, web-server included, ready to go" executable structure. I mean sure: you get automation and repeatability of installs but at what cost? You have to maintain all the buzz-word hoops that your app needs to be wrapped into - requiring what amounts to a full new job in medium sized software company. And you still need the sysadmin to actually make the servers work.

RemoteWorker 12y ago

I haven't been reading Docker related news lately. Is there anything I should know if I already have my own working continuous deployment system made with Ansible, Jenkins and Docker? For example, it seems like I don't need Docker Machine if I already have my own Ansible recipes for provisioning.

nickstinemates 12y ago
If it's already working and you're happy, awesome. Machine is just a convenient way to provision new Docker hosts, in a separate project/binary. If that is being filled by Ansible for you today, fantastic !

deeviant 12y ago

Begun, these docker wars have.

fndrplayer13 12y ago

Maybe I'm just thick in the head, but one of the thing that continues to disappoint me about Docker is the size of the binaries. Wouldn't it be good if we could build the container a single time, and then ship that top-level changeset around? For example. If I build a 200mb binary on top of `ubuntu:latest` I would like to be able to just ship that 200mb around, instead of 200mb + ubuntu:latest (another ~167mb?). If you colocate many services in a single machine (say 10-12) the network of grabbing those tarballs makes Docker less appealing. 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?

xnxn 12y ago
The idea is that you build the image and push it to a registry. The service hosts then only pull the layers they don't already have. 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.
- nickstinemates 12y ago
  Specifically about filesets - take a look at the docker import command. It will take an arbitrary rootfs (tar file) and turn it in to a docker image.
  - bmurphy1976 12y ago
    I've been down this path, far down this path. 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).

slifin 12y ago

Talking about Docker as we are 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

cdoxsey 12y ago
Completely agree. You can do something like this: 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?
- Gigablah 12y ago
  In regards to (3), you don't... people have made functional containers with the scratch or busybox images that are less than 10mb in size.

endymi0n 12y ago

Wonderful. We just containerized all of our apps and are in the process of choosing our approach for running and deploying them in a cluster. 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)

cgswong 12y ago
We are in a similar position as yourself and share your opinion. What we are essentially doing is: 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.
borjaburgos 12y ago
I'd invite you to check out http://tutum.co http://tutum.co , but then again, I'm one of the cofounders, so I'm 100% biased. Take my invitation with a grain of salt. Feedback welcomed. Cheers,
- thomasfromcdnjs 12y ago
  Was reading this earlier and saw your comment. A few hours later while Googling you came up number one in results =D Giving it a shot now.
12y ago