Container Orchestration

How has Docker changed the Ops landscape?

Docker has changed the Ops landscape in two key ways.

Firstly, its built-in delivery mechanism—the ability to push images to a Docker Registry and pull them down as needed—solves a common question: how do I get my software onto the target machine?

Secondly, containers let us treat hugely disparate software in essentially the same way: we use the same mechanism to start, stop, and restart containers, whatever they happen to be running.

What is container orchestration?

This standardization, both in terms of delivery mechanism and how we manage software, reshapes the way we think of operations. The focus shifts to how we configure, run, and update the multiple containers that make up an application in concert, a process known as container orchestration.

Orchestrators

A new breed of tools has emerged to help orchestrate our app containers. They are named, rather uncreatively, orchestrators.

What do these orchestrators do for us?

First, they provide an environment or platform on which we can run and manage our containerized applications. They do this by creating an abstraction above the (physical or virtual) servers needed to run the software.

When deploying applications, it is more convenient to think of our group of “compute” servers as a single logical unit, a cluster. This lets us say things like, “Let’s deploy this app to the cluster,” without caring how it gets deployed or on exactly which instance. We can (mostly) let our orchestration layer handle those details for us.