Containerization and Docker Fundamentals Questions

I use Docker daily for packaging services with a focus on minimal images, reproducible builds, and runtime security.

Typical production-grade Dockerfile (multi-stage, non-root, pinned base):

# build stage
FROM golang:1.20-alpine AS builder
WORKDIR /src
COPY go.mod go.sum ./
RUN go mod download
COPY . .
RUN CGO_ENABLED=0 GOOS=linux GOARCH=amd64 go build -ldflags="-s -w" -o /app ./cmd/service

# final stage
FROM gcr.io/distroless/static:nonroot
USER nonroot
COPY --from=builder /app /app
EXPOSE 8080
ENTRYPOINT ["/app"]

Optimizations I apply

• Choose minimal base (distroless/alpine) and pin versions to avoid drift.
• Multi-stage builds to keep build toolchain out of final image.
• Strip binary symbols (-ldflags "-s -w") and remove package manager caches during build.
• Reduce layers by combining RUN steps, enable image scanning (Trivy/Snyk), and apply user namespaces / non-root USER to reduce attack surface.

Secrets & credentials

• Never bake secrets into images. Use runtime secret stores: Kubernetes Secrets with RBAC, HashiCorp Vault + CSI driver, or AWS Secrets Manager with IAM roles.
• Mount secrets as tmpfs or environment variables injected at deploy-time; prefer short-lived tokens and encryption at rest/in-transit.
• Scan images for accidental secrets with git-secrets or Repo pre-commit hooks.

Production issue (example)
Situation: A CPU spike and OOMs after a release where container used default JVM memory settings.
Action:

• Rolled back deployment, examined image and container metrics (Prometheus + Grafana).
• Rebuilt image to include proper JVM flags (Xmx/Xms) and healthcheck; added resource requests/limits in Kubernetes and liveness/readiness probes.
• Added probe-based rollout and Canary deployment pipeline; added alerting on container OOMKilled and CPU saturation.
  Result: Resolved stability, prevented recurrence via CI gate that validates resource settings and exposes metrics for new images. Learned to validate runtime defaults and enforce resource constraints before rollout.

Strategy
For a slow-starting service with flaky dependencies, I’d separate “is the process alive?” from “is it ready to serve traffic?” and add a startup probe so the orchestrator doesn’t kill the pod too early.

Checks

• Liveness: only verifies the process is not wedged. Keep it cheap and dependency-free.
• Readiness: verifies the service can handle requests, including critical dependencies or internal initialization.
• Startup probe: allows several minutes of boot time before liveness begins.

Dependency handling
Readiness should fail if a required dependency is down, but the app should continue retrying in the background rather than exiting. That prevents crash loops during a temporary outage.

Logs and metrics

• Log startup phases: config load, migrations, cache warmup, dependency checks.
• Emit metrics for startup duration, readiness transitions, dependency failures, and probe latency.
• Alert on repeated readiness failures, not on brief single failures during deploys.

Trade-off
I’d keep health endpoints simple and deterministic. If readiness is too strict, deployments become fragile; if it’s too loose, broken pods receive traffic. The right balance is fast liveness, realistic readiness, and a generous startup probe.

A tag is a human-friendly label for an image, like api:1.2.3 or latest. A digest is the cryptographic content hash of the image, like sha256:..., which identifies the exact artifact.

Why digests are more reliable

• Tags can be moved to point to different images.
• Digests are immutable: the same digest always means the same image content.
• Deployments pinned to digests are reproducible across environments.

Example:

myapp:latest   -> mutable, may change over time
myapp@sha256:abc123... -> exact image, stable and auditable

For SRE, I prefer digest pinning in production because it prevents surprise deployments when a tag is overwritten. Tags are still useful for release workflows and readability, but digests are better for rollback, compliance, and proving that staging and prod ran the same artifact.

Writing logs to stdout and stderr is recommended because containers are meant to be ephemeral. If an app writes to local files, those logs may disappear when the container is restarted unless extra storage is configured.

Operational benefits for SRE

• Centralized collection by the platform or log agent
• Easier correlation across replicas and environments
• No need to manage per-container log files
• Better support for autoscaling and immutable deployments
• Simpler incident response because logs flow into a single observability pipeline

Example: in Kubernetes or Docker-based platforms, the runtime can capture stdout/stderr and forward them to Elasticsearch, Loki, CloudWatch, or another aggregator. That gives me searchable logs without SSHing into hosts.

I’d still keep logs structured, include request IDs, and avoid excessive noise. The main idea is to treat logs as a stream for aggregation, not as local files trapped inside an ephemeral container filesystem.

I’d restructure the build so the most stable inputs are copied first and the expensive compile step happens as late as possible.

Recommended approach:

• Separate dependency manifests from application code
• Cache Maven/Gradle dependencies in an early layer
• Copy source files after dependencies are resolved
• Use .dockerignore to exclude target/, .git/, docs, and local files
• Build a reusable base image for common Java dependencies if the repo is large

Example pattern:

FROM maven:3.9-eclipse-temurin-21 AS build
WORKDIR /app
COPY pom.xml .
RUN mvn -q dependency:go-offline
COPY src ./src
RUN mvn -q package -DskipTests

If only source files change, Docker reuses the dependency layer instead of downloading everything again. In CI, I’d also mount a Maven cache directory and avoid invalidating it with unrelated files. For a monorepo, I’d split modules so changes in one service don’t rebuild every artifact. The goal is to make the cache reflect actual dependency boundaries, not just directory structure.