Docker in Production: Swarm, Kubernetes and Beyond

Everything so far runs on one machine. This closing lesson covers what changes when that machine is a production server, when one server is no longer enough, and how Docker Swarm and Kubernetes keep containers running across a cluster. You will finish knowing which option fits which situation and what to learn next.

Single-Host Production Checklist

Many real workloads run on one well-managed server with Compose. Before calling such a deployment production-ready, confirm:

Images come from a registry, pinned by tag or digest, built and scanned by CI.
Every service has restart: unless-stopped, resource limits and log rotation; secrets are files.
Only the reverse proxy publishes ports and it terminates TLS; Caddy needs two lines of configuration.
The database volume is backed up on a schedule, with a tested restore.
Updates are docker compose pull && docker compose up -d, with the previous tag recorded for one-command rollback.
Monitoring exists beyond docker stats: cAdvisor with Prometheus, or a hosted agent, watching CPU, memory, restarts and disk.

text

# Caddyfile: automatic HTTPS in front of the web service
shop.example.com {
  reverse_proxy web:80
}

Why Orchestration

A single host cannot survive its own failure, cannot scale a service beyond its CPUs, and needs manual work to update without downtime. An orchestrator runs containers across many machines and adds scheduling, replication with self-healing, rolling updates with rollback, and service discovery with load balancing. Everything you learned about images, healthchecks, signals, logging to stdout and resource limits carries over unchanged; orchestrators depend on those properties.

Docker Swarm

Swarm is built into the Docker Engine and reuses the Compose file format, which makes it the smallest step up from a single host:

bash

docker swarm init                                     # this node becomes a manager
docker stack deploy -c compose.yaml -c compose.prod.yaml shop
docker service ls                                     # shop_api 3/3 replicas
docker service update --image ghcr.io/you/shop-api:1.5.0 shop_api   # rolling update
docker service rollback shop_api

The deploy: key controls replicas, update strategy and placement; docker compose ignores most of it, Swarm honours all of it:

yaml

services:
  api:
    image: ghcr.io/you/shop-api:1.5.0
    deploy:
      replicas: 3
      update_config: { parallelism: 1, delay: 10s, order: start-first }
      resources: { limits: { cpus: "1", memory: 512m } }

Swarm suits small clusters run by small teams; its ecosystem is modest and Docker positions Kubernetes as the primary orchestrator.

Kubernetes Essentials

Kubernetes, the industry-standard orchestrator, describes desired state in YAML objects and continuously reconciles the cluster toward it. The objects you meet first:

| Object | Role | Compose analogue | |--------|------|------------------| | Pod | One or more containers scheduled together | A running container | | Deployment | Manages replicas and rolling updates of Pods | deploy: | | Service | Stable name and load balancing for Pods | Service-name DNS | | Ingress | HTTP routing and TLS from outside | The Nginx proxy |

bash

kubectl apply -f api-deployment.yaml
kubectl get pods
kubectl logs deploy/api -f
kubectl scale deploy/api --replicas=5
kubectl rollout status deploy/api

Docker Desktop includes a single-node cluster (Settings > Kubernetes); kind and minikube create local clusters anywhere. In production most teams use a managed control plane such as Amazon EKS, Google GKE or Azure AKS, and Helm packages manifests the way Compose packages services.

Choosing

| Situation | Reasonable choice | |-----------|-------------------| | One server, small team, minutes of downtime acceptable | Compose with the checklist above | | A few servers, high availability with minimal new concepts | Swarm | | Many services, autoscaling, multiple teams, cloud integrations | Managed Kubernetes | | No desire to run infrastructure at all | A container platform (Cloud Run, ECS Fargate, Fly.io, Render) that takes the same image and handles scheduling, TLS and scaling |

What to Learn Next

Kubernetes in depth: Deployments, Services, Ingress, Helm and operating a managed cluster.
Linux and networking fundamentals: everything in Docker is a Linux primitive underneath.
Infrastructure as code and observability: Terraform for the servers, Prometheus and OpenTelemetry for what runs on them.

Key Takeaways

A single host with Compose is a valid production platform once images are pinned and restart policies, limits, rotation, secrets, a TLS proxy, backups and monitoring are in place.
Orchestrators add scheduling, self-healing, rolling updates and service discovery across many machines.
Swarm reuses the Compose file with docker stack deploy; Kubernetes uses Deployments, Services and Ingress applied with kubectl.
Managed Kubernetes or a container platform is usually better than running a cluster yourself.
Good images (small, non-root, healthchecked, logging to stdout, signal-aware) are the foundation for every option.

What to learn next: Kubernetes — take the images and Compose knowledge from this course into cluster-scale deployments with Deployments, Services, Ingress and Helm.