Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Announcing Docker 1.9: Production-Ready Swarm and Multi-Host Networking

blog.docker.com

Post reply on HN
Print view View original

71–80 of 80 posts

Re: Announcing Docker 1.9: Production-Ready Swarm and Multi-Host Networking

#71

Post by sytse »

ihsw wrote: post #23
sytse wrote: post #16

What is the difference between Compose, Swarm, Tutum and Kubernetes? To me looks like you can use each of them to compose a set of containers to run an app.

The Docker command is used for working with one image. When working with multiple images, coordinating ports, volumes, environment variables, links, and other things gets very troublesome very quickly as you get into using a mish-mash of deployment and management scripts. Compose aims to solve this problem by declaratively defining ports, volumes, links, and other things. Compose does allow you to scale up and down e…

Thanks, that was helpful.

Re: Announcing Docker 1.9: Production-Ready Swarm and Multi-Host Networking

#72

Post by cpuguy83 »

tachion wrote: post #54

Congratulations on new release! Sadly, still without FreeBSD Jails support, that was sort-of promised around 1.0...

I'm not sure the completeness of the support as I don't run BSD, but I know it's being worked on and at least compiles on BSD. There's actually quite a bit of BSD-only code in.

Re: Announcing Docker 1.9: Production-Ready Swarm and Multi-Host Networking

#73

Post by wstrange »

lobster_johnson wrote: post #28
sytse wrote: post #16

What is the difference between Compose, Swarm, Tutum and Kubernetes? To me looks like you can use each of them to compose a set of containers to run an app.

Swarm and Kubernetes are definitely competitors. Swarm is a container manager that automatically starts and stops containers in a cluster using a scheduling algorithm. It implements the Docker API, so it actually acts as a facade that aggregates all the hosts in the pool. So you talk to it just like you would with a single-host Docker install, but when you tell Swarm to start a given container, it will schedule it so…

I think it worth mentioning that setting up networking in Kubernetes is largely a problem for deployers - not so much k8 users.

There are a variety of hosted, virtualized and bare metal solutions available.

The CoreOS folks have some nice all-in-one VMs if you want to experiment.

Google's hosted Container engine is about as simple as it gets - and very inexpensive (I have been playing with it for a few weeks and have spent about $20).

Re: Announcing Docker 1.9: Production-Ready Swarm and Multi-Host Networking

#74

Post by nzoschke »

olalonde wrote: post #41
dcosson wrote: post #36

I don't quite understand the swarm & compose workflow for production. I'd rather use a declarative language to specify what the systems look like, potentially with auto-scaling, health checks to replace containers if they go down, etc. I don't want to run one-off commands to launch containers based on local instead of centrally stored configuration, run one-off commands to launch the underlying hosts and to scale to…

Swarm & compose are pretty low level and not sufficient for production deployments in my experience. In production, you usually need things like logging/monitoring, versioning/rollbacks, scaling, configuration/user management, load balancing, etc. which you either have to setup yourself or get through a PaaS. I personally recommend Deis because it's Docker/CoreOS based (lightweight) and its developers are very active…

You're absolutely right about still needing logging, scaling, configuration management and load balancing.

Me and a team are working on another open-source project, Convox, that offers this on AWS.

One differentiator is that we use "pure" AWS for everything.

Load balancing comes from configuring ECS and an ELB the right way. Logging is based on Kinesis and Lambda. We're seeing great reliability and manageability with this approach.

http://convox.com/

Re: Announcing Docker 1.9: Production-Ready Swarm and Multi-Host Networking

#75

Post by nzoschke »

silversmith wrote: post #43

On topic of docker and multi-container, multi-machine orchestration... Is there a comprehensive "docker deployment for dummies" guide out there? For example, let's say I have couple web applications with their dockerfiles ready, a database and a redis instance on software side, and then couple server instances for it all to run on. Where do I go from there? What's the best process to package everything up and get it…

If you're comfortable deploying to AWS, I'm building an open source and free platform, Convox, that addresses your setup and deployment questions.

Here are a couple guides that walk you through your first Docker cloud deployment:

http://convox.github.io/docs/getting-started/ http://convox.github.io/docs/getting-started-with-docker/

This gives you a private build and registry service that are secured in your own VPC and accessable only through authenticated API calls.

The software that sets this all up is open source and free, but you do pay for your AWS usage (EC2, ELB and S3).

Servers know how to fetch the new version by issuing one `release` command that triggers zero-downtown rollout on the EC2 Container Service (ECS).

Re: Announcing Docker 1.9: Production-Ready Swarm and Multi-Host Networking

#76

Post by takeda »

merb wrote: post #50

Docker more and more gets into a direction which i don't like. EDIT the missing content..: I mean currently it mostly is for the big users. There aren't too much things for "small" users. The big things like kubernetes, etc are really hard to configure / maintain, etc. I mean it's easier to maintain ansible / puppet / chef / etc... - scripts than maintaining a real "docker" environment. even looking at deis, flynn, o…

I think at this moment docker does looks cool, but doesn't provide much value at this time. Some people are using it just for packaging their apps, but that's something that was already solved or supposed to be solved by the language that is used.

The direction where it is going is to create an "internet operating system" you upload your application and don't care on which server it is running.

Currently that above problem has not been solved yet, and what we have is just bunch of tools to put them together and DIY.

The real power of this will come, once cloud providers will allow you to simply upload the images without having to build that infrastructure yourself.

I think you're right to fall back to ansible / puppet / chef, because this technology is simply not ready yet.

This is especially true if you're using public cloud (and while you can make it work in AWS, it will cost you more; both due to amount of effort, but also due to overhead imposed by it. Remember, AWS still charges you by VM).

There might be some benefits of using it right now when you have your own datacenter with physical machines. It could provide costs savings, compared to running your apps on dedicated physical servers or even using VMs.

Re: Announcing Docker 1.9: Production-Ready Swarm and Multi-Host Networking

#77

Post by nzoschke »

amalag wrote: post #15

I am really trying to figure out the ecosystem. I did some stuff with a single server but now as we need to move it to multiple servers we have Rancher, Weave, and so many others (kubernetes?). And now docker has integrated multihost networking so I am really not sure how to proceed.

The ecosystem is changing so rapidly right now.

One answer is to stick with whatever AWS offers. The EC2 Container Service (ECS) offers a practical solution to running your app as containers on a cluster of multiple servers without adding any other software for orchestration.

It has a lot of deficiencies, but these are solved with other AWS services. For example you still use an ELB for load balancing across your servers and containers.

The rest of the ecosystem is pushing for a more radical container future that doesn't rely on AWS.

Joyent has a true "container-native" infrastructure with Triton. You can run your app as multiple containers without considering anything about servers.

Tutum (recently acquired by Docker) operates the same way. I'm excited to see what this platform offers if it evolves in lockstep with Docker core for networking, logging and data.

Kubernetes and Swarm are projects that solve the low level challenges of orchestrating containers in a cluster. But you almost certainly need to build a lot more around these systems to get logs, load balancing, etc.

Re: Announcing Docker 1.9: Production-Ready Swarm and Multi-Host Networking

#78

Post by picozeta »

picozeta wrote: post #7
TheMakeA wrote: post #5

Does anyone know if Docker Toolbox supports NFS (or something faster than VBox Shared Folders) yet?

Couldn't you use ssh and build something with sshfs?

May I ask, why this was downvoted? Isn't the idea of vbox's shared folders to provide a convenient data exchange with the host OS? If one puts ssh into the docker container, the host may mount a container's directory into its tree.

Re: Announcing Docker 1.9: Production-Ready Swarm and Multi-Host Networking

#79

Post by voltagex_ »

merb wrote: post #57
voltagex_ wrote: post #53

Earlier quoted context omitted.

docker-compose and tmux and runit works.

so how is docker helping you? I mean tmux and runit are really good without docker and docker just gives a few things, like process isolation. (which you could also have with cgroups and other container technologies which probably working better with runit)

Ability to reproduce a build environment - and have others do it. I can spend time working out what dependencies are needed on various distros, or I can ship a Dockerfile in my Git repo.

Re: Announcing Docker 1.9: Production-Ready Swarm and Multi-Host Networking

#80

Post by robhaswell »

thedevopsguy wrote: post #60
jschorr wrote: post #46

Earlier quoted context omitted.

This space is still (fairly) new, so the general answer seems to be that there are multiple solutions to each problem, some that work well with others and some that do not. For orchestration, offhand the most active projects seem to be Kubernetes [1], Swarm [2], Deis [3] and Mesos[4]. Kubernetes is built primarily by Google, Swarm by Docker and Deis by EngineYard, with each team having experience in different areas (…

The docker ecosystem is hard to follow. Like you've just mentioned there are multiple solution to each problem. Docker based solutions for orchestration(Swarm), storage (v1.9) and networking (v1.9) overlap with the offerings from Kubernetes,Mesos, Flocker and whole bunch of others. It's hard to know whether to wait for Docker to provide a solution or to use something that already has momentum. Take networking for exa…

My advice would be to think hard about your requirements and pick something which meets them. Don't fret about the "best" solution - you and your team have more important problems to solve. If something works for you then you have made the right choice. All the solutions you would pick today will still be around tomorrow.
Post reply on HN