Containers
Containers package an application with its filesystem dependencies and run it with operating-system isolation. They are lighter than virtual machines because containers share the host kernel, but they are not magic sandboxes. Kernel vulnerabilities, excessive privileges, mounted host paths, and weak image hygiene can still compromise systems.
Images and Layers
A container image is built from layers. Each layer records filesystem changes. Smaller, clearer images usually build faster, pull faster, scan faster, and expose less attack surface. Multi-stage builds are common: compile in a build image, copy only the runtime output into a minimal final image.
Tags are names; digests identify content. Production deployments should prefer immutable references or a release process that records the resolved digest.
Runtime Discipline
Production containers should run as non-root where possible, use read-only filesystems when practical, declare CPU and memory expectations, expose health endpoints, and handle termination signals. A container that ignores SIGTERM may fail graceful shutdown during deployment or node maintenance.
Exercise
Inspect a Dockerfile. Identify the base image, user, exposed port, dependency installation step, build cache boundaries, and final runtime command. Then ask whether a vulnerability scanner can explain every package in the final image.
Build Reproducibility
Container builds should be reproducible enough that a team can explain what changed between two images. Pinning base images by digest improves reproducibility, while dependency lockfiles reduce accidental upgrades. Build arguments should be documented because they can change behavior without changing source code.
Layer caching is useful but can hide mistakes. If dependency installation happens before copying source, rebuilds are faster. If the lockfile is not copied correctly, the cache may preserve stale dependencies. A Dockerfile is both packaging logic and operational documentation.
Security Posture
Containers should run with the minimum privileges required. Running as root, adding broad Linux capabilities, mounting the host filesystem, or using privileged mode should require explicit justification. The container boundary is weaker than a virtual-machine boundary when the host kernel is exposed through unnecessary privileges.
Image scanning should be paired with ownership. A vulnerability report with hundreds of findings and no triage model becomes noise. Teams need rules for reachable vulnerabilities, base-image refreshes, exception expiry, and emergency rebuilds.
Runtime Behavior
A containerized application must handle termination. Orchestrators send signals during rollouts, scaling events, and node maintenance. The process should stop accepting new work, finish or checkpoint in-flight work, close connections, and exit within the grace period. Ignoring this behavior creates data loss and failed deploys.
Study Task
Rewrite a Dockerfile using a multi-stage build. In the final stage, include only runtime dependencies, set a non-root user, declare health behavior elsewhere in the deployment, and record the image digest after build. Compare image size and vulnerability count before and after.
Operational Review
Container practice should be reviewed at build time and runtime. At build time, ask whether the Dockerfile is reproducible, minimal, and understandable. At runtime, ask whether the process handles signals, writes logs to standard output, avoids unnecessary privilege, and exposes health information through the platform.
The review should include image freshness. A small image can still contain old vulnerable packages. A large image can still be acceptable if its contents are justified and patched. The real question is whether the team can explain, rebuild, scan, and redeploy the image quickly when a base vulnerability appears.
Containers standardize packaging, but they do not eliminate operations. They move many operational choices into image design and orchestrator configuration.