
Problems that warrant Docker orchestration - torkale
https://railsadventures.wordpress.com/2015/11/15/docker-orchestration-the-full-story/
======
dxhdr
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.

~~~
erez-rabih
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.

------
bpicolo
> 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

~~~
biokoda
No it is not. [http://stackoverflow.com/questions/14388706/socket-
options-s...](http://stackoverflow.com/questions/14388706/socket-options-so-
reuseaddr-and-so-reuseport-how-do-they-differ-do-they-mean-t)

------
ecaron
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...](https://blog.docker.com/2015/02/orchestrating-docker-with-machine-
swarm-and-compose/))

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

~~~
erez-rabih
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.

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

