Day 38 Theory — Docker and Production Packaging

Why packaging matters

A Python application that works on one developer laptop is not yet a deployable production artifact.

The machine may accidentally provide:

• the right Python version,
• globally installed libraries,
• local configuration files,
• writable directories,
• credentials,
• system packages that were never documented.

If production depends on those hidden assumptions, deployment becomes unpredictable.

A container image gives us a repeatable package containing the application filesystem and runtime metadata needed to start the process.

Docker does not make weak software reliable. It makes the software packaged in a repeatable form so the same artifact can move through environments.

Image versus container

These words are often mixed together.

An image is a packaged, immutable set of filesystem layers plus metadata.

A container is a running process created from an image with runtime configuration and isolation supplied by the container runtime/operating system.

Dockerfile
    |
    v
docker build
    |
    v
Image
    |
    v
docker run / orchestrator
    |
    v
Container process

Think of the image as the packaged artifact and the container as one execution of that artifact.

A container is still a process

Do not think of a container as a tiny virtual machine.

At runtime, your application is still a process managed by an operating system kernel. Container isolation commonly relies on operating-system mechanisms such as namespaces and resource controls.

This matters because normal process rules still apply:

• signals matter,
• exit codes matter,
• file permissions matter,
• memory limits matter,
• network sockets matter.

Docker changes packaging and isolation; it does not eliminate operating-system behavior.

Dockerfile as a build recipe

A Dockerfile describes how to build the image.

A simplified Python service might look like:

FROM python:3.13-slim
WORKDIR /app
COPY requirements.txt .
RUN pip install --no-cache-dir -r requirements.txt
COPY . .
CMD ["python", "-m", "service"]

Each instruction should exist for a reason.

Ask:

• Which base image do we trust?
• Which files enter the image?
• Which dependency versions are resolved?
• Which user runs the process?
• What command becomes PID 1 inside the container?

Build context and .dockerignore

When Docker builds an image, files in the build context may be available to COPY instructions.

Do not send unnecessary files into the build context.

A .dockerignore can exclude items such as:

.git
.venv
__pycache__
.env
local test output
large temporary artifacts

This improves build efficiency and reduces the chance of accidentally packaging sensitive or irrelevant data.

A .dockerignore is not a substitute for real secret management, but it is part of a disciplined build boundary.

Layers and cache

Image builds are organized into layers. Layer reuse can make rebuilds much faster.

Consider two patterns.

Weak cache pattern:

COPY . .
RUN pip install -r requirements.txt

Any source-code change can invalidate the earlier copy layer and force dependency installation again.

Better pattern:

COPY requirements.txt .
RUN pip install -r requirements.txt
COPY . .

Now changing ordinary application code does not necessarily invalidate the dependency-install layer.

The broader principle is:

Put relatively stable dependency inputs before frequently changing application files when that ordering is correct for your build.

Do not optimize cache at the expense of correctness.

Layer history and secrets

A critical beginner misconception is:

COPY .env /tmp/.env
RUN use-secret /tmp/.env
RUN rm /tmp/.env

and then assuming the secret is gone.

Image layers are content history. Deleting a file in a later layer does not necessarily erase it from earlier image data.

Do not bake credentials into the image in the first place.

Avoid:

• copying .env,
• embedding API keys in source,
• writing secrets into ARG/commands where they can persist in build metadata or layers,
• committing credentials to the build context.

Use approved build-secret mechanisms when a secret is genuinely required during a build, and inject application secrets securely at runtime.

Multi-stage builds

Sometimes build tools are needed to create an artifact but are unnecessary at runtime.

A multi-stage build separates those concerns.

Builder stage
  - compiler
  - development headers
  - build tooling
  - produce artifact
        |
        v
Runtime stage
  - minimal runtime
  - application artifact only

Benefits can include:

• smaller image,
• fewer packages,
• reduced attack surface,
• clearer distinction between build and runtime dependencies.

Do not use multi-stage builds merely because they look “production grade.” Use them when they simplify or harden the runtime artifact.

Run as a non-root user

Running the application as root inside a container gives the process unnecessary privilege inside its isolation boundary.

A safer image normally creates a dedicated runtime user and gives that user only the filesystem permissions the application needs.

Example idea:

RUN adduser --disabled-password --gecos "" appuser
USER appuser

Exact commands vary by base image.

At deployment time, platforms can add further controls such as:

• read-only root filesystem,
• dropped Linux capabilities,
• allowPrivilegeEscalation: false,
• seccomp profiles,
• explicit UID/GID policy.

Container hardening works in layers.

The filesystem should match application needs

If the application only needs to read packaged code and write temporary data to /tmp, do not assume the entire image filesystem must be writable.

Design explicit writable locations for:

• temporary files,
• caches if needed,
• generated runtime artifacts.

Persistent business data should generally live in an appropriate external persistence service or mounted persistent storage—not in the container's ephemeral writable layer by accident.

Reproducible dependencies

A production build should not silently resolve unrelated future dependency versions every time it runs.

Use the dependency-locking strategy appropriate to the Python project.

The goal is:

same source + same declared dependency lock + same build inputs
          -> predictable application artifact

Perfect bit-for-bit reproducibility can require additional controls, but dependency pinning/locking is a foundational step.

Base images are supply-chain dependencies

FROM python:... is not just syntax. The base image becomes part of your software supply chain.

Consider:

• trusted registry/source,
• maintained version,
• vulnerability posture,
• digest pinning strategy where appropriate,
• update/patch process.

A tiny image is not automatically safer if nobody maintains it.

Security is about known, maintained and minimized dependencies—not only image size.

Build once, promote the same artifact

A mature delivery flow avoids rebuilding different application images for test, staging and production from the same source if the intention is to deploy the exact tested artifact.

Conceptually:

commit
  -> CI tests
  -> build image sha256:abc...
  -> scan/verify
  -> staging uses sha256:abc...
  -> production promotes sha256:abc...

Environment-specific configuration should usually be supplied at runtime rather than creating a new application image for every environment.

This gives stronger evidence that production is running what was tested.

Health checks answer different questions

Orchestrators may check several aspects of application health.

Do not collapse them into one endpoint without understanding the semantics.

Conceptually:

• startup — has initialization completed?
• readiness — should this instance receive traffic now?
• liveness — is the process stuck in a state where restart may be appropriate?

For example, temporary model-provider failure may make one feature degraded without necessarily meaning the application process is dead.

Bad health-check design can cause restart loops during external outages.

Signals and graceful shutdown

Containers are expected to stop.

Deployments roll, nodes terminate, autoscalers reduce capacity and operators restart services.

The process should handle termination signals deliberately.

A graceful shutdown sequence may look like:

SIGTERM
   |
   v
stop accepting new work
   |
   v
finish/cancel bounded in-flight work
   |
   v
close connections / flush telemetry
   |
   v
exit before termination deadline

A process that ignores shutdown behavior can drop requests or leave work in uncertain states.

Resource limits affect application behavior

A container can be given CPU and memory constraints.

The application should be tested within realistic limits.

An AI API client that creates unbounded concurrency may exhaust memory or sockets long before CPU reaches 100%.

Packaging is therefore connected to the reliability lessons we already learned.

Local Docker success is not production readiness

A successful:

docker build
docker run

proves something useful: the application can be packaged and started.

It does not prove:

• security,
• scalability,
• correct health semantics,
• disaster recovery,
• authorization,
• good observability,
• safe deployment strategy.

Do not use “Dockerized” as a synonym for “production grade.”

Service Desk connection

Today the Service Desk becomes a releaseable artifact rather than a developer-directory assumption.

The architectural transition is:

Before
------
source code + local Python environment + machine assumptions

After
-----
source
 -> tested build
 -> minimal container image
 -> immutable image identity
 -> runtime configuration/secrets
 -> orchestrated process with health + shutdown behavior

The principle is:

Package the same tested application into a minimal, reproducible, least-privilege image; keep secrets and environment-specific state outside the image; and treat the container as a real production process with explicit health, resources and shutdown behavior.