LPI DevOps Tools Engineer: Application Container

What this domain tests

Application Container covers building, shipping, and running OCI images: Dockerfile authoring, layer caching, registries, volumes, and runtime behavior. The exam expects reasoning about image size, reproducibility, and signal handling - not just running docker build.

Core rules

• An image is an ordered stack of layers. Put rarely changing instructions (base image, package installs) first and source code last, so the cache survives edits.
• Use multi-stage builds: compile with the full toolchain, then COPY --from=build only the artifact into a slim runtime image.
• Pin the base image by tag or digest. FROM node:20-bookworm-slim is reproducible; FROM node:latest is not.
• Use exec-form ENTRYPOINT/CMD (["node","server.js"]) so the process is PID 1 and receives SIGTERM. Shell form lets a shell swallow signals.
• Run as a non-root user with USER, and add a .dockerignore so .git and secrets never enter the build context.
• Treat the container filesystem as ephemeral: named volumes for persistent data, bind mounts for development.

Worked example

A Go service image ships at 1.1 GB. The Dockerfile uses golang:1.22 as the final base, copies the whole repository, and runs go build. Reasoning: the toolchain and source dominate the size. Fix with two stages - FROM golang:1.22 AS build, run go build -o /app, then FROM gcr.io/distroless/static and COPY --from=build /app /app. Copy go.mod/go.sum and run go mod download before copying source so dependency layers cache. Result: roughly 10 MB, fewer CVEs, faster pulls.

Traps

• Baking secrets into ENV or COPY; layers keep them.
• apt-get install without removing /var/lib/apt/lists/* in the same RUN.
• Assuming docker run --rm deletes a named volume - it does not.
• Confusing CMD (defaults, overridable) with ENTRYPOINT (the executable).