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

61–70 of 80 posts

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

#61

Post by ownagefool »

merb wrote: post #56
ed_blackburn wrote: post #55

Earlier quoted context omitted.

Certainly. There's an excellent opportunity there if someone is willing to execute. Would you (the community) pay for a product? Or support an open source project through consultancy? Or are we going to sit and wait for a large engineering organisation to build it internally and open source?

i would pay, yes. however it would need to be a excellent product. and I don't think that any product the near term could replace a existing ansible/puppet/etc... workflow which contains a bunch of lines (less then 1000 for multiple projects). as said the only thing gain for docker would be process isolation, so it should be really really awkward simple and useful on low end hardware. (as the other solution already d…

Installing kubernetes isn't actually as difficult as you've made it out to be. You'd be able to draft a workflow in less effort in comparable circumstances using puppet and you'll get things such as health checking and failover of your apps for mostly free.

If you're well invested in puppet, using puppet is going to be easier because you know it. You can happily use docker with puppet. Stop puppet from installing $APP and instead use it to docker pull && docker run $APP.

This means the logic for building your application has obviously moved to the Dockerfile. You cannot currently get rid of this logic, only hide it in abstractions. I prefer it living in the apps repo as it's a nice seperation of concerns, but you obviously would prefer it to be magic, which you can have but at the price of versatility.

If you are able write code to build and deploy apps, then moving over to using docker should be pretty trivial for you. However, I actually see docker as a replaceable part, whilst kubernetes might actually be here to stay.

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

#62

Post by rdsubhas »

merb wrote: post #56
ed_blackburn wrote: post #55

Earlier quoted context omitted.

Certainly. There's an excellent opportunity there if someone is willing to execute. Would you (the community) pay for a product? Or support an open source project through consultancy? Or are we going to sit and wait for a large engineering organisation to build it internally and open source?

i would pay, yes. however it would need to be a excellent product. and I don't think that any product the near term could replace a existing ansible/puppet/etc... workflow which contains a bunch of lines (less then 1000 for multiple projects). as said the only thing gain for docker would be process isolation, so it should be really really awkward simple and useful on low end hardware. (as the other solution already d…

* you need network isolation as well. no point in doing process isolation without it. and thus forwarded ports.

* shared folders to persist necessary files. and thus volumes. and a few years later distributed volumes.

* not just isolate a process, but all its dependencies as well. no point in having a shared .so file which everybody can change, while just a single process is isolated. and thus a whole sandboxed container.

* and then deal with the size of a full sandbox, until you need some way to share unchanged files. and thus images and layers.

* and so on and so on.

big things always start small. at least in docker's case they did start small, and they're still small and lean individual projects. feel free not to use docker compose or anything else.

edit: formatting

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

#63

Post by zwischenzug »

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…

Try writing a book on it! Maddening.

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

#64

Post by jacques_chester »

DannoHung wrote: post #34
jacques_chester wrote: post #20

Earlier quoted context omitted.

I'm biased: use a full PaaS. I like Cloud Foundry because I've worked on it. OpenShift is another alternative.

Pretty sure openshift v3 is built on top of kubernetes

And Cloud Foundry can run Docker containers.

The point is that both are platforms. Application developers shouldn't really need to care about the internals of a PaaS, for the same reason that I don't really care about the internals of the Linux kernel.

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

#65

Post by jacques_chester »

olalonde wrote: post #40
jacques_chester wrote: post #20

Earlier quoted context omitted.

I'm biased: use a full PaaS. I like Cloud Foundry because I've worked on it. OpenShift is another alternative.

I've been using Deis ( http://deis.io/ ) which is built on top of Docker and inspired by Heroku. I think it's a bit more "lightweight" than Cloud Foundry but really pleased so far. I had a few issues but the Deis team was always quick to help and fix bugs.

If you want a lightweight Cloud Foundry, try Lattice[0]. It's specifically intended to allow developers to experiment with the core Cloud Foundry components (routing, scheduling/placement and log draining) with very low overhead.

[0] http://lattice.cf/

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

#66

Post by jacques_chester »

merb wrote: post #56
ed_blackburn wrote: post #55

Earlier quoted context omitted.

Certainly. There's an excellent opportunity there if someone is willing to execute. Would you (the community) pay for a product? Or support an open source project through consultancy? Or are we going to sit and wait for a large engineering organisation to build it internally and open source?

i would pay, yes. however it would need to be a excellent product. and I don't think that any product the near term could replace a existing ansible/puppet/etc... workflow which contains a bunch of lines (less then 1000 for multiple projects). as said the only thing gain for docker would be process isolation, so it should be really really awkward simple and useful on low end hardware. (as the other solution already d…

You're describing a PaaS. There are already several.

My favourite is Cloud Foundry, because I've worked on it and I trust the way it's built.

Here's how I deploy an app:

    cf push
Done.

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

#67

Post by bboreham »

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…

> If so, that's probably the simplest overlay solution of all the aforementioned

(I work on Weave)

Weave Net also lets you create a Docker overlay network using VXLAN, without insisting that you configure a distributed KV store (etcd, consul, etc.). So I would argue Weave Net is the simplest :-)

More detail here: http://blog.weave.works/2015/11/03/docker-networking-1-9-wea...

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

#68

Post by cpuguy83 »

m_mueller wrote: post #37
cpuguy83 wrote: post #12

Earlier quoted context omitted.

Hipache is a reverse proxy, swarm is for managing/scheduling a cluster of docker engines.

Well, when I think of a cluster I think of load balancing and failover - for which you can use a reverse proxy such as Hipache. So I don't quite understand how this is not related. The way I understand Swarm, it could be just a higher level abstraction built on top of that?

Load balancing and failover are generally a requirement in clustered environments, but are really different jobs. LB's "schedule" connection requests, cluster schedulers schedule the things that those connections are going to (and probably the LB), makes sure they are up and running, etc.

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

#70

Post by flurdy »

Estragon wrote: post #35
mikegcoleman wrote: post #21

Earlier quoted context omitted.

I won't comment on Kubernetes because I'm not qualified to do so. Compose: Multi-container orchestration. You define an application stack via a compose file including links between containers (web front end links to a database). When you run docker compose up on that file, compose stands up the containers in the right order to deal with dependencies. Swarm: Represents a cluster of Docker Hosts as a single entity. Wil…

If tutum is primarily a gui on top of a bunch of open source products, it doesn't sound like much of a business plan.

It worked well enough to be acquired by Docker :)
Post reply on HN