Container orchestrators are the same but different, Docker Swarm

by | Oct 30, 2019 | Docker | 0 comments

Docker in Action, 2ed has been released! Get 50% off with code tsdocker

Reading Time: 5 minutes

This is the first of several posts that will provide a high-level introduction to the top container orchestrators in late-2019, differences between them, and which might be best for you. We’ll examine:

Logical Deployment Architecture of a Container Orchestrator
Logical Deployment Architecture of a Container Orchestrator

First, some things the are materially the same across all of these orchestrators in common practice:

  • logical architecture with 3-5 manager and up to a few hundred worker nodes
  • use of the Docker/OCI image format and container runtime
  • continuously converges application deployments to the desired state declared by an application deployment descriptor
  • limit cpu, memory, and I/O resources available to containers
  • schedule application containers to worker nodes with sufficient capacity that satisfy constraints declared in node, container, and service metadata
  • each orchestrator offers a model for core service orchestration concepts: a Service, instances of that service, Configuration, Secret, and other resources
  • provides an identity to Service instances (containers) as the solution to The First Secret Problem

Here are some things that are materially different across all these orchestrators in common practice:

  • who they are built for and sold to
  • the breadth, depth, extensibility, and details of the orchestrator’s model
    • e.g. the concept of a ‘Service’ is shared but how that service is described and implemented is different in ways that matter in each orchestrator
  • each orchestrator ultimately has a custom application descriptor format and command-line tooling that reflects its orchestration model
  • IP networking model and deployment requirements, e.g. Kubernetes needs to allocate an IP for every service instance (process) and starts from the position of a fully-peered open network between service instances
  • the specific tools and often the strategy for integrating with other network infrastructure and collaborating services
    • e.g. ECS Services are load-balanced with an ALB or NLB, but Kubernetes Services would likely use ELB and/or a third-party component as part of its ingress solution
  • application log collection and shipping often varies significantly
  • support for auto scaling service instances
  • orchestrator deployment and upgrade processes

If you want to deploy applications to two different container orchestrators, you should generally plan to at least double the effort to create and maintain that option. My default position is don’t support multiple orchestrators, but feel free to ping me if you’d like me to qualify that for your situation.

Ok, let’s dig into into Swarm a bit.

Docker Swarm

Docker Swarm is a container orchestrator built into Docker Engine and a core component of the Docker Enterprise suite. Swarm is much simpler to deploy and operate than most other orchestrators because it is:

  • fully integrated with the Docker Engine and toolchain
  • provides commonly needed service networking, config, and secret management components
  • uses the familiar Docker Compose v3 application descriptor format

Teams can create container clusters easily using the swarm subcommand of thedocker cli to initialize a swarm and join container hosts to the cluster in either manager or worker roles.

I think Swarm has best-in-class modeling of the core concepts of service orchestration such as Services, Config, and Secrets. These concepts and their implementations are easy for people new to containers and cluster orchestration to get started with. However, depending on your requirements you may feel limited by what is included, particularly around networking and #servicemesh.

If you want to learn more, I recommend reading Part III of Docker in Action, which describes container orchestration concepts and using Swarm with Compose in detail.

Differences

Here are three key differences between Swarm and most other orchestrators.

First, Swarm includes overlay networking technology and routing mesh that is active on every cluster node. These provide many networking features useful to:

  • expose services outside of the cluster to API Gateways and load balancers by publishing a particular port on each cluster node
  • discover services within the cluster by name
  • create dedicated network zones for public or private services
  • encrypt traffic between services at the network layer

Second, Docker Services do not support the sidecar container pattern. Each Docker service instance (Task) has one and only one container. Sidecars are most-often used to retrieve and ship application specific logs and metrics to their final destination or participate in a service mesh, both of which are very common with Kubernetes. The main consequences here are that:

  • if application logs are sent to stdout (12-factor style), the container platform must document what application log formats will be supported and implement a log shipping component volume that can handle the application log throughput
  • if applications send logs directly to the log repository, then they become responsible for the delivery of those logs to the log repository, even when the log system is down or slow, certainly a non-traditional application responsibility

Third, Swarm does not have the concept of a Job that can be used to run an ad-hoc or recurring Task. It’s possible to workaround this using Services though I would not lean on it too heavily by, e.g. building a batch job execution system for a data warehouse on it.

Best For

I think some of the best ways to use Swarm are:

  • Learning the concepts of containerized service orchestration on a development machine or Play with Docker (free)
  • Experimenting with containerized service deployment processes using a small Swarm cluster in order to decide if you should go further with containerized application services
  • As the foundation of a containerized compute platform that is (relatively) simple to use and operate, especially:
    • in non-Cloud datacenters and with existing, “well-known” networking infrastructure such as load balancers and API Gateways
    • to replace custom container deployment systems or those managed by system configuration management systems like Chef or Ansible
    • when you don’t need or can’t use service autoscaling because, e.g. the underlying cluster capacity is static
    • when you want the additional security and delivery support features of Docker Enterprise or an on-ramp to Docker Kubernetes Service

Anecdata

I’ll close with some Swarm anecdata…

I have been asked some variation of “how can I run these containerized services on my development machine using Kubernetes” a number of times, mostly by software developers. After a couple probing questions, I suggest either:

  • try the Kubernetes support in Docker for Mac/Windows if they actually need to use Kubernetes
  • try Compose+Swarm in Docker if they just want their services running locally the quickest and simplest way possible

So far, deploying to Swarm has been met with comments like, “Gosh, that was really easy and exactly what I needed to do. Why are other options so complex?” My answer to that question is that Swarm prioritized architectural attributes like usability and security over flexibility and extensibility.

I’ve witnessed similar reactions from “DevOps transformation” teams who were surprised at how quick their time-to-value was for creating a cluster and deploying services to it from an automated delivery pipeline.

Give Swarm a chance, you might like it and find that it meets your needs.

The next post in this series covers Elastic Container Service.

Stephen

#NoDrama