Just DevOps 2019 - Jakub Hajek - Container orchestration with Docker Swarm

### Overview In this talk from Just DevOps 2019, Jakub Hajek discusses container orchestration using Docker Swarm as a practical, lightweight alternative to complex platforms like Kubernetes. Drawing from his background running projects and leading a DevOps/admin team at Sole Metal / Elastometal, Hajek argues that many teams rush into Kubernetes due to industry hype rather than actual architectural needs. Docker Swarm provides a low barrier to entry, out-of-the-box cluster management, and stable orchestration that fits many production workloads without unnecessary operational overhead.

### Key Topics - **Rationale for Docker Swarm**: Avoiding overengineering and excessive complexity; understanding core business needs and achieving faster delivery without the steep learning curves of Kubernetes or service meshes. - **Swarm Architecture & Consensus**: Node roles (Managers vs. Workers), Raft consensus algorithm for maintaining state, quorum requirements, and leader election. - **Declarative Services & Scheduling**: Defining desired states (replicas vs. global mode), placement constraints, placement preferences across availability zones/datacenters, and automatic reconciliation. - **Zero-Downtime Updates & Healthchecks**: Rolling updates with configurable parallelism, delay, healthchecks, and automatic rollbacks on failure. - **Networking, Discovery & Security**: Ingress routing mesh, internal service discovery via built-in DNS, encrypted overlay networks (IPsec), and native secrets/configs management. - **Edge Ingress with Traefik & Consul**: Dynamic routing, automatic SSL/TLS certificate generation and renewal via Let's Encrypt, and horizontally scaling ingress with Consul as a distributed key-value store.

### Technical Details - **Cluster Initialization & Management**: Initializing a single-node or multi-node cluster requires just `docker swarm init`, followed by `docker swarm join` using generated authentication tokens over mutually authenticated TLS (gRPC/HTTP2). - **Consensus & State**: The Raft database is stored on manager nodes at `/var/lib/docker/swarm/raft`. The leader coordinates log replication, while manager nodes maintain quorum and handle scheduling. Workers merely execute tasks and report statuses. - **Declarative Service Definition**: Services can run as replicated (0 to N tasks/containers) or `global` (exactly one container per node, useful for monitoring agents like cAdvisor or node exporters). Scheduling can be influenced by labels, resource constraints (CPU/RAM), or placement preferences across availability zones. - **Rolling Updates**: Configured via update parameters such as parallelism (e.g., updating 1 container at a time) and delay (e.g., 10s intervals), relying on healthchecks (HTTP response status 200 via curl or wget) to halt and roll back if tasks fail. - **Secrets and Configs**: `docker secret` stores sensitive data encrypted in Raft, mounted decrypted in-memory under `/run/secrets/<name>` for explicitly permitted services. `docker config` provides a non-encrypted equivalent, requiring versioning conventions (e.g., appending version numbers) when configurations change. - **Traefik and Consul Stack Demo**: Demonstrated on AWS `t2.micro` instances provisioned via Docker Machine across three VMs. Traefik listens on `/var/run/docker.sock` to detect Swarm service events automatically and dynamically update routes defined by Docker service labels. Consul acts as the shared key-value store for Let's Encrypt certificates, enabling multiple Traefik replicas to synchronize certificates without collision.

### Takeaways - Master Docker fundamentals (image optimization, 12-factor principles, environment configuration) before advancing to complex orchestrators. - Docker Swarm provides production-grade clustering, built-in ingress routing mesh, service discovery, secrets, and zero-downtime rolling updates out of the box with minimal maintenance. - Swarm serves as an ideal baseline for projects requiring stability and simple operational overhead, with the option to migrate to Kubernetes later if complex features become strictly necessary.