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

51–60 of 80 posts

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

#51

Post by zwischenzug »

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…

I wouldn't call it comprehensive but I did this:

https://zwischenzugs.wordpress.com/2015/08/26/a-high-availab...

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

#52

Post by zwischenzug »

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

Yes: Docker, Kubernetes, and etcd

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

#53

Post by voltagex_ »

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…

docker-compose and tmux and runit works.

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

#55

Post by ed_blackburn »

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…

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?

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

#56

Post by merb »

ed_blackburn wrote: post #55
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…

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 does) and getting process isolation with cgroups isn't too hard on newer kernels. (# systemctl set-property httpd.service CPUShares=500 MemoryLimit=500M)

so what the product needs to have:

  - process isolation
  - easy configuration
  - configure the os/software and update it easily
  - nothing more than a bunch of lines per project (no dockerfile frickling)
  - binary / git rollouts

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

#57

Post by merb »

voltagex_ wrote: post #53
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…

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)

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

#58

Post by crb »

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…

This is very much Kubernetes's opinion, based on the production experience the engineers who built it.

Brian Grant has explained it recently here: https://github.com/kubernetes/kubernetes/blob/master/docs/wh...

"The technical definition of "orchestration" is execution of a defined workflow: do A, then B, then C. In contrast, Kubernetes is comprised of a set of control processes that continuously drive current state towards the provided desired state. It shouldn't matter how you get from A to C: make it so. This results in a system that is easier to use and more powerful, robust, and resilient."

Look into PaaSes that are built on top of K8s, like Red Hat's OpenShift v3 or Deis.

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

#59

Post by alexro »

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…

I totally agree with you and that's why I started https://github.com/slicebuild

The project is only month and a half long so if you want I can talk you through privately

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

#60

Post by thedevopsguy »

jschorr wrote: post #46
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…

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 example. Solutions have been bandied about for the last year or so and only now do we have something that's production ready. Do I rip out what I already have for something that is docker native or do I continue with the community based solution.

Storage (Data Locality) also follows a similar path. Kubernetes provides a way for making network based storage devices available to your containers. But now, with the announcement of Docker v1.9 do I go with their native solution or something that has been around for ~6months longer?

I've been working with these technologies for the past year and it has not been easy building something that is stable with a reasonable amount of future-proofness baked in.

Post reply on HN