Docker :latest Tag Broke Production — Pin Your Base Images

Docker containerization solves the 'works on my machine' problem at the infrastructure level. Your application runs in development. You deploy it and it crashes — different Python version, different library, different timezone. Docker eliminates environment drift by packaging the application with its entire dependency graph into a portable image.

The architecture is client-server. The Docker client sends commands to the Docker Daemon via REST API. The Daemon manages all Docker objects — images, containers, networks, volumes. This separation means the client and daemon can run on different machines, enabling remote builds and CI/CD integration.

Containers are not VMs. They share the host Linux kernel and use namespaces for isolation and cgroups for resource limits. This gives millisecond startup times and sub-megabyte overhead — but also means a compromised container has kernel-level access to the host. Understanding this trade-off is essential for production security decisions.

Why Docker Containerization Is Not Just Lightweight VMs

Docker containerization packages an application with its dependencies into a portable, isolated unit called a container. Unlike virtual machines, containers share the host OS kernel, eliminating the overhead of a full guest OS per instance. This yields near-native performance and sub-second startup times, making containers the standard for microservices and CI/CD pipelines.

Each container runs as an isolated process in user space, with its own filesystem, network stack, and resource limits. Images are built from layered filesystems (UnionFS), enabling incremental builds and efficient storage — only changed layers are transferred or stored. This layering is the root of both Docker's power and its pitfalls: a base image pinned to :latest can silently introduce breaking changes when the upstream tag is updated.

Use containerization when you need consistent environments across development, testing, and production — especially in distributed systems with many services. It eliminates "it works on my machine" by bundling the runtime, config, and OS-level dependencies into a single artifact. In production, this reproducibility is critical for rollbacks, scaling, and auditing.

Docker Architecture — How It All Fits Together

Docker containerization uses a client-server architecture — before writing a single Dockerfile, understand what you are actually talking to. Docker with three main components:

Docker Client: The CLI you interact with. When you run docker build or docker run, the Docker client sends these commands via REST API to the Docker Daemon. The client and daemon can run on the same machine or on different machines.

Docker Daemon (dockerd): The background service that does the actual work. The Docker Daemon listens for Docker API requests and manages Docker objects — images, containers, networks, and volumes. It is the engine that builds, runs, and distributes containers.

Docker Engine: The collective name for the client + daemon + REST API layer. When people say 'install Docker', they mean install Docker Engine (or Docker Desktop on macOS/Windows, which bundles Docker Engine inside a lightweight Linux VM).

Docker Registry: A storage and distribution system for container images. Docker Hub is the default public registry — it hosts official images for postgres, nginx, python, node, and thousands more. Companies run private registries (Amazon ECR, GitHub Container Registry, or a self-hosted Docker registry) to store proprietary images. When you run docker pull postgres:16, Docker Engine contacts Docker Hub and downloads the image layers.

The flow for every docker run command: Docker client → REST API → Docker Daemon → checks local image cache → pulls from registry if not cached → creates container → starts process.

Failure scenario — Daemon unreachable: If the Docker Daemon is down or the socket is misconfigured, every docker command fails with 'Cannot connect to the Docker daemon'. In production, this means your CI/CD pipeline stops, health checks cannot exec into containers, and log collection breaks. Always monitor the Docker Daemon process and socket permissions.

What Containers Actually Are (Not VMs)

The most common misunderstanding about Docker containerization: Linux containers are not virtual machines. A virtual machine emulates hardware — it has its own kernel, its own memory management, its own full operating system. Booting a VM takes seconds to minutes and uses hundreds of MB of RAM just for the OS overhead.

Containers share the host's operating system kernel. They use Linux kernel features — namespaces (for isolation: each running container sees its own filesystem, network, and process tree) and cgroups (for resource utilization limits: CPU caps, memory limits) — to create isolated environments without the overhead of a separate OS.

Practical difference: a VM running Ubuntu might use 512MB RAM just for the OS. A Docker container running Ubuntu uses <1MB overhead for isolation — the processes inside see an Ubuntu-like environment but share the host's Linux kernel. This is why you can run 50 containers on a machine that could only run 3 VMs, with dramatically better resource utilization.

This architecture is also why Docker Desktop on macOS and Windows runs a lightweight Linux VM internally — macOS and Windows have different kernels, so Docker Engine needs a Linux kernel to host Linux containers.

Security trade-off: Because containers share the host kernel, a container escape vulnerability gives the attacker root access to the host. VMs have a much stronger isolation boundary (the hypervisor). For multi-tenant workloads where you run untrusted code, use VMs (gVisor, Firecracker) or sandboxed containers (Kata Containers). For trusted application deployment, containers are the right choice.

Performance impact: The shared-kernel architecture means container-to-container communication on the same host uses localhost networking — no hypervisor overhead. Inter-container latency is sub-millisecond. In a VM-based architecture, network traffic between VMs on the same host still goes through virtual network interfaces, adding 10-50 microseconds per packet.

Installing Docker and Your First Commands

Installing Docker on Linux (Ubuntu/Debian):

# Install Docker Engine on Ubuntu
curl -fsSL https://get.docker.com | sh

# Add your user to the docker group (avoids sudo on every command)
sudo usermod -aG docker $USER
newgrp docker

# Verify install
docker --version
# Docker version 26.1.3, build b72abbb

# ── Essential Docker commands ─────────────────────────────────────
# Pull an image from Docker Hub
docker pull python:3.12-slim

# Run a container interactively
docker run -it python:3.12-slim bash

# Run a container in the background (detached)
docker run -d --name myapp -p 8000:8000 myapp:latest

# List running containers
docker ps

# List all containers (including stopped)
docker ps -a

# Stop a running container
docker stop myapp

# View container logs
docker logs -f myapp

# Execute a command inside a running container
docker exec -it myapp bash

# Remove a stopped container
docker rm myapp

# List Docker images
docker images

# Remove an image
docker rmi python:3.12-slim

Your First Dockerfile — Building Container Images

A Dockerfile is a recipe for building a container image — the fundamental unit of Docker containerization. Docker reads it top to bottom, executing each instruction as a layer. Docker caches layers and only rebuilds what changed — understanding this is the difference between 30-second builds and 5-minute builds.

When you run docker build, the Docker client sends your build context (your project files) to the Docker Daemon, which executes each Dockerfile instruction in sequence, creating a new image layer for each one.

Layer caching mechanics: Each instruction in a Dockerfile creates a layer. Docker caches layers and reuses them if the instruction and all preceding layers are unchanged. If you COPY your entire application before installing dependencies, every code change invalidates the pip install layer — forcing a full reinstall on every build. The fix: COPY requirements.txt first, RUN pip install, then COPY the rest.

Build context size matters: The docker build command sends your entire build context (current directory by default) to the Daemon. Without a .dockerignore file, this includes .git (often 100MB+), node_modules, __pycache__, and potentially .env files with secrets. A large build context slows every build, even with layer caching.

# ── Base image ───────────────────────────────────────────────────
# Always pin exact versions — 'python:latest' will break your
# build when a new Python version releases
FROM python:3.12-slim

# ── Metadata ────────────────────────────────────────────────────
LABEL maintainer="your@email.com"
LABEL version="1.0.0"

# ── Set working directory ────────────────────────────────────────
WORKDIR /app

# ── Copy requirements FIRST (layer caching trick) ────────────────
# If requirements.txt doesn't change, Docker caches this layer.
# If you copied all files first, every code change would
# invalidate the pip install layer — rebuilds take forever.
COPY requirements.txt .
RUN pip install --no-cache-dir -r requirements.txt

# ── Now copy the rest of your code ──────────────────────────────
COPY . .

# ── Create non-root user (security best practice) ───────────────
# Running as root inside a container is a security risk.
RUN useradd --create-home appuser
USER appuser

# ── Expose port and set default command ──────────────────────────
EXPOSE 8000
CMD ["python", "-m", "uvicorn", "main:app", "--host", "0.0.0.0", "--port", "8000"]

Multi-Stage Builds — Shrinking Production Images

The single biggest mistake in beginner Dockerfiles: shipping build tools to production. A Python application that compiles some C extensions needs gcc, make, and build headers during the build — but not at runtime. A Go application needs the entire Go toolchain to compile — but the final binary needs nothing.

Multi-stage builds solve this: use a heavy 'builder' image with all your build tools, then copy only the finished artifact into a minimal 'runtime' image. Production images shrink from gigabytes to tens of megabytes, reducing attack surface and improving pull times across different environments.

Why this matters for security: Every tool in your production image is an attack surface. gcc, make, curl, wget — if an attacker gets shell access to your container, these tools let them compile exploits, download payloads, and pivot. A slim runtime image with no build tools gives an attacker almost nothing to work with.

Why this matters for deployment speed: Container images must be pulled to every node before they can run. A 1.2GB image takes 30-60 seconds to pull over a fast network. A 180MB image pulls in 5-10 seconds. During rolling deployments across 20 nodes, that difference is minutes of deployment time.

Failure scenario — bloated image causes deployment timeout: A team deployed a 2.4GB Python image (single-stage, with gcc, build headers, and test dependencies). During a rolling update on Kubernetes, the image pull took 90 seconds per node. With 15 nodes and a 2-minute readiness timeout, 8 nodes failed to pull the image in time, causing the rollout to fail. The fix was a multi-stage build that reduced the image to 220MB — pulls now complete in 8 seconds.

# ── Stage 1: Builder ─────────────────────────────────────────────
FROM python:3.12 AS builder
WORKDIR /build

# Install build dependencies (won't be in final image)
RUN apt-get update && apt-get install -y gcc libpq-dev

COPY requirements.txt .
RUN pip install --user --no-cache-dir -r requirements.txt

# ── Stage 2: Runtime (minimal) ───────────────────────────────────
FROM python:3.12-slim AS runtime
WORKDIR /app

# Copy only the installed packages from builder — not gcc, not apt cache
COPY --from=builder /root/.local /root/.local
COPY . .

RUN useradd --create-home appuser && chown -R appuser /app
USER appuser

ENV PATH=/root/.local/bin:$PATH
EXPOSE 8000
CMD ["uvicorn", "main:app", "--host", "0.0.0.0", "--port", "8000"]

Volumes — Persisting Data Beyond Container Lifetime

Containers are ephemeral by design — when a running container stops, everything written to its filesystem is lost. For stateful applications (databases, file uploads, logs), you need volumes.

Named volumes: Docker Daemon manages the storage location. Survives container restarts and removals. Best for databases and multiple containers that need to share data.

Bind mounts: Mount a host directory into the container. Great for developers working on software development workflows where code changes need to reflect immediately without rebuilding the container image. Not recommended for production — ties the container to host filesystem paths.

tmpfs mounts: Stored in host memory only. Useful for sensitive temporary data that must not persist to disk.

Failure scenario — bind mount in production causes data loss: A team ran PostgreSQL in Docker with a bind mount: -v /data/postgres:/var/lib/postgresql/data. During a server migration, they copied the container but forgot to copy /data/postgres on the host. The new container started with an empty bind mount — PostgreSQL initialized a fresh database, overwriting nothing (the old data was on the old host). But the team thought the data was 'in Docker' and deleted the old server. All production data was lost. The fix: use named volumes (docker volume create) which are managed by Docker and backed up explicitly, not bind mounts that depend on host filesystem awareness.

Performance impact: Named volumes use Docker's storage driver (overlay2 by default) which is optimized for container workloads. Bind mounts go through the host filesystem, which may use different I/O schedulers and caching. For database workloads, named volumes on SSD-backed storage outperform bind mounts by 10-20% on write-heavy benchmarks.

# ── Named volume (production databases) ──────────────────────────
docker volume create postgres_data

docker run -d \
  --name postgres \
  -e POSTGRES_PASSWORD=secret \
  -v postgres_data:/var/lib/postgresql/data \
  -p 5432:5432 \
  postgres:16

# Data persists even after removing the container:
docker rm postgres
docker run -d \
  --name postgres_new \
  -e POSTGRES_PASSWORD=secret \
  -v postgres_data:/var/lib/postgresql/data \
  postgres:16
# Same data — the volume survived the container removal

# ── Bind mount (software development) ───────────────────────────
docker run -d \
  --name dev_app \
  -v $(pwd):/app \
  -p 8000:8000 \
  myapp:latest
# Edit code on the docker host → changes reflected in container immediately
# No docker build required during development

Docker Compose — Orchestrating Multiple Containers

Real applications built by developers are never one container. A REST API needs a database. A background worker needs a message queue. A web application needs a cache layer. Docker Compose defines and runs multi-container applications — what Docker Inc. calls 'multi container applications' — with a single YAML file and a single command.

Docker Compose handles networking between containers automatically: every service defined in docker-compose.yml can reach every other service by its service name. Your web container reaches the database at db:5432, not localhost:5432 — Docker's internal DNS resolves service names to container IP addresses.

Failure scenario — depends_on does not wait for readiness: A team used depends_on: db to ensure the database started before the web service. But depends_on only waits for the container to start, not for the database to accept connections. The web service started, tried to connect to PostgreSQL before it was ready, and crashed. The team saw intermittent failures on every docker compose up. The fix: add a healthcheck to the database service and use depends_on: condition: service_healthy.

Networking gotcha — default bridge network isolation: Docker Compose creates a default network for all services in the same docker-compose.yml. But containers from different docker-compose.yml files are on different networks and cannot communicate by default. To connect services across compose files, create an external network and attach both compose files to it.

version: '3.9'

services:
  # ── Web application ──────────────────────────────────────────
  web:
    build: .
    ports:
      - "8000:8000"
    environment:
      - DATABASE_URL=postgresql://user:password@db:5432/myapp
      - REDIS_URL=redis://redis:6379
    depends_on:
      db:
        condition: service_healthy
      redis:
        condition: service_started
    restart: unless-stopped

  # ── PostgreSQL database ───────────────────────────────────────
  db:
    image: postgres:16-alpine
    environment:
      POSTGRES_USER: user
      POSTGRES_PASSWORD: password
      POSTGRES_DB: myapp
    volumes:
      - postgres_data:/var/lib/postgresql/data
    healthcheck:
      test: ["CMD-SHELL", "pg_isready -U user -d myapp"]
      interval: 10s
      timeout: 5s
      retries: 5

  # ── Redis cache ───────────────────────────────────────────────
  redis:
    image: redis:7-alpine
    command: redis-server --maxmemory 256mb --maxmemory-policy allkeys-lru

volumes:
  postgres_data:

Container Orchestration — Docker Swarm and Beyond

Docker Compose handles multiple containers on a single docker host. When you need containers running across multiple machines — for high availability or scale — you need container orchestration.

Docker Swarm: Docker's built-in container orchestration mode. Turn multiple Docker hosts into a cluster with docker swarm init. Supports service scaling, rolling updates, and automatic container rescheduling when a node fails. Simpler than Kubernetes, suitable for smaller deployments.

```bash # Initialize a swarm docker swarm init

# Deploy a service across the swarm (3 replicas) docker service create --replicas 3 --name myapp -p 8000:8000 myapp:1.0.0

# Scale up docker service scale myapp=5

# Rolling update docker service update --image myapp:2.0.0 myapp ```

Kubernetes vs Docker Swarm: Docker Swarm is simpler to operate. Kubernetes has a larger ecosystem and is the standard for production container orchestration at scale — used by Amazon ECS alternatives, Google GKE, and Azure AKS. AWS Fargate takes this further: run containers without managing any servers or clusters at all — you define the container, AWS Fargate handles the infrastructure.

Docker containerization at scale requires orchestration. For most application development teams: start with Docker Compose locally, Docker Swarm for small production deployments, Kubernetes (or a managed service like Amazon ECS or AWS Fargate) for large-scale production.

When to graduate from Swarm to Kubernetes: If you need custom resource definitions, advanced networking (service mesh, network policies), sophisticated autoscaling (HPA, VPA, KEDA), or a large ecosystem of operators and tools — Kubernetes is the answer. If you need simple rolling updates and basic scaling on 3-10 nodes, Swarm is sufficient and far simpler to operate.

Production Best Practices — What Separates Senior from Junior Docker Usage

Experienced developers follow these Docker containerization rules religiously.

1. Never use :latest in production. FROM python:latest or image: postgres:latest will silently upgrade on your next deployment and potentially break your application. Always pin exact versions: python:3.12.3-slim, postgres:16.2-alpine.

2. Scan images for vulnerabilities. docker scout quickview myimage or integrate Trivy into your CI pipeline. Docker images accumulate CVEs as base operating system packages age.

3. Use .dockerignore. Excluding node_modules, .git, __pycache__, .env from the build context prevents accidentally shipping secrets and dramatically speeds up docker build.

4. Set resource limits. A running container with no resource limits can consume all docker host resources and crash other services. Always set --memory and --cpus in production, or use Docker Compose deploy.resources limits.

5. Implement health checks. The Docker Daemon and Kubernetes use health checks to know when a running container is ready to receive traffic and when it needs to be restarted.

6. Store secrets in secrets managers, not env vars or images. ENV SECRET_KEY=abc123 in a Dockerfile bakes the secret into every layer of the container image — it appears in docker history. Use Docker secrets, AWS Secrets Manager, or Vault.

7. Run as non-root. The USER instruction in a Dockerfile is not optional in production. Running as root inside a container means a container escape gives the attacker root on the host.

8. Use read-only filesystems where possible. --read-only flag makes the container filesystem read-only. Writable paths (tmp, logs) use tmpfs mounts. This prevents an attacker from writing binaries or modifying application code inside the container.

9. Log to stdout/stderr, not files. Docker captures stdout/stderr and makes it available via docker logs. Logging to files inside the container requires a volume mount and a log rotation strategy. Let Docker handle log collection.

# .dockerignore — what NOT to send to Docker Daemon during docker build
.git
.gitignore
__pycache__
*.pyc
*.pyo
.pytest_cache
.coverage
htmlcov/
.env
.env.*
*.env
node_modules/
npm-debug.log
.DS_Store
docker-compose*.yml
Dockerfile*
README.md
docs/
tests/
*.test.py
Coverage/

What Is Docker? — The Only Definition That Matters

Docker is a tool that bundles your application with every dependency it needs into a single, portable unit called a container. That's it. No magic. No hypervisor.

Here's why that matters: when you ship a container, you ship the exact OS libraries, the exact runtime version, the exact config files. The environment on the target machine becomes irrelevant. You stop debugging "works on my machine" because your machine travels with the app.

Docker uses kernel namespaces and cgroups (not a full OS) to isolate processes. That means containers start in milliseconds, not minutes. They use a fraction of the RAM a VM would. And they don't require you to provision an entire guest OS for every service.

If you're still thinking of containers as "lightweight VMs," stop. That mental model will lead to design mistakes. A container is a process with boundaries. Treat it like one.

// io.thecodeforge — devops tutorial

# Process tree on a host running 3 containers
# vs 3 VMs on the same hardware

# CONTAINERS (shared kernel):
#   PID 1: systemd (host kernel)
#   PID 245: /docker-containerd
#     PID 312: nginx (container 1)
#     PID 344: postgres (container 2)
#     PID 376: node app (container 3)

# VIRTUAL MACHINES (separate kernels):
#   Host PID 1: systemd
#   Hypervisor: runs 3 full OS instances
#   Each VM: boots init, systemd, sshd, cron, etc.
#   Total overhead: ~500MB - 1GB per VM

# Container startup: 50-200ms
# VM startup: 30-90 seconds

Why Docker Is Essential for DevOps — The Real Reason

DevOps is about removing friction between writing code and running it in production. Docker eliminates the #1 friction point: environment drift.

Your laptop runs macOS. Your CI server runs Ubuntu 22.04. Your production runs Amazon Linux 2023. Without Docker, each of those environments requires its own setup scripts, package managers, and hours of troubleshooting when something breaks.

With Docker, you write one Dockerfile. That file produces an image that behaves identically on every platform that runs Docker. Your CI pipeline builds the image once, then deploys the same artifact to staging and production. No recompilation. No "but it passed in CI" incidents.

Docker also forces you to declare dependencies explicitly. That Node.js app that worked because the host happened to have Python 2.7? It fails during the image build, not in production at 3 AM. That's the whole point: fail fast, fail in your pipeline, fail before customers see it.

If you're not using Docker in your CI/CD pipeline, you're spending 30% of your time on environment issues. That's not DevOps. That's manual ops with a fancy title.

// io.thecodeforge — devops tutorial

# Minimal CI pipeline using Docker
# Build once, deploy everywhere

stages:
  - build
  - test
  - deploy

build:
  stage: build
  script:
    - docker build -t registry.thecodeforge.io/payment-api:${CI_COMMIT_SHA} .
    - docker push registry.thecodeforge.io/payment-api:${CI_COMMIT_SHA}

test:
  stage: test
  script:
    - docker run registry.thecodeforge.io/payment-api:${CI_COMMIT_SHA} npm test

deploy:
  stage: deploy
  script:
    - docker pull registry.thecodeforge.io/payment-api:${CI_COMMIT_SHA}
    - docker run -d --restart=always -p 8080:8080 \
        registry.thecodeforge.io/payment-api:${CI_COMMIT_SHA}

A Simple Docker Workflow — Build, Ship, Run, Repeat

Stop reading theory. Here's the actual workflow you'll use every day:

Step 1: Write your application code. Could be anything — a Python API, a Rust binary, a static site. Doesn't matter.

Step 2: Write a Dockerfile. This is a recipe that tells Docker how to build your image. Start FROM a base image (Alpine is ~5MB, Ubuntu is ~70MB, pick wisely). COPY your code in. RUN any build steps. Define the CMD that starts your app.

Step 3: Run docker build -t my-app:latest .. This executes your Dockerfile and produces an immutable image. Think of it like a compiled binary — you can't change it after it's built without rebuilding.

Step 4: Run docker run -d -p 8080:8080 my-app:latest. Docker creates a new container from your image. The -d flag detaches it (runs in background). The -p maps host port 8080 to container port 8080.

That's it. You just containerized an application. Now you can ship that image to a registry, pull it on a server, and run it identically. No dependencies to install. No version conflicts. No surprises.

// io.thecodeforge — devops tutorial

# Step 1: app.py (simple Flask API)
# from flask import Flask
# app = Flask(__name__)
# @app.route('/health')
# def health():
#     return {"status": "ok"}

# Step 2: Dockerfile
FROM python:3.12-alpine
WORKDIR /app
COPY requirements.txt .
RUN pip install --no-cache-dir -r requirements.txt
COPY app.py .
CMD ["python", "app.py"]

# Step 3: Build it
# $ docker build -t health-api:v1.0 .

# Step 4: Run it
# $ docker run -d --name health-api \
#   --restart=unless-stopped \
#   -p 8080:5000 \
#   health-api:v1.0

Docker’s Solution

Docker doesn't just package code — it solves the most painful friction in DevOps: environment inconsistency. Before Docker, junior developers would fight with 'it works on my machine' issues, debugging missing libraries, differing OS versions, and conflicting dependencies. Docker's container image is an immutable, versioned snapshot of your entire runtime environment — from the base OS layer to every package and configuration file. This guarantees that the exact same environment runs on your laptop, the CI server, and production. The real power is not the container itself but the contract it enforces: the Dockerfile defines exactly what the environment looks like, eliminating drift entirely. Combined with registries like Docker Hub or ECR, teams can share, version, and audit environments as easily as source code. For DevOps pipelines, this means the build stage produces a single artifact that behaves identically everywhere, cutting deployment failures by an order of magnitude.

// io.thecodeforge — devops tutorial
name: docker-build-and-push
on:
  push:
    branches: [main]
jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3
      - name: Login to DockerHub
        run: echo "${{ secrets.DOCKER_PASSWORD }}" | docker login -u "${{ secrets.DOCKER_USERNAME }}" --password-stdin
      - name: Build image
        run: docker build -t myapp:${{ github.sha }} .
      - name: Push immutable image
        run: docker push myapp:${{ github.sha }}

Why Containers Win Over Virtual Machines

The core architectural difference is that containers share the host OS kernel, while virtual machines run a full guest OS with a hypervisor. This means containers are lightweight, starting in milliseconds compared to VMs that may take minutes to boot. Resource overhead is minimal — a single host can run hundreds of containers vs. tens of VMs. But the real DevOps advantage is density plus speed. Docker uses copy-on-write layers, so base images are shared across containers, reducing disk usage drastically. For microservices, this is transformative: each service runs in its own isolated container with predictable resource limits, yet the host overhead is nearly zero. CI/CD pipelines that used to take 20 minutes with VMs can finish in under 2 minutes with containers because there's no OS boot per stage. The trade-off is security isolation — containers provide process-level isolation, not hardware-level. This makes containers perfect for trusted workloads or with proper security contexts, but VMs still win for multi-tenant environments with untrusted code.

// io.thecodeforge — devops tutorial
services:
  web:
    image: nginx:alpine
    deploy:
      resources:
        limits:
          cpus: '0.5'
          memory: 256M
        reservations:
          cpus: '0.25'
          memory: 128M
  api:
    image: myapi:1.2.3
    deploy:
      resources:
        limits:
          cpus: '1.0'
          memory: 512M
    depends_on:
      - db
  db:
    image: postgres:15-alpine
    volumes:
      - pgdata:/var/lib/postgresql/data
volumes:
  pgdata: