DevOps / Intermediate: controlled delivery systems / Lesson 7

Container images and runtime boundaries

Distinguish image construction from running processes, and reason about isolation, writable data, identity, and resource limits.

About 4 min readContent reviewed 2026-10-25

On this page

Lesson goals

Distinguish image metadata from runtime behavior.
Review process identity, networks, and data persistence.
Explain container health and graceful termination assumptions.

An image is not a running service

A container image packages a filesystem and execution metadata. A running container adds a process, runtime configuration, namespaces, mounts, and resource policy. Containers commonly share the host kernel; they are not identical to virtual machines or complete security boundaries. An image that builds successfully may still fail to start, connect, or handle traffic. Record the image identity and runtime settings separately. The course uses Dockerfile concepts and Linux container assumptions, while actual engine behavior and supported options depend on the selected Docker or compatible runtime release.

Build a narrow context

The build context contains files the builder may access. Exclude repository metadata, local secrets, caches, and unrelated output through a reviewed .dockerignore. The first example is a short Dockerfile for a project that supplies app.py; it is intentionally not runnable here because that application and image retrieval are outside the lesson. The versioned base tag is readable but mutable, so a real release policy must select a reviewed digest and update it deliberately. Copy only required files, use an explicit working directory, and avoid putting credentials into instructions or layers.

dockerfile Illustrative Linux-container Dockerfile

FROM python:3.13-slim
WORKDIR /app
COPY app.py /app/app.py
USER 10001:10001
EXPOSE 8080
CMD ["python", "/app/app.py"]

The project must provide app.py and appropriate access. EXPOSE declares intent only. The mutable base tag is a teaching choice, not a production digest policy; no image is fetched or built.

Understand startup and identity

Exec-form commands avoid an unnecessary shell layer and make signal delivery easier to reason about. The application still needs to handle termination and release resources. Run with a nonroot identity when compatible with required access, and grant only necessary filesystem permissions. EXPOSE is image metadata; it does not publish a port or make the application bind an interface. The process must listen on the documented address and port, and the runtime or platform must provide the intended network mapping. A successful local port mapping says nothing about a remote service policy.

Keep persistent state outside disposable layers

A container’s writable layer is not a durable backup. Decide which data is temporary, which belongs on managed persistent storage, and how it is restored consistently. The second example lists synthetic runtime assumptions and explicitly separates ephemeral scratch space from persistent application data. Mounting a host path can expose host files and bypass image assumptions, so review it as a privilege boundary. Resource limits also need measurement: memory exhaustion or CPU throttling can resemble application defects. Do not remove every limit to hide a symptom; compare workload demand with the intended resource contract.

yaml Synthetic runtime review record

identity: nonroot-application-user
listen: documented-container-interface:8080
scratch: ephemeral-and-size-bounded
application-data: managed-persistent-storage
shutdown: drain-before-termination
resources: measured-request-and-limit-policy

This provider-neutral record separates packaging from runtime obligations. It is not a Docker Compose or Kubernetes manifest and does not mount any host path.

Verify the artifact and the runtime contract

Review image contents, dependency and base-image updates, startup behavior, health semantics, and shutdown separately. Test with the intended architecture and user identity in an authorized disposable environment. Record image provenance and scan results, while remembering that scans cover known findings rather than proving safety. Keep a compatible previous artifact for recovery and avoid mutable latest tags in release records. A container improves packaging consistency only when the surrounding configuration, data, network, and access boundaries are also explicit. No host engine, service, or container is started by these examples.

Common errors and fixes

EXPOSE does not make a port reachable

Why it happens: Metadata was confused with process binding and network mapping.
How to fix it: Inspect each boundary in the selected runtime context.
Prevent it next time: Document bind, service port, and external routing separately.

Data disappears after replacement

Why it happens: Important state lived only in the disposable writable layer.
How to fix it: Recover from verified storage or backup and correct persistence design.
Prevent it next time: Rehearse replacement and restore with synthetic state.

Termination cuts off requests

Why it happens: Signal handling and drain behavior were untested.
How to fix it: Use a clear process entry and bounded graceful shutdown.
Prevent it next time: Include shutdown in artifact acceptance checks.

Check your understanding

1. A Dockerfile says EXPOSE 8080, but the application listens only on container loopback. What is missing?

Show worked solution

Image metadata does not change the application’s bind address. Verify the intended container interface and runtime routing from the caller’s context. Repair configuration according to the platform contract; publishing a host port alone cannot make an incorrectly bound process accept the intended traffic.

2. Why should a local credentials file be excluded even when the Dockerfile never copies it explicitly?