Containers, Registries, and Cloud-Native Delivery

Introduction

Modern cloud applications are assembled from services that must be built, tested, transported, started, monitored, updated, and sometimes removed rapidly. Traditional deployment approaches often depend on the precise configuration of a server, operating system, runtime, and collection of libraries. Such dependencies can produce the familiar problem that software works in development but fails in testing or production.

Containers address this problem by packaging an application with its required user-space files, libraries, configuration defaults, and startup command. A container image is a portable, immutable description of that package. A container runtime turns an image into an executing process. A registry stores and distributes images. Orchestration platforms coordinate many containers across one or more machines.

Together, these technologies support reproducible cloud delivery. They do not eliminate the need for sound application design, security, testing, or operations. Rather, they provide a standardized unit around which those practices can be organized.

Learning Objectives

By the end of this chapter, you should be able to:

• distinguish containers, images, registries, runtimes, and orchestration platforms;
• explain image layers, tags, digests, and basic image supply-chain risks;
• construct a practical Dockerfile using appropriate instructions;
• describe how a container is started, isolated, configured, and stopped;
• compare local container execution with orchestrated deployment;
• design a simple CI/CD flow for building, scanning, publishing, and deploying images;
• identify operational, security, governance, and cost considerations in cloud-native delivery.

1. The Container Model

A container is an isolated process running on a host operating system. Unlike a virtual machine, a container normally does not include a complete guest kernel. Containers share the host kernel while receiving isolated views of resources such as processes, filesystems, networking, and users.

A virtual machine virtualizes hardware and runs a complete operating system. A container virtualizes the operating-system environment for a process. Consequently, containers are generally faster to start and more resource-efficient than virtual machines, although the degree of isolation and the operational model differ.

The main components are:

A useful conceptual relationship is:

Image + runtime configuration → running container

The image should contain application code and required dependencies, but environment-specific values such as database passwords should normally be supplied at runtime through a secret-management mechanism rather than embedded in the image.

Images and Containers

An image is not a running server. It is a versioned artifact from which one or more containers can be created. Multiple containers may be instantiated from the same image, with each container receiving its own writable runtime layer.

Images are commonly composed of read-only layers. A Dockerfile instruction such as installing packages or copying application files may create a layer. Layers can be reused between images, reducing storage and transfer costs. When a container writes to a path already represented in a read-only layer, the runtime normally records the change in a writable top layer. This design is called copy-on-write.

The writable layer is usually ephemeral. Data that must survive container replacement should be stored in a persistent volume or an external service such as object storage or a managed database.

Tags and Digests

A tag is a human-readable label, such as 1.4.2 or production. Tags are mutable: a registry administrator or build process can make a tag point to a different image. A digest is a content-derived identifier, commonly represented as a cryptographic hash, that identifies a particular image manifest.

For reproducible delivery, a deployment may use a digest rather than relying only on a mutable tag:

registry.example.com/payments/api@sha256:abc123...

Tags remain useful for human communication, while digests provide stronger immutability guarantees. A disciplined system records both the release version and the digest actually deployed.

2. Dockerfiles and Image Construction

A Dockerfile is a text file containing instructions for constructing an image. A simple example is:

FROM python:3.12-slim

WORKDIR /app

COPY requirements.txt .
RUN pip install --no-cache-dir -r requirements.txt

COPY src/ ./src/

RUN useradd --create-home appuser
USER appuser

EXPOSE 8080
CMD ["python", "-m", "src.app"]

This example demonstrates several important principles:

• FROM selects a base image.
• WORKDIR establishes the working directory.
• COPY transfers files into the image.
• RUN executes a build-time command.
• USER avoids running the application as root.
• EXPOSE documents the intended listening port; it does not itself publish the port.
• CMD supplies the default command when a container starts.

Common Dockerfile Instructions

ENTRYPOINT and CMD have different roles. For example:

ENTRYPOINT ["/usr/local/bin/server"]
CMD ["--port", "8080"]

The entry point defines the primary executable, while the command supplies default arguments. The exact override behavior depends on the container tool and invocation syntax, so teams should test it rather than assume that all command-line forms behave identically.

Build Context and .dockerignore

The build context is the set of files made available to the image builder. A context that includes source-control metadata, local credentials, test outputs, or large directories increases build time and can accidentally expose sensitive information. A .dockerignore file should exclude unnecessary content, for example:

.git
.env
__pycache__
node_modules
coverage
*.log

The ignore file is not a complete security boundary. Sensitive data should not be placed in the build context at all, and secrets should be supplied through secure build mechanisms only when genuinely required.

Layering and Build Efficiency

Place stable instructions earlier and frequently changing instructions later. In the example, dependencies are copied and installed before application source code is copied. If only source code changes, the dependency layer may be reused from cache.

A multi-stage build separates compilation from the final runtime image:

FROM golang:1.22 AS build
WORKDIR /src
COPY . .
RUN go build -o /out/service ./cmd/service

FROM gcr.io/distroless/static-debian12
COPY --from=build /out/service /service
USER nonroot:nonroot
ENTRYPOINT ["/service"]

The final image contains the compiled executable rather than the compiler and source tree. This can reduce attack surface and image size, provided the application remains diagnostically supportable.

3. Registries and Image Distribution

A container registry stores image manifests, layers, signatures, and associated metadata. Registries may be public or private and may be operated by a cloud provider, an enterprise, or an independent service.

A typical image reference has the form:

registry.example.com/team/service:2.1.0

The components are the registry host, repository path, and tag. A registry may also retain vulnerability reports, provenance information, access logs, and retention policies.

Pull and Push Operations

A build system typically performs the following sequence:

1. authenticate to the registry;
2. build the image;
3. apply a release tag;
4. run tests and security checks;
5. push the image and metadata;
6. deploy the resulting digest to an environment.

A deployment system then authenticates to the registry, pulls the image onto a suitable node, verifies policy or signatures where configured, and starts a container from that image.

Registry Governance

A professional registry strategy should define:

• who may push images;
• whether repositories are public or private;
• naming and tagging conventions;
• vulnerability scanning requirements;
• image signing and provenance requirements;
• retention and deletion rules;
• geographic replication and availability needs;
• audit logging and emergency access procedures.

Tags such as latest are convenient for experimentation but are weak release identifiers because they do not uniquely identify content. Production delivery should prefer immutable version tags and/or digests.

4. Runtime Concepts

The container runtime performs several operations:

1. obtains the image locally or from a registry;
2. verifies and unpacks image layers;
3. creates namespaces and control groups;
4. constructs the container filesystem;
5. configures networking and mounts;
6. starts the configured process;
7. monitors exit status and resource use.

Linux namespaces provide isolation of process identifiers, networking, mounts, users, and other system views. Control groups, commonly called cgroups, constrain and measure resources such as CPU and memory. These mechanisms provide process isolation, not absolute security. A container escape vulnerability, excessive privilege, or unsafe host configuration can compromise the host.

Process and Lifecycle

A well-designed container normally has one main foreground process. The process receives signals from the runtime and should handle termination gracefully. Applications that ignore termination signals may be killed abruptly, causing incomplete requests or inconsistent temporary state.

A simplified lifecycle is:

Created → Starting → Running → Stopping → Exited
                         ↓
                       Failed

A container should be treated as replaceable. If a process fails, a supervisor or orchestrator may create a new instance. This model encourages stateless application processes and externalized durable data.

Configuration, Secrets, and Health

Configuration commonly enters a container through environment variables, mounted files, command arguments, or platform configuration objects. Environment variables are convenient but may be exposed through process inspection or diagnostic tools. Passwords, tokens, and private keys should be managed by a secrets system with controlled access, rotation, and auditing.

A liveness check asks whether a process should be restarted. A readiness check asks whether it is prepared to receive traffic. These are different questions. Restarting a slow but healthy application because of an incorrectly designed liveness probe can create an outage. A readiness check should normally fail during startup, dependency initialization, or controlled shutdown.

5. Orchestration Basics

Running one container on a developer workstation is straightforward. Operating hundreds of containers requires scheduling, service discovery, health management, rollout control, and resource governance. An orchestrator provides these capabilities.

A typical orchestrated system includes:

• workload definitions, describing desired replicas and images;
• scheduler, selecting suitable compute nodes;
• service discovery, providing stable names for changing instances;
• networking, connecting clients, services, and external gateways;
• health management, replacing failed or unhealthy instances;
• configuration and secrets, separating deployment data from images;
• autoscaling, adjusting capacity according to demand or policy;
• observability, collecting logs, metrics, and traces.

Kubernetes is a widely used orchestration platform. Its central design principle is declarative management: the operator describes the desired state, and controllers work continuously to make the actual state converge toward it.

For example, a simplified deployment might specify an image and three replicas:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: web
spec:
  replicas: 3
  selector:
    matchLabels:
      app: web
  template:
    metadata:
      labels:
        app: web
    spec:
      containers:
        - name: web
          image: registry.example.com/team/web:2.1.0
          ports:
            - containerPort: 8080
          readinessProbe:
            httpGet:
              path: /ready
              port: 8080

A Deployment manages replica replacement and rollout behavior, while a Service commonly provides a stable network endpoint for a changing set of Pods. The precise resource model differs among orchestration products, but the underlying concerns are similar.

Scheduling and Resources

A scheduler places workloads according to available capacity, placement constraints, affinity rules, and resource requests. Resource requests communicate expected reservation needs; limits cap or constrain consumption according to platform behavior.

Overstated requests waste capacity and increase cost. Understated requests can cause contention and unstable performance. Resource values should be based on measurements and revisited after application changes.

Scaling and Rollouts

Horizontal scaling increases or decreases the number of application instances. Vertical scaling changes the resources allocated to an instance. Horizontal scaling is most effective when the service is sufficiently stateless and can share durable state through external systems.

A rolling update gradually replaces old instances with new ones. A blue-green deployment maintains separate old and new environments and shifts traffic between them. A canary deployment exposes a small proportion of traffic to the new version before broader release. These strategies reduce release risk but require reliable health signals, observability, and rollback procedures.

6. Containers in CI/CD

A container-based CI/CD pipeline can be organized as follows:

Commit
  ↓
Static checks and unit tests
  ↓
Build image
  ↓
Image and dependency scanning
  ↓
Integration tests
  ↓
Sign and publish image
  ↓
Deploy to test environment
  ↓
Acceptance and security tests
  ↓
Approval or automated promotion
  ↓
Deploy immutable digest
  ↓
Observe and, if necessary, roll back

The image built for release should be the image tested and promoted. Rebuilding separately for each environment can produce a different artifact and weaken reproducibility. Environment-specific configuration should be injected at deployment time.

A useful release record contains the source commit, image digest, build system identity, test results, dependency information, scanner results, approval evidence, and deployment time. This record supports incident investigation and auditability.

Reproducibility

Reproducibility means that a documented source state and controlled build process produce an equivalent artifact. Absolute bit-for-bit reproducibility can be difficult when dependencies, timestamps, network resources, or base images change. Practical controls include:

• pinning important dependencies and base-image versions;
• recording image digests;
• using lockfiles;
• controlling build inputs;
• avoiding network-dependent behavior during late build stages;
• generating software bills of materials;
• retaining build logs and provenance.

Reproducibility is not the same as immutability. An image can be immutable after publication while still having been produced by an uncontrolled or poorly documented process.

7. Security and Governance

Container security is a lifecycle concern rather than a single scanning step.

Build-Time Controls

Use trusted base images, remove unnecessary tools, update dependencies, scan for known vulnerabilities, and prevent secrets from entering image layers. A vulnerability scanner reports matches against databases; its result requires interpretation. A vulnerable package may be unreachable, while a supposedly low-severity weakness may be critical in a particular exposed service.

Runtime Controls

Run as a non-root user when possible, drop unnecessary Linux capabilities, apply a read-only root filesystem where practical, restrict network access, and use resource limits. Keep the host kernel and runtime patched. Use separate identities for build, deployment, and application operations.

Supply-Chain Risks

Risks include malicious dependencies, compromised base images, unauthorized registry pushes, dependency confusion, poisoned build agents, and tag replacement. Controls may include signed images, verified provenance, private registries, protected branches, least-privilege credentials, isolated builders, and admission policies that reject unapproved images.

Security decisions must balance control with operational reality. A highly restrictive policy that teams cannot use may encourage workarounds. Governance should therefore provide approved paths, clear exception procedures, monitoring, and periodic review.

8. Illustrative Case: A Retail Order Service

Background

A small retailer operates an order API on manually configured virtual machines. Developers test against different library versions, releases require an operations engineer to copy files, and rollback is slow.

Problem

The team needs a repeatable release process for a Python API and a worker that processes payment events. The API must scale horizontally, while payment data must remain outside the container filesystem.

Analysis

The application has two independently scalable processes. Packaging both in one container would couple their scaling and restart behavior. The team therefore chooses separate images for the API and worker, using a shared dependency policy and common observability conventions.

Approach

The team:

1. writes Dockerfiles with pinned dependency lockfiles;
2. uses a multi-stage or minimal runtime image where practical;
3. excludes local credentials through .dockerignore and build controls;
4. runs unit, integration, and image vulnerability tests in CI;
5. publishes immutable release tags and records digests;
6. stores payment state in a managed database and event queue;
7. deploys the API and worker as separate orchestrated workloads;
8. defines readiness and liveness checks independently;
9. uses a rolling deployment with an automated rollback threshold;
10. collects logs, request metrics, queue depth, and deployment events.

Configuration such as database endpoints is supplied by the deployment environment. Secrets are retrieved from a managed secret store. The API image is tested once and promoted from testing to production by digest rather than rebuilt.

Outcome

Releases become repeatable, rollback can restore the previous digest, and API replicas can scale without multiplying worker processes unnecessarily. The team also discovers that observability is essential: without queue-depth and payment-failure metrics, a technically successful deployment could still damage business operations.

Learning Points

The case illustrates that containers are not merely a packaging convenience. They establish a release unit, but reliable delivery also requires externalized state, controlled configuration, health signals, security policy, monitoring, and tested rollback procedures.

9. Challenges and Limitations

Containers can introduce new complexity. A distributed system may contain many images, services, networks, credentials, and deployment policies. Debugging a failed request may require correlating logs and traces across several containers.

Other limitations include:

• persistent storage requires deliberate design;
• shared-kernel isolation is not identical to virtual-machine isolation;
• image scanning produces findings that require judgment;
• orchestration platforms have substantial learning and operating costs;
• poorly sized workloads waste resources or become unstable;
• mutable tags and undocumented manual changes undermine reproducibility;
• excessive abstraction can hide the behavior of the underlying application.

Containers should therefore be adopted because they solve a defined delivery or operational problem, not because they are fashionable. For a simple application, a managed platform or serverless service may be more appropriate than operating a full orchestrator.

10. Contemporary Developments

Cloud-native delivery increasingly emphasizes platform engineering, software supply-chain security, and policy automation. Organizations are adopting internal developer platforms that provide approved templates for building, scanning, deploying, and observing services. Software bills of materials help identify which applications depend on a vulnerable component. Provenance frameworks record how an artifact was built.

Service meshes may provide traffic management, identity, encryption, and telemetry between services, but they also add operational complexity. WebAssembly and other lightweight execution technologies are being explored for selected workloads, although containers remain a dominant general-purpose packaging model.

Artificial intelligence can assist with log classification, anomaly detection, test generation, and incident investigation. It should not be treated as an authority: generated deployment changes require review, and sensitive logs must be handled according to privacy and security policy. AI tools can also generate insecure Dockerfiles or expose secrets if given inappropriate context.

Best Practices Checklist

• Build small, focused images from maintained base images.
• Pin or otherwise control important dependencies.
• Keep secrets out of Dockerfiles, source code, and image layers.
• Use non-root execution and least privilege.
• Separate build, test, and deployment identities.
• Scan images and dependencies, then assess findings in context.
• Promote the tested artifact rather than rebuilding for production.
• Prefer immutable digests for production deployment.
• Externalize durable data and environment-specific configuration.
• Define meaningful readiness and liveness behavior.
• Instrument applications before depending on automated rollout.
• Test rollback and document ownership for failures.
• Apply registry retention, access control, and audit policies.

Chapter Summary

Containers package applications and their user-space dependencies into portable execution units. An image is an immutable artifact, whereas a container is a running instance created by a runtime. Images are composed of layers and are distributed through registries using tags and content digests. Dockerfiles define image construction, and good practices include small trusted bases, efficient layering, multi-stage builds, non-root execution, and careful exclusion of sensitive files.

A runtime creates isolation and manages process, filesystem, network, and resource behavior, but containers are not an absolute security boundary. Orchestrators extend the model by scheduling workloads, maintaining replicas, providing service discovery, applying health checks, scaling services, and controlling rollouts. CI/CD pipelines should build, test, scan, sign, publish, and deploy the same immutable artifact while injecting configuration and secrets at runtime.

Reliable cloud-native delivery depends on more than packaging. It requires reproducibility, observability, secure supply-chain controls, durable-state design, appropriate resource management, governance, and tested rollback. Containers are valuable when they make these practices clearer and more repeatable, not when they merely add another layer of technology.

Key Terms

Container: An isolated operating-system process created from an image.

Container image: An immutable package containing application files, dependencies, metadata, and startup information.

Container runtime: Software that creates, starts, monitors, and stops containers.

Dockerfile: A declarative text file containing image-build instructions.

Layer: A reusable read-only filesystem change forming part of an image.

Copy-on-write: A mechanism that records container changes in a writable layer while preserving image layers.

Registry: A service that stores and distributes container images and related metadata.

Tag: A human-readable image label that may be changed to reference different content.

Digest: A content-derived identifier for a particular image manifest.

Build context: Files made available to an image builder.

Multi-stage build: A build using separate stages so that build tools need not remain in the final image.

Namespace: An operating-system isolation mechanism that gives a process a restricted view of resources.

Control group: A kernel mechanism for limiting and measuring resource use.

Orchestrator: A platform that schedules and manages containers across infrastructure.

Readiness probe: A check indicating whether an instance should receive traffic.

Liveness probe: A check indicating whether an instance should be restarted.

Rolling update: A deployment strategy that gradually replaces old instances with new ones.

Software bill of materials: An inventory of components and dependencies in a software artifact.

Image provenance: Evidence describing how and from which inputs an image was built.

Immutable deployment: A deployment that references a fixed artifact rather than modifying a running instance.

Review Questions

Short Answer Questions

1. What is the difference between a container image and a running container?
2. Why is a digest generally more reliable than a mutable tag for production deployment?
3. What is the purpose of a .dockerignore file?
4. Distinguish a readiness probe from a liveness probe.
5. Why should durable application data normally be stored outside a container's writable layer?

Long Answer Questions

1. Explain how a Dockerfile, image registry, runtime, and orchestrator cooperate in a cloud deployment.
2. Discuss the security risks of running containers and describe practical controls at build and runtime.
3. Explain how image layers and multi-stage builds can improve delivery efficiency and reduce attack surface.
4. Compare rolling, blue-green, and canary deployment strategies.
5. Describe the major stages of a secure container CI/CD pipeline and explain why the tested artifact should be promoted rather than rebuilt.

Analytical / Application Questions

1. A team deploys an image tagged production, but a rollback later retrieves different content from the same tag. Diagnose the design weakness and propose a corrected release process.
2. An orchestrated service repeatedly restarts during a slow five-minute startup. Its application is healthy after startup. Analyze whether the liveness or readiness configuration is likely incorrect and propose changes.
3. A payment worker stores temporary transaction state only in the container filesystem. The orchestrator replaces the container during scaling. Analyze the likely consequence and recommend an architecture that preserves required state.

Multiple Choice Questions with Answers

Question 1

Which statement best distinguishes a container image from a container?

A. An image is a running process, while a container is a registry repository.

B. An image is an immutable package, while a container is a running instance of that package.

C. An image is always a virtual machine, while a container is always serverless.

D. An image stores only passwords, while a container stores application code.

Correct Answer: B. An image is an immutable package, while a container is a running instance of that package.

Question 2

Why are production deployments commonly pinned to an image digest?

A. A digest identifies a particular image content and is not dependent on a mutable label.

B. A digest automatically encrypts all application data.

C. A digest makes an application independent of its operating-system kernel.

D. A digest eliminates the need for testing.

Correct Answer: A. A digest identifies a particular image content and is not dependent on a mutable label.

Question 3

What does the EXPOSE instruction in a Dockerfile primarily do?

A. It publishes a port to the public internet.

B. It encrypts traffic on the specified port.

C. It documents the port on which the application is expected to listen.

D. It creates a database connection.

Correct Answer: C. It documents the port on which the application is expected to listen.

Question 4

Which practice most directly reduces the size of a final compiled application image?

A. Copying the entire source repository into the final image

B. Using a multi-stage build

C. Running the application as root

D. Adding development tools to the runtime stage

Correct Answer: B. Using a multi-stage build

Question 5

What is the main purpose of a readiness probe?

A. To determine whether an instance should receive traffic

B. To calculate the image digest

C. To build a new image layer

D. To authenticate to the registry

Correct Answer: A. To determine whether an instance should receive traffic

Question 6

Which storage approach is most appropriate for data that must survive container replacement?

A. The container's temporary writable layer

B. A random file in the build context

C. A persistent volume or external durable service

D. A Dockerfile comment

Correct Answer: C. A persistent volume or external durable service

Question 7

What is a principal function of an orchestrator?

A. Replacing all application source code with configuration

B. Scheduling and maintaining container workloads across infrastructure

C. Guaranteeing that every dependency is vulnerability-free

D. Converting containers into physical servers

Correct Answer: B. Scheduling and maintaining container workloads across infrastructure

Question 8

Which item should generally not be embedded in a container image?

A. A startup command

B. Application libraries

C. A confidential database password

D. A compiled application binary

Correct Answer: C. A confidential database password

Question 9

A CI/CD system builds an image, tests it, publishes it, and then rebuilds from source for production. What is the main concern?

A. The production artifact may differ from the tested artifact.

B. The registry will necessarily delete the test image.

C. The application cannot use environment variables.

D. The orchestrator cannot perform rolling updates.

Correct Answer: A. The production artifact may differ from the tested artifact.

Question 10

Which control helps reduce the risk of unauthorized image use in an orchestrated environment?

A. Allowing every user to push to production repositories

B. Using admission policies and verified image provenance

C. Using only the mutable tag latest

D. Disabling registry audit logs

Correct Answer: B. Using admission policies and verified image provenance