Docker – Data/ML Engineer Blog

Docker for Data Teams: Containerization vs. Orchestration (and Where Kubernetes Fits)

Introduction — why this matters

You push a change to a data API, it works on your laptop, then blows up in staging because of Python versions, OS libs, or a missing driver. Containers fix this by packaging your code with its runtime and dependencies. Docker is the most common way to build and run those containers. But Docker is not a full orchestration platform—Kubernetes (or ECS/Nomad) handles that at scale. Let’s draw the line, then ship a real example.

Concepts in plain English

What Docker actually is

Containerization toolchain: Build (docker build), distribute (docker push/pull), and run (docker run) images.
Runtime: Starts isolated processes sharing the kernel (lighter than VMs).
Local developer UX: Docker Desktop/CLI, plus Docker Compose for multi-container dev.

What Docker is not

Cluster orchestrator: It doesn’t schedule across many machines, auto-heal, or roll out zero-downtime updates.
Secret manager or service mesh: You’ll use cloud/K8s tools for that.

Orchestration at a glance

Docker Compose: Great for local and small, single-host setups (dev/test).
Docker Swarm: Lightweight clustering, now niche.
Kubernetes: Industry standard for production orchestration (deployments, autoscaling, self-healing).
AWS ECS / Nomad: Popular managed/alternative orchestrators.

Architecture: from laptop to cluster

Build an immutable image (your app + runtime).
Publish to a registry (Docker Hub, ECR, GCR).
Run:
- Local: docker run or docker compose up.
- Prod: An orchestrator (Kubernetes/ECS) schedules containers on nodes, restarts them, rolls updates, and attaches storage/networking.

Real example: API + MongoDB (dev with Compose, prod with K8s)

1) Dockerfile (Python FastAPI)

# Multi-stage to keep images small
FROM python:3.12-slim AS base
ENV PYTHONDONTWRITEBYTECODE=1 PYTHONUNBUFFERED=1
WORKDIR /app

# Build deps separately for better caching
COPY pyproject.toml poetry.lock* /app/
RUN pip install --no-cache-dir poetry && poetry config virtualenvs.create false \
 && poetry install --only main --no-root

# Copy source
COPY . /app
# Run as non-root for security
RUN useradd -m appuser
USER appuser

EXPOSE 8000
CMD ["uvicorn", "service:app", "--host", "0.0.0.0", "--port", "8000"]

2) docker-compose.yml (local dev)

version: "3.9"
services:
  api:
    build: .
    ports: ["8000:8000"]
    environment:
      MONGO_URL: "mongodb://mongo:27017/app"
    depends_on: ["mongo"]
  mongo:
    image: mongo:7
    volumes:
      - mongo_data:/data/db
    healthcheck:
      test: ["CMD", "mongosh", "--eval", "db.runCommand({ ping: 1 })"]
      interval: 10s
      timeout: 5s
      retries: 5
volumes:
  mongo_data:

Run: docker compose up --build

3) Minimal Kubernetes (prod orientation)

apiVersion: apps/v1
kind: Deployment
metadata: { name: api }
spec:
  replicas: 3
  selector: { matchLabels: { app: api } }
  template:
    metadata: { labels: { app: api } }
    spec:
      containers:
        - name: api
          image: ghcr.io/acme/api:1.2.3
          ports: [{ containerPort: 8000 }]
          env:
            - name: MONGO_URL
              valueFrom:
                secretKeyRef: { name: mongo-secrets, key: url }
          resources:
            requests: { cpu: "200m", memory: "256Mi" }
            limits:   { cpu: "500m", memory: "512Mi" }
          readinessProbe:
            httpGet: { path: /health, port: 8000 }
            initialDelaySeconds: 5
            periodSeconds: 5
---
apiVersion: v1
kind: Service
metadata: { name: api }
spec:
  selector: { app: api }
  ports: [{ port: 80, targetPort: 8000 }]
  type: ClusterIP

Kubernetes adds: replicas, rolling updates, health probes, resource limits, and secrets.

When to use what (quick table)

Need	Docker/Compose	Kubernetes	ECS
Solo dev, quick demos	✅	❌	❌
Single VM/staging	✅	➖ (overkill)	✅ (Fargate-lite)
Zero-downtime deploys	➖	✅	✅
Autoscaling & self-healing	❌	✅	✅
Rich ecosystem (operators, CSI, HPA)	❌	✅	➖
Lowest ops on AWS	➖	➖ (EKS)	✅ (managed)

Best practices for data/ML workloads

Image & build

Use multi-stage builds; pin base images; avoid latest.
Scan images (Trivy/Grype); include SBOM (Syft).
Run as non-root; drop Linux capabilities.

Runtime

Health checks (HTTP/TCP) and readiness gates.
Set CPU/memory requests/limits; prevent noisy neighbors.
Externalize config & secrets (K8s Secrets/SSM/Secrets Manager).
Persist state in volumes managed by your cloud/K8s storage classes.

Networking & security

Least-privilege network policies; don’t expose containers directly to the internet.
Prefer mTLS/ingress controllers in K8s; avoid embedding creds in images.

Data specifics

Don’t store databases’ data inside container layers—use volumes.
For NoSQL labs, Compose is perfect; for production, use managed DB services or stateful K8s with care (backups, anti-affinity, pod disruption budgets).

CI/CD

Build once, tag immutably, promote the same image across stages.
Cache layers; use build args for platform (--platform linux/amd64).
Record provenance (attestations) for compliance.

Common pitfalls (avoid these)

Using :latest tags → non-reproducible deploys.
Baking secrets into images or env files in Git.
Treating containers as VMs (huge images, SSH inside).
Ignoring health probes and resource limits → flaky rollouts.
Running stateful databases in K8s without storage/backup strategy.
Architecture mismatch (built on ARM, deployed on x86) without multi-arch.

Conclusion & takeaways

Docker = containerization: package and run apps consistently.
Kubernetes/ECS = orchestration: schedule, scale, heal, and roll out in clusters.
Start with Docker + Compose for developer velocity; graduate to Kubernetes/ECS when you need reliability, scaling, and governance.
For data work, keep state in managed services or robust storage layers, and harden builds/runtimes from the start.

Internal link ideas

“Kubernetes 101 for Data Engineers: Deployments, Services, and HPAs”
“Designing CI/CD for Data APIs: Docker Images, Registries, and Blue-Green”
“Running Kafka/Redis/Mongo Locally with Docker Compose”
“Security Hardening: SBOM, Scanning, and Non-Root Containers”

Image prompt

“A clean, modern diagram contrasting Docker (container build/run) with Kubernetes (cluster orchestration). Show a developer building an image, pushing to a registry, and an orchestrator scheduling pods across nodes. Minimalistic, high-contrast, isometric 3D, labeled components, subtle blue/teal palette.”

Data/ML Engineer Blog