Problems that warrant Docker orchestration | Hacker News Reader

Problems that warrant Docker orchestration

railsadventures.wordpress.com

48 pointstorkale9 comments

What's the advantage of switching to containers in this example setup?

If you're only using ~3 machines, why not deploy "by hand" and have a text file that maps containers to machines. If you're using a ton of machines, presumably the marginal machine-waste is minimal and you should just stick to the role-per-machine setup. It's way simpler.

I'm questioning the necessity of all this added complexity.

The advantages of switching to containers are numerous. They provide isolation, portability, quick boot times, consistency, application + dependencies in one package and a lot more. It totally refines development-production similarity when working on a software system. The same container that runs on the developer's machine will run in production. When working with Docker, your delivery pipeline is a lot more consistent and reflects better the code that runs on production later on. Docker has all the advantages VMs have, but with some major improvements: they are a lot more lightweight both on boot time and when moving them over the network, they share host machine resources and more. A quick search in Google will yield more than you can read about this topic :) I agree it is more complicated managing Docker containers than managing VMs, but I don't think of Docker as a new way to run things on production, this is just the side-effect. I think of Docker as a better, more consistent, way to develop and deliver software projects.

> No matter how you twist it, the same port cannot be occupied by two different processes on a given machine

Is that not what SO_REUSEPORT is for? (Serious question). Not that it would solve this problem necessarily

No it is not. http://stackoverflow.com/questions/14388706/socket-options-s...

I'm not sold on the title of this article. It isn't about Docker Orchestration at all (an example of an article about orchestration would be https://blog.docker.com/2015/02/orchestrating-docker-with-ma...)

This article is just about the problems that warrant implementing an orchestration solution. It is only at the end that they hint about talking about how orchestration is actually accomplished in a "Next time we'll talk about..." teaser

I think the article provides some great foundational perspectives on how HA/service discovery/port mgmt and so on were handled in the "pre-containers" era of VMs with a look into how these challenges are somewhat re-imagined in this current world of containers (predominantly Docker). I'm looking forward to the follow-on post about why they chose Kubernetes and how that solution works for them.

Ok, let's use your phrase. Title changed from "Docker Orchestration". If someone suggests a better title, we can change it again.

Thanks for the comment ecaron.

As this is the first post of a series, I wanted to present the problems we're dealing with when running Docker containers on production. It was also important for me to specifically touch the major shift of mind and new challenges that Docker has brought to our production infrastructure.

As I see it orchestrating Docker isn't about a certain tool or a framework. It is an abstract problem that is being solved in many different ways/frameworks.

That's why I do think that Docker orchestration is an appropriate title for the article, but I can see where you're coming from :)

The next post in the series is going to be much more specific to ECS and Kubernetes.

Thanks for the write-up, this is really helpful to get the big picture. Looking forward to your next posts.

Reply on news.ycombinator.com