container.training/docs/swarmkit.md

SwarmKit

• SwarmKit is an open source toolkit to build multi-node systems

• It is a reusable library, like libcontainer, libnetwork, vpnkit ...

• It is a plumbing part of the Docker ecosystem

--

.footnote[🐳 Did you know that кит means "whale" in Russian?]

---

SwarmKit features

• Highly-available, distributed store based on Raft
  (avoids depending on an external store: easier to deploy; higher performance)

• Dynamic reconfiguration of Raft without interrupting cluster operations

• Services managed with a declarative API
  (implementing desired state and reconciliation loop)

• Integration with overlay networks and load balancing

• Strong emphasis on security:

  • automatic TLS keying and signing; automatic cert rotation
  • full encryption of the data plane; automatic key rotation
  • least privilege architecture (single-node compromise ≠ cluster compromise)
  • on-disk encryption with optional passphrase

---

class: extra-details

Where is the key/value store?

• Many orchestration systems use a key/value store backed by a consensus algorithm
  (k8s→etcd→Raft, mesos→zookeeper→ZAB, etc.)

• SwarmKit implements the Raft algorithm directly
  (Nomad is similar; thanks @cbednarski, @diptanu and others for point it out!)

• Analogy courtesy of @aluzzardi:

  It's like B-Trees and RDBMS. They are different layers, often associated. But you don't need to bring up a full SQL server when all you need is to index some data.

• As a result, the orchestrator has direct access to the data
  (the main copy of the data is stored in the orchestrator's memory)

• Simpler, easier to deploy and operate; also faster

---

SwarmKit concepts (1/2)

• A cluster will be at least one node (preferably more)

• A node can be a manager or a worker

• A manager actively takes part in the Raft consensus, and keeps the Raft log

• You can talk to a manager using the SwarmKit API

• One manager is elected as the leader; other managers merely forward requests to it

• The workers get their instructions from the managers

• Both workers and managers can run containers

---

Illustration

---

SwarmKit concepts (2/2)

• The managers expose the SwarmKit API

• Using the API, you can indicate that you want to run a service

• A service is specified by its desired state: which image, how many instances...

• The leader uses different subsystems to break down services into tasks:
  orchestrator, scheduler, allocator, dispatcher

• A task corresponds to a specific container, assigned to a specific node

• Nodes know which tasks should be running, and will start or stop containers accordingly (through the Docker Engine API)

You can refer to the NOMENCLATURE in the SwarmKit repo for more details.

---

Swarm Mode

• Since version 1.12, Docker Engine embeds SwarmKit

• All the SwarmKit features are "asleep" until you enable "Swarm Mode"

• Examples of Swarm Mode commands:

  • docker swarm (enable Swarm mode; join a Swarm; adjust cluster parameters)

  • docker node (view nodes; promote/demote managers; manage nodes)

  • docker service (create and manage services)

???

• The Docker API exposes the same concepts

• The SwarmKit API is also exposed (on a separate socket)

---

You need to enable Swarm mode to use the new stuff

• By default, all this new code is inactive

• Swarm Mode can be enabled, "unlocking" SwarmKit functions
  (services, out-of-the-box overlay networks, etc.)

.exercise[

• Try a Swarm-specific command:

  docker node ls
  

]

--

You will get an error message:

Error response from daemon: This node is not a swarm manager. [...]