CCNA Container Image Building Questions

Chaining with `&&` executes both commands within one RUN instruction, producing a single image layer and satisfying the layer-minimisation constraint. The shell only proceeds to `dnf install` if `dnf update` succeeds, so failures halt the build rather than silently continuing. This is standard Containerfile syntax.

`podman image build` is the fully qualified form of the build command, invoking Buildah's image-building engine to read a Containerfile and produce a local image. It satisfies the stem's requirement for a valid Podman build command, functioning identically to `podman build` but with the explicit `image` subcommand namespace.

ENV sets a persistent environment variable that remains available to processes at build and runtime within the image. Unlike ARG, which applies only during the build, ENV satisfies the requirement for a persistent APP_PORT value of 8080 in the Containerfile.

Placing the CA in /etc/pki/ca-trust/source/anchors/ and running update-ca-trust regenerates the consolidated trust store, so the container trusts the internal registries and repositories required behind the corporate firewall. This satisfies the stem's custom CA constraint by installing the certificate into the system trust bundle at build time.

A scratch image contains no libraries or system files, so a dynamically linked binary cannot resolve its interpreter or glibc dependencies at runtime, producing 'file not found'. Statically compiling the Go binary with CGO disabled removes those external dependencies.

Multi-stage builds let earlier stages compile and build, while the final stage copies only the binary and required runtime libraries. Build tools, source and caches are excluded, shrinking the production image and reducing its exploitable attack surface.

COPY transfers files or directories from the build context into the image filesystem, without ADD's URL fetching or tar auto-extraction. It satisfies the stem's requirement for an instruction that copies build-context content into the container image.

ENTRYPOINT fixes the executable, while CMD supplies default arguments that a user can override at runtime by appending values to `podman run`. This pairing satisfies the stem's requirement for defaults with override flexibility, unlike CMD alone, which is fully replaced when arguments are passed.

RUN accepts both forms: shell form executes via `/bin/sh -c`, while exec form runs the command directly without a shell. This satisfies the stem's requirement for instructions supporting either syntax, since RUN genuinely permits both, unlike CMD or ENTRYPOINT where the distinction affects signal handling and argument passing.

The exec form runs the executable directly without a shell, allowing it to receive signals like SIGTERM from Podman and forward arguments correctly. This is critical for graceful shutdown and proper argument handling. The shell form wraps the command in /bin/sh -c, which can interfere with signal propagation and argument forwarding, so switching to exec form is a best practice.

EXPOSE documents the network ports a container listens on at runtime, functioning as metadata for image consumers and tooling. It satisfies the stem's requirement for declaring listening ports, unlike RUN or CMD, which execute commands rather than record port information.

ENV values are baked into the image configuration and exported to the container's process environment at runtime, so the application can read configuration such as database hosts without rebuilds. ARG would not survive into the running container.

Minimal trusted base images shrink the installed package set, directly reducing the vulnerability surface and satisfying least privilege by removing unnecessary software. Fewer components mean fewer exploitable paths and less to patch, which is the mechanism that limits attacker opportunity.

Multi-stage builds let earlier stages carry compilers, SDKs and build dependencies, while the final stage copies only the finished artefacts. This keeps the production image minimal, since heavyweight build tooling never ships in the runtime layer, directly reducing image size.

Using curl/wget in a RUN instruction gives granular control over downloads, headers, and cache handling.

WORKDIR sets the working directory for subsequent RUN, CMD, ENTRYPOINT, COPY and ADD instructions, satisfying the stem's requirement to affect all following instructions. Unlike cd inside a single RUN, it persists across build stages and layers, so later instructions resolve relative paths from that directory.

SOURCE_DATE_EPOCH sets a fixed Unix timestamp that Podman's build tooling applies to file metadata, replacing build-time clocks. This yields byte-identical layers across rebuilds, satisfying the reproducibility constraint and enabling deterministic image digests for supply chain verification.

Each FROM instruction begins a fresh build stage with its own base image and filesystem layer, so a single Containerfile can chain several stages. This satisfies the multi-stage requirement that stages remain isolated until explicitly copied between.

ARG declares build-time variables that are available only during the image build, not at container runtime. This satisfies the stem's requirement to define variables within a Containerfile, since ARG instructions set values consumed by subsequent build steps such as RUN, without persisting into the running container's environment.

FROM specifies the base image that subsequent Containerfile instructions build upon, and it must be the first non-comment instruction in a valid Containerfile. This satisfies the stem's requirement, because podman build cannot construct a layered image without an initial parent image reference.

ENV sets a persistent environment variable that remains in the image metadata, so it is available both during subsequent build steps and at container runtime. This directly satisfies the stem's requirement for a variable present across build and run, unlike ARG, which exists only at build time.

COPY transfers files from the build context on the host into the image filesystem during a build. ADD also copies but additionally handles remote URLs and archive extraction, so COPY is the precise instruction for plain local file transfer into the container.

The --no-cache flag tells podman to bypass the layer cache entirely and execute every instruction in the Containerfile from scratch, producing fresh layers even for unchanged instructions. It does not delete the local image or the stored cache; it simply instructs this build to avoid reusing cached layers, so the newly fetched repository metadata is honored during the RUN that installs packages.

Placing base dependencies before source code maximizes cache reuse.

The COPY instruction supports the --from flag, which references a previous build stage by its name or index. Here, `builder` is the named stage, so COPY --from=builder pulls the compiled artifact from that stage's filesystem into the final image. This keeps the final image minimal because only the binary is transferred, not the entire build toolchain.

In exec form the executable becomes PID 1 directly, so signals such as SIGTERM sent by Podman reach the application itself. This enables correct signal handling and graceful termination, unlike shell form where a shell intercepts them.

The COPY --from=builder instruction pulls artefacts from the named earlier build stage rather than the build context, copying the compiled binary at /app into the final runtime image. This satisfies the multi-stage requirement to exclude build tooling from production.

This approach separates dependency installation from application code copying. Podman caches each instruction layer. Since dependencies change infrequently, their layer remains cached when only code changes, avoiding reinstallation. The COPY of code invalidates subsequent layers, but dependencies are already cached. This optimizes rebuild time and is a best practice for leveraging build caching effectively.

COPY transfers files from the build context or a stage into the image filesystem, satisfying the requirement to bring external data in. ADD performs the same transfer with extra archive and URL handling. Both are distinct from RUN, which executes commands inside the build.

ENTRYPOINT fixes the executable, while CMD supplies default arguments that a user can replace by appending values to `podman run`. This satisfies the stem's requirement for overridable defaults, since arguments passed on the command line replace CMD entirely but leave ENTRYPOINT intact.

WORKDIR sets the working directory used by subsequent RUN, CMD, ENTRYPOINT, COPY and ADD instructions in the Containerfile, persisting across later layers. This directly satisfies the stem's requirement for the instruction that establishes that directory context.

USER sets the user name, UID, group name and GID applied when running subsequent RUN, CMD and ENTRYPOINT instructions, plus the container's runtime identity. It changes execution identity only, not file ownership, which requires separate handling.

The USER instruction sets the execution identity for subsequent RUN, CMD and ENTRYPOINT instructions within the image, satisfying the stem's requirement to switch from root to the non-privileged 'appuser' account. Unlike WORKDIR or ENV, USER changes the UID/GID context, so later build steps and container runtime processes run unprivileged.

ADD unpacks a recognised local compressed tar archive (gzip, bzip2 or xz) directly into the destination path, satisfying the stem's requirement for a distinguishing characteristic. COPY merely transfers files verbatim, performing no extraction, so archive handling is an axis unique to ADD.

EXPOSE documents the ports the containerised process listens on, letting Podman and other tooling know which network ports are intended for publication. It satisfies the stem's requirement by declaring runtime listening intent as image metadata, though it does not itself publish the port or alter firewall rules.

ARG declares variables that are available only during the build and can be referenced in instructions like RUN to influence what gets installed. This is appropriate for values such as a version or a package channel that affect the build result. The value is not persisted as a runtime environment variable, so it does not leak into the running container unless explicitly re-declared.

Rootless builds run inside user namespaces, so root within the container maps to an unprivileged host UID. Privileged operations and host volume mounts are therefore constrained, since the build process lacks real host root privileges.

CMD supplies the default command executed when a container starts, and it is overridden by arguments passed at runtime. This satisfies the stem's requirement for a default execution parameter, complementing ENTRYPOINT, which defines the fixed executable that CMD arguments feed into.

FROM declares the base image from which subsequent build steps run, and it must be the first instruction in a stage. It satisfies the stem because every later instruction, such as RUN or COPY, executes against the filesystem and metadata established by that base image.

The -f flag overrides podman build's default Containerfile lookup, pointing it at dockerfiles/Customfile. The trailing dot supplies the build context, so podman reads instructions from that named file while resolving COPY and ADD paths relative to the current directory, satisfying both the non-standard filename and subdirectory location.

Docker caches each layer keyed on the instruction and its inputs. If COPY requirements.txt sits after a layer whose content or timestamps change, that layer's cache invalidates, forcing the subsequent RUN to re-execute even though requirements.txt itself is unchanged.

The RUN instruction executes shell commands during a build stage and commits the resulting filesystem changes as a new image layer. Package updates and dependency installs therefore persist in the final image, unlike CMD or ENTRYPOINT, which only define runtime behaviour.

ARG declares a build-time variable that exists only during image construction, so the VERSION value can be referenced by RUN instructions in the Containerfile. Unlike ENV, it is not persisted into the running container, satisfying the build-time-only constraint in the stem.

Exec form passes the command as a JSON array, so the process runs directly as PID 1 without a shell wrapper. It therefore receives Unix signals such as SIGTERM itself, enabling graceful shutdown, whereas shell form spawns a shell that intercepts signals.

Each RUN instruction creates an immutable layer; deleting files in a later layer only adds a whiteout marker, leaving the original bytes in the earlier layer and thus in the final image. Combining download, install, cache removal and cleanup in one RUN prevents those bytes from ever being committed.

Frequently changing instructions such as COPY of source code invalidate the cache for that layer and every layer after it. Putting them last confines cache invalidation to the final steps, so earlier dependency layers remain reusable across rebuilds.

COPY --chown sets ownership at copy time, so the file lands in the image layer already owned by developer:devgroup. This satisfies the stem's efficiency constraint by avoiding a separate RUN chown instruction, which would create an extra layer and duplicate the file's data.

LABEL adds arbitrary key-value metadata to the image, and maintainer is a commonly recognized key for contact information. The data becomes part of the image configuration and is visible through podman inspect, which is exactly the documentation goal described. Multiple LABEL instructions or a single instruction with several key=value pairs can be used.

Container image layers cache by instruction order, so a COPY of frequently changing configuration files near the top invalidates every subsequent layer, forcing application installation to rebuild each time. Moving volatile files later preserves caching for the expensive, stable application code layers.

ADD handles both local paths and remote URLs, and automatically extracts a local tar archive into the destination. COPY only copies files and never unpacks archives, so it cannot satisfy the automatic-unpacking constraint for the /app directory.

--build-arg passes a named variable into the build at run time, letting a Containerfile consume values such as versions or credentials without hard-coding them. It satisfies the stem's requirement for specifying build arguments, distinct from --tag, which names the resulting image.

EXPOSE is metadata only; it records the port the image intends to listen on, informing users and tooling. It does not publish the port or alter runtime networking, which requires -p or -P at container start.

Build secrets mount the key only during the RUN instruction via a temporary filesystem, so it never persists in image layers or history. This satisfies the requirement to pass the API key without exposing it in the resulting image.