<p>Welcome to the wonderful world of container orchestrators.</p>

<p>Consider microservices for a moment. Each service should be independently deployed and independently scaled across a cluster of VMs. Where does basic Docker and Docker Compose fit in? They don’t compete with distributed system orchestrators like Openshift Kubernetes, CloudFoundry or Docker Swarm.</p>

<p>A microservices platform that scales out and has fault tolerances needs a cluster of servers with internal load balancing where traffic to each service is load balanced to many replicas. The idea that you would link two containers doesn’t make sense in a microservices world as each container should connect to a logical service that balances traffic to many pods that are scaled independently of other services. So study the templates for how large scale apps run across a whole cluster of VMs with something like OKD Kubernetes. </p>

<p>So where does Docker Compose fit in if you are using a full orchestrator? I don’t think it does if you are using something like Kubernetes. Developers can run Minikube or Minishift on their laptop. Better yet one “not production” cluster can run a different namespace for every developer to have their own personal or shared sandpits to develop in. You can also setup one namespace per test environment on that one cluster simplifying you management. (Production can be in a dedicated cluster.)</p>

<p>Note that Docker <a href="https://kubedex.com/kubernetes-container-runtimes/" rel="nofollow noreferrer">isn’t the only container runtime</a> these days and IMHO it’s unlikely to not be the default one for orchestrators in other than Swarm in the future. For example k8s now uses a standard API that <a href="https://kubic.opensuse.org/blog/2018-09-17-crio-default/" rel="nofollow noreferrer">lets you plug in alternatives</a> and runtimes that focus on security and footprint are likely to become the default. </p>

<p><strong>Update</strong>: There are some special cases where “running two image in the same process space” makes sense. One is the “<a href="https://link.medium.com/BfC9rYVgaU" rel="nofollow noreferrer">sidecar pattern</a>”. Rather than than mixing business services together this is where you run a technical service image with every business service image. An example of that is a service mesh that uses an smart proxy in every container. Every business service only connects to the smart proxy in the same process space that forwards traffic to the next business service. The smart proxy can then do things like service discovery, load balancing, circuit breaking, load shedding, protocol upgrades, mutual TLS between all business services. </p>

CC BY-SA 4.0
2019-01-31T23:41:50.567Z
2019-02-09T10:33:50.043Z
2019-02-09T10:33:50.043Z
simbo1905
<p>welcome to DevOps SE, @bgarcial!</p>

<p>Well I think there are the following options depending on the use case:</p>

<ul>
<li>Docker Container <em>links</em> are a according to the vendor site a <a href="https://docs.docker.com/network/links/" rel="nofollow noreferrer">legacy feature</a> and you shouldn't use it</li>
<li>Docker <em>compose</em> should work well but you can't scale horizontally: the stack is runnable only one a single machine</li>
<li>With <em>Docker Swarm</em> using mostly same YML you can distribute your containers across many machines</li>
<li>If you are going to deploy large scale production environments you might want to choose <em>Kubernetes</em> over Swarm, maybe have a look for example on <em>Rancher/Kubernetes</em>.</li>
</ul>

CC BY-SA 4.0
2018-12-17T08:51:51.223Z
With respect to Networking, docker links are just an old way to communicate between containers. I've seen recently the bridges concept ... is this the road?
bgarcial
CC BY-SA 4.0
2018-12-17T09:03:26.467Z
depending on your use case: indeed Docker allows configuration of virtual networks aside just containers. https://docs.docker.com/network/bridge/#use-the-default-bridge-network
Ta Mu
CC BY-SA 4.0
2018-12-17T06:25:13.237Z
2020-01-08T15:59:32.547Z
2020-01-08T15:59:32.547Z
Ta Mu
<p>I am familiarizing with the architecture and practices to package, build and deploy software or unless, small pieces of software.</p>

<p>If suddenly I am mixing concepts with specific tools (sometimes is unavoidable), let me know if I am wrong, please.</p>

<p>On the road, I have been reading and learning about the images and containers terms and their respective relationships in order to start to build the workflow software systems of a better possible way. </p>

<p>And I have a question about the services orchestration in the context of the docker :</p>

<ul>
<li><p>The containers are lightweight and portable encapsulations of an environment in which we have all the binary and dependencies we need to run our application. OK</p></li>
<li><p>I can set up communication between containers using <strong>container links</strong> <code>--link</code> flag.  </p></li>
</ul>

<p>I can replace the use of container links, with docker-compose in order to automate my services workflow and running multi-containers using <code>.yaml</code> file configurations.</p>

<p>And I am reading about of the Container orchestration term, which defines the relationship between containers when we have distinct "software pieces" separate from each other, and how these containers interact as a system.</p>

<p>Well, I suppose that  I've read good the documentation :P</p>

<p>My question is:</p>

<p>A docker level, are <strong>container links</strong> and <code>docker-compose</code> a way of container orchestration? </p>

<p>Or with docker, if I want to do container orchestration ... should I use <code>docker-swarm</code>? </p>

<docker><containers><orchestration>
How does Docker container orchestration work?
bgarcial
# How does Docker container orchestration work?

(Asked by: username_0 on 2018-12-16)

I am familiarizing with the architecture and practices to package, build and deploy software or unless, small pieces of software.

If suddenly I am mixing concepts with specific tools (sometimes is unavoidable), let me know if I am wrong, please.

On the road, I have been reading and learning about the images and containers terms and their respective relationships in order to start to build the workflow software systems of a better possible way.

And I have a question about the services orchestration in the context of the docker :

* The containers are lightweight and portable encapsulations of an environment in which we have all the binary and dependencies we need to run our application. OK
* I can set up communication between containers using **container links** `--link` flag.

I can replace the use of container links, with docker-compose in order to automate my services workflow and running multi-containers using `.yaml` file configurations.

And I am reading about of the Container orchestration term, which defines the relationship between containers when we have distinct "software pieces" separate from each other, and how these containers interact as a system.

Well, I suppose that I've read good the documentation :P

My question is:

A docker level, are **container links** and `docker-compose` a way of container orchestration?

Or with docker, if I want to do container orchestration ... should I use `docker-swarm`?

**Tags:** docker, containers, orchestration


---

## 2 answers

### Answer by username_2 on 2018-12-17. Score: 4 | Accepted answer

welcome to DevOps SE, @username_0!

Well I think there are the following options depending on the use case:

* Docker Container *links* are a according to the vendor site a [legacy feature](https://docs.docker.com/network/links/) and you shouldn't use it
* Docker *compose* should work well but you can't scale horizontally: the stack is runnable only one a single machine
* With *Docker Swarm* using mostly same YML you can distribute your containers across many machines
* If you are going to deploy large scale production environments you might want to choose *Kubernetes* over Swarm, maybe have a look for example on *Rancher/Kubernetes*.

> **Comments:**
> **username_0**: With respect to Networking, docker links are just an old way to communicate between containers. I've seen recently the bridges concept ... is this the road?  
> **username_2**: depending on your use case: indeed Docker allows configuration of virtual networks aside just containers. https://docs.docker.com/network/bridge/#use-the-default-bridge-network  

---

### Answer by username_1 on 2019-01-31. Score: 3

Welcome to the wonderful world of container orchestrators.

Consider microservices for a moment. Each service should be independently deployed and independently scaled across a cluster of VMs. Where does basic Docker and Docker Compose fit in? They don’t compete with distributed system orchestrators like Openshift Kubernetes, CloudFoundry or Docker Swarm.

A microservices platform that scales out and has fault tolerances needs a cluster of servers with internal load balancing where traffic to each service is load balanced to many replicas. The idea that you would link two containers doesn’t make sense in a microservices world as each container should connect to a logical service that balances traffic to many pods that are scaled independently of other services. So study the templates for how large scale apps run across a whole cluster of VMs with something like OKD Kubernetes.

So where does Docker Compose fit in if you are using a full orchestrator? I don’t think it does if you are using something like Kubernetes. Developers can run Minikube or Minishift on their laptop. Better yet one “not production” cluster can run a different namespace for every developer to have their own personal or shared sandpits to develop in. You can also setup one namespace per test environment on that one cluster simplifying you management. (Production can be in a dedicated cluster.)

Note that Docker [isn’t the only container runtime](https://kubedex.com/kubernetes-container-runtimes/) these days and IMHO it’s unlikely to not be the default one for orchestrators in other than Swarm in the future. For example k8s now uses a standard API that [lets you plug in alternatives](https://kubic.opensuse.org/blog/2018-09-17-crio-default/) and runtimes that focus on security and footprint are likely to become the default.

**Update**: There are some special cases where “running two image in the same process space” makes sense. One is the “[sidecar pattern](https://link.medium.com/BfC9rYVgaU)”. Rather than than mixing business services together this is where you run a technical service image with every business service image. An example of that is a service mesh that uses an smart proxy in every container. Every business service only connects to the smart proxy in the same process space that forwards traffic to the next business service. The smart proxy can then do things like service discovery, load balancing, circuit breaking, load shedding, protocol upgrades, mutual TLS between all business services.


---

