Containers

The inventory service works on Ana's laptop with Java 21.0.4 and fails on Bruno's with Java 17; the staging server has a different time zone; production has an older libc. Every environment is a slightly different machine, and every difference is a bug waiting for a deploy. A container packages the application together with everything it needs to run — runtime, libraries, configuration defaults — into one immutable artifact that behaves the same on a laptop, in CI and in a Kubernetes cluster.

Containers are processes, not small VMs

A virtual machine (VM) emulates hardware: each VM boots its own kernel on top of a hypervisor. A container is an ordinary Linux process that the kernel isolates and limits. All containers on a host share the host's kernel.

flowchart TB
    subgraph VMs["Virtual machines"]
        direction TB
        hw1["Hardware"] --> hv["Hypervisor"]
        hv --> g1["Guest OS kernel"] --> a1["catalog"]
        hv --> g2["Guest OS kernel"] --> a2["inventory"]
    end
    subgraph CT["Containers"]
        direction TB
        hw2["Hardware"] --> k["Host OS kernel<br/>namespaces + cgroups"]
        k --> c1["catalog<br/>(process)"]
        k --> c2["inventory<br/>(process)"]
    end

Two kernel features do the work⁴:

Because the isolation is weaker, cloud providers that run other customers' containers on shared hosts wrap them in lightweight VMs (AWS Firecracker under Lambda and Fargate, gVisor under Google Cloud Run). For your own services on your own nodes, plain containers are the norm.

What an image is

An image is a read-only template from which containers are started. The Open Container Initiative (OCI) standardizes its format, so an image built with Docker runs on containerd, CRI-O or Podman¹. An OCI image is:

• a list of layers — compressed tar archives, each holding the file-system changes of one build step;
• a config — environment variables, the default command, the user, exposed ports;
• a manifest that lists the config and the layers by their digests (SHA-256 hashes of the content).

flowchart LR
    m["Manifest<br/>sha256:9f2c…"] --> cfg["Config<br/>ENTRYPOINT, USER, ENV"]
    m --> l1["Layer 1: base OS files<br/>(distroless / Alpine)"]
    m --> l2["Layer 2: Java runtime"]
    m --> l3["Layer 3: dependencies (jars)"]
    m --> l4["Layer 4: application classes"]

Layers are content-addressed and shared: ten BoxOffice services built on the same base image store and download the base layers once. When a container starts, the runtime stacks the read-only layers with an overlay file system and adds a thin writable layer on top — which disappears with the container. That is why state must live in volumes or backing services.

Tags move, digests do not

boxoffice/inventory:1.8.3 is a tag: a human-friendly pointer that anyone with push rights can move to another image. boxoffice/inventory@sha256:9f2c… is a digest: it identifies exactly one content. Production deployments should reference digests (or immutable tags enforced by the registry) so that "the image we tested" is provably "the image we run".

A production Dockerfile for a BoxOffice service

The catalog service is a Spring Boot 4 application on Java 21. A naive Dockerfile copies the source and runs Maven inside the final image — producing a large image that contains the compiler, the Maven cache and the source code. A multi-stage build compiles in one stage and copies only the result into a minimal runtime stage²:

# ---- build stage: JDK + Maven, discarded at the end ----
FROM maven:3.9-eclipse-temurin-21 AS build
WORKDIR /src
# 1. dependencies first: this layer is cached until pom.xml changes
COPY pom.xml .
RUN mvn -q dependency:go-offline
# 2. then the source code, which changes on every commit
COPY src ./src
RUN mvn -q package -DskipTests \
 && java -Djarmode=tools -jar target/catalog.jar extract --layers --launcher --destination target/extracted

# ---- runtime stage: only a JRE, no shell, non-root ----
FROM gcr.io/distroless/java21-debian12:nonroot
WORKDIR /app
# Spring Boot layers: rarely-changing first, application classes last
COPY --from=build /src/target/extracted/dependencies/ ./
COPY --from=build /src/target/extracted/spring-boot-loader/ ./
COPY --from=build /src/target/extracted/snapshot-dependencies/ ./
COPY --from=build /src/target/extracted/application/ ./
ENV JAVA_TOOL_OPTIONS="-XX:MaxRAMPercentage=75 -XX:+ExitOnOutOfMemoryError"
EXPOSE 8080
USER nonroot
ENTRYPOINT ["java", "org.springframework.boot.loader.launch.JarLauncher"]

Each line has a reason:

Add a .dockerignore (with target/, .git/, *.log, .env) so the build context sent to the builder stays small and secrets do not leak into layers.

docker build -t boxoffice/catalog:1.4.0 catalog/
docker image ls boxoffice/catalog            # check the size
docker run --rm -p 8080:8080 --memory=512m --cpus=1 \
  -e SPRING_DATASOURCE_URL=jdbc:postgresql://db:5432/catalog boxoffice/catalog:1.4.0

# syntax=docker/dockerfile:1

# ---- build stage: compile with Maven inside a JDK image -------------------
FROM maven:3.9-eclipse-temurin-21 AS build
WORKDIR /src
COPY pom.xml .
COPY src ./src
# the cache mount keeps ~/.m2 between builds: dependencies are downloaded once
RUN --mount=type=cache,target=/root/.m2 mvn -B -q package -DskipTests

# ---- runtime stage: only a JRE and the jar --------------------------------
FROM eclipse-temurin:21-jre
WORKDIR /app
RUN useradd --system --uid 10001 app
COPY --from=build /src/target/app.jar app.jar
USER app
EXPOSE 8082
# use up to 75% of the container's memory limit for the heap
ENTRYPOINT ["java", "-XX:MaxRAMPercentage=75", "-jar", "app.jar"]

Graceful shutdown: the other half of disposability

When Kubernetes replaces a pod it sends SIGTERM, waits terminationGracePeriodSeconds (30 s by default), then sends SIGKILL. A service that dies instantly drops every in-flight request — including someone's payment. Spring Boot handles it with two properties:

server:
  shutdown: graceful            # stop accepting, finish in-flight requests
spring:
  lifecycle:
    timeout-per-shutdown-phase: 20s

Registries and the supply chain

Images are stored in a registry (Docker Hub, GitHub Container Registry, Amazon ECR, Google Artifact Registry, Harbor). Because an image is everything that will run in production, the path from source to registry — the software supply chain — is an attack target. The minimum hygiene for BoxOffice's pipeline⁵:

The Network & security class discusses supply-chain security in depth; the Delivery page wires these steps into the CI pipeline.

Docker Compose: the whole system on one machine

Compose describes a multi-container application in one YAML file. For BoxOffice it is the local development and test environment, not the production platform:

services:
  catalog:
    build: ./catalog
    environment:
      SPRING_DATASOURCE_URL: jdbc:postgresql://db:5432/boxoffice
      SPRING_DATA_REDIS_HOST: redis
    depends_on:
      db: { condition: service_healthy }
    deploy:
      resources:
        limits: { cpus: "1.0", memory: 512M }
  db:
    image: postgres:17
    environment:
      POSTGRES_DB: boxoffice
      POSTGRES_PASSWORD: ${DB_PASSWORD}
    healthcheck:
      test: ["CMD-SHELL", "pg_isready -U postgres"]
      interval: 5s
      retries: 10
    volumes: [ "pgdata:/var/lib/postgresql/data" ]
  redis:
    image: redis:8-alpine
volumes:
  pgdata: {}

Services find each other by service name (db, redis) through Compose's internal DNS — never localhost, which inside a container means the container itself. Compose has no multi-host scheduling, no self-healing across machines and no rolling updates; when you need those, you need an orchestrator — the subject of the next page.

Trade-offs

How it connects

flowchart LR
    NS["namespaces + cgroups"] --> CT["container =<br/>isolated process"]
    IMG["OCI image: layers,<br/>config, manifest"] --> CT
    IMG --> DIG["digest, not tag:<br/>build once, promote"]
    DIG --> DEL["CI and GitOps<br/>→ Delivery"]
    IMG --> SC["scan, SBOM, sign<br/>→ Network & security"]
    CT --> MEM["memory limit → OOMKilled<br/>JVM MaxRAMPercentage"]
    CT --> SIG["SIGTERM, graceful shutdown<br/>→ safe rolling updates"]
    MEM --> K8S["pods, probes, limits<br/>→ Kubernetes"]
    SIG --> K8S
    CMP["Docker Compose:<br/>local environment"] --> CT
    CT --> VM["Firecracker, gVisor<br/>under FaaS → Compute"]

Palette components: app (every BoxOffice service is an image) · worker · serverless (containers wrapped in micro-VMs). Scenarios: scale-out (small images start replicas fast), serverless-burst (cold starts). Continues in: Kubernetes, Delivery, Network & security — supply-chain security, Compute — serverless and autoscaling, Hands-on 1 — container.