Production Deployment, Cloud and Orchestration

Introduction

A Docker image that runs correctly on a developer workstation is not automatically ready for production. Production deployment introduces requirements for reliability, security, observability, controlled change, cost management and recovery from failure. A production container must operate as part of a wider system: images are built and signed, configuration is supplied safely, traffic is routed, data is protected, health is measured and capacity is adjusted as demand changes.

This chapter examines the transition from single-host Docker use to production platforms. It distinguishes Docker Compose, Docker Swarm and Kubernetes; evaluates cloud registries and managed container services; and develops practical approaches to scaling and high availability. The central design principle is that orchestration is not simply “running more containers”. It is the systematic management of desired state, placement, networking, security, updates and recovery.

Learning Objectives

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

1. Prepare a Docker workload for production deployment.
2. Explain the roles and limitations of Docker Compose, Swarm and Kubernetes.
3. Select an appropriate cloud registry and managed container platform.
4. Design basic scaling, health-checking and high-availability strategies.
5. Evaluate operational, financial, security and governance consequences of deployment choices.
6. Apply production deployment principles to a realistic case.

1. From Container Image to Production Service

A container image is an immutable package containing an application and its runtime dependencies. A production service is a continuously operated system with additional concerns:

• Availability: the service remains usable despite expected component failures.
• Performance: response time and throughput remain within agreed limits.
• Security: identities, secrets, images, networks and host systems are protected.
• Operability: engineers can observe, update, troubleshoot and recover the service.
• Repeatability: the same version can be deployed consistently across environments.
• Governance: changes, access and data processing satisfy organisational and legal requirements.

A useful distinction is between deployment and release. Deployment places an artifact in an environment; release makes that artifact available to users. A team may deploy version 2.4 to production, perform tests, and release it gradually to 10% of users. This distinction supports canary and blue–green strategies.

1.1 Production-readiness checklist

Before deployment, teams should verify the following.

A container should normally perform one principal service function. This does not prohibit helper containers, but combining unrelated processes in one container makes health management, scaling and logging more difficult.

1.2 Immutable artifacts and image provenance

A robust pipeline builds an image once and promotes that same image through testing, staging and production. Deploying by a mutable tag such as latest weakens traceability because the tag may refer to different content at different times. A digest identifies content more precisely, for example image@sha256:....

Image provenance includes the source revision, builder, dependencies and build time. Software bills of materials (SBOMs) record included components, while signing mechanisms allow a deployment system to verify that an image came from an authorised process. Vulnerability scanning is valuable, but it is not a complete security assessment: a scanner can report a vulnerable library while missing insecure application logic or an unsafe runtime configuration.

1.3 Configuration and secrets

Configuration should be separated from the image. Typical configuration includes database endpoints, feature flags and timeouts. Secrets include passwords, private keys and tokens. Secrets should be stored in a dedicated secret-management system or orchestrator secret facility, encrypted in transit and at rest, and exposed only to the workload that needs them.

A secret injected as an environment variable may be easier to use, but it can accidentally appear in diagnostic output or process metadata. Mounted secret files or a secrets API may reduce that risk. Rotation must be designed in advance: applications should tolerate a new credential being issued without requiring an unsafe manual rebuild.

1.4 Health and graceful termination

Three behaviours are often confused:

• Startup: whether an application has completed initialisation.
• Readiness: whether it can receive traffic now.
• Liveness: whether it is functioning sufficiently to remain running.

A slow-starting application should not be restarted merely because it is not yet ready. Conversely, a ready endpoint should not report success if the application cannot perform essential work. On termination, the process should stop accepting new work, complete or cancel in-flight work according to policy, and then exit within the platform’s grace period.

2. Deployment Models and the Orchestration Problem

A single Docker host is simple and useful for development or small internal services, but it creates a substantial failure domain. If the host, its storage or its network fails, all services may become unavailable. Manual placement also becomes error-prone as the number of services increases.

An orchestrator maintains a desired state. An operator might specify that three replicas of a web service should run, each using a particular image and network policy. The orchestrator compares desired and observed states, then schedules or replaces workloads to reduce the difference. This is a reconciliation loop.

Figure: An orchestrator repeatedly compares desired and observed state and takes corrective action.

The model is powerful but not magical. It cannot make an application stateless, repair corrupted data, or guarantee availability when all nodes share one failed power domain. High availability therefore requires coordinated application, infrastructure and operational design.

3. Compose, Swarm and Kubernetes

These technologies overlap but solve different problems.

3.1 Docker Compose

Docker Compose describes a multi-container application, commonly in YAML. It is particularly effective for local development, integration testing, demonstrations and small single-host deployments. A Compose file can define services, networks, volumes, environment variables, dependencies and health checks.

Compose is not normally a multi-node production orchestrator. A restart policy can restart a process on one host, but it does not provide the scheduling, cluster quorum, broad policy model or ecosystem associated with Kubernetes. Compose remains valuable because its declarative service description is readable and convenient, and because developers can reproduce dependencies such as databases and message brokers locally.

3.2 Docker Swarm

Swarm is Docker’s integrated cluster mode. It provides managers, worker nodes, services, replicas, an overlay network, service discovery and rolling updates. Its close integration with Docker makes it comparatively approachable for teams already using Docker CLI and Compose-style definitions.

Swarm can be appropriate for modest clusters where simplicity and a limited operational surface are priorities. Its ecosystem and industry adoption are smaller than Kubernetes’. Teams should assess long-term support, available skills, cloud integration and monitoring tools before selecting it for a strategic platform.

3.3 Kubernetes

Kubernetes is a platform for managing containerised workloads across a cluster. Its main abstractions include:

• Pod: the smallest schedulable unit; normally one application container, possibly with tightly coupled sidecars.
• Deployment: manages replicated, replaceable application Pods and rollout history.
• Service: provides a stable virtual endpoint and selects Pods by labels.
• Ingress or Gateway: represents external HTTP routing, usually through an implementation such as a controller.
• ConfigMap and Secret: hold non-secret configuration and sensitive values, subject to appropriate protection.
• StatefulSet: supports workloads requiring stable identities or storage relationships.
• DaemonSet: places a workload on selected nodes, often for agents.
• Job and CronJob: run finite or scheduled work.
• Namespace: provides a logical boundary for organisation and policy, not a complete security boundary by itself.

Kubernetes offers extensive scheduling, autoscaling, policy and extension capabilities. Its cost is complexity. A team must operate or purchase control-plane services, understand networking and storage, manage upgrades, and establish reliable observability. Kubernetes is not automatically the best choice for every application.

3.4 Comparative decision table

The correct choice depends on workload complexity, team capability, regulatory requirements, expected growth and the organisation’s tolerance for platform operations. “More powerful” does not mean “more suitable”.

4. Cloud Registries and Managed Container Platforms

A container registry stores and distributes images. A cloud registry commonly provides private repositories, authentication integration, vulnerability scanning, replication, lifecycle policies and audit events. Examples include Amazon Elastic Container Registry (ECR), Azure Container Registry (ACR), Google Artifact Registry and equivalent offerings from other providers.

4.1 Registry selection criteria

Evaluate:

1. Identity integration: Can the registry use the organisation’s identity provider and short-lived credentials?
2. Location and latency: Is the registry near build systems and deployment regions?
3. Replication: Can images be copied across regions or accounts?
4. Retention: Can old tags and unreferenced manifests be removed safely?
5. Security: Are encryption, private endpoints, scanning and signing supported?
6. Auditability: Are pushes, pulls and administrative changes recorded?
7. Availability and recovery: What service guarantees and recovery options exist?
8. Cost: Are storage, data transfer and scanning charges understood?

A registry should not be treated as a permanent archive without a retention design. At the same time, deleting an image still required by a running deployment can complicate rollback. Retention rules should preserve release artifacts for the organisation’s recovery period.

4.2 Managed container execution models

Cloud platforms expose several levels of abstraction:

• Virtual machines: The organisation manages the host operating system and runs Docker or an orchestrator. This provides control but increases maintenance.
• Managed Kubernetes: The provider manages some or all control-plane components; the customer still manages workload configuration and often worker nodes or node pools.
• Serverless containers: The provider abstracts most host management and charges according to allocated or consumed resources, depending on the service.
• Platform-as-a-service container deployment: The platform supplies deployment, routing, scaling and health features with fewer configuration choices.
• Container-based functions: Short-lived event-driven containers are run under a function model, subject to execution-time and runtime constraints.

The trade-off is generally between control and operational burden. A managed service reduces undifferentiated infrastructure work but may create provider-specific dependencies and limit low-level tuning.

5. Scaling and Capacity Planning

Scaling means adjusting service capacity to meet workload demand. Vertical scaling increases resources for an instance; horizontal scaling adds instances or replicas. Horizontal scaling normally improves resilience as well as capacity, but only if the application and its dependencies support concurrent operation.

5.1 Resource estimation

A simple first approximation for stateless replicas is:

where:

• N is the minimum number of replicas needed for average service capacity;
• λ is the incoming request rate in requests per second;
• μ is the sustainable request-processing rate of one replica in requests per second;
• ⌈ ⌉ means round upward to the next whole replica.

This estimate assumes approximately independent replicas, balanced traffic, stable request cost and no bottleneck elsewhere. It does not by itself guarantee an acceptable response time. Queueing effects, burst demand, database capacity and failure headroom must also be considered.

Worked example. Suppose peak demand is 180 requests per second and one replica sustainably handles 75 requests per second. Then:

Three replicas provide nominal processing capacity of 225 requests per second. If one replica must be able to fail while peak demand continues, a simple N+1 policy requires four replicas, subject to validation through load testing. This is a planning approximation, not a service-level guarantee.

For CPU capacity, if each replica requests 0.5 vCPU and four replicas are required, requested application capacity is:

The cluster must provide additional capacity for system services, daemon agents, scheduling constraints and failure recovery. Memory often becomes the limiting resource before CPU, particularly for runtimes with large heaps or caches.

5.2 Autoscaling signals

Autoscaling may use CPU utilisation, memory, request rate, queue length, latency or a business metric. CPU is convenient but can be misleading: an I/O-bound service may have low CPU while a queue grows rapidly. A queue-based worker should often scale according to backlog and processing time.

Scaling has delay. New instances require image pulls, startup and readiness checks. Therefore, scaling thresholds should be tested against realistic bursts, and minimum capacity should cover ordinary demand. Scale-down should be conservative to avoid oscillation, known as thrashing.

5.3 Statelessness and stateful dependencies

Horizontal scaling is easiest when service instances are stateless. User sessions can be stored in signed tokens or a shared session store; uploaded files should use durable object storage rather than a container’s writable layer. Databases, queues and caches require separate capacity, replication, consistency and backup decisions.

A replicated application does not remove the database as a potential bottleneck. Connection pools must be bounded, schema migrations must be compatible with rolling updates, and retry policies must avoid creating a retry storm. Retries should be limited, use backoff and respect idempotency.

6. High Availability and Resilience

High availability (HA) is an architectural property, not a checkbox. It requires eliminating or reducing single points of failure across the request path:

1. Multiple application replicas.
2. Traffic distribution and health-aware routing.
3. Failure-domain distribution across nodes, zones or regions.
4. Redundant control and data-plane components where required.
5. Durable, replicated data with tested restoration.
6. Monitoring, alerting and an incident response process.

6.1 Availability targets

Availability is often expressed as:

where A is availability, U is observed uptime and D is observed downtime over the measurement period. Both variables must use the same time unit. If a service has 43,180 minutes of uptime and 20 minutes of downtime in a 30-day period, then:

or approximately 99.954% availability. This is an observed measurement, not a prediction. Maintenance definitions, exclusions and dependency failures must be specified in the service-level agreement.

A design target of “three nines” does not mean every component must independently achieve exactly that value. Dependencies combine, and the end-to-end service may be less available than its strongest component. Conversely, redundancy can improve the service, but only when failure independence is credible. Two replicas on the same failed node are not equivalent to two replicas distributed across failure domains.

6.2 Recovery objectives

• RTO (Recovery Time Objective): maximum acceptable time to restore service after a disruption.
• RPO (Recovery Point Objective): maximum acceptable amount of data loss measured in time.

For example, an RPO of 15 minutes means the organisation accepts that, in a severe failure, the latest recoverable data may be up to 15 minutes old. These objectives determine backup frequency, replication design and operational cost.

6.3 Updates and rollback

Rolling updates replace instances gradually and can maintain service capacity if sufficient healthy replicas remain. A safe update requires compatible configuration, readiness checks, controlled surge capacity and a rollback condition. Blue–green deployment runs two environments and switches traffic between them; it simplifies rollback but temporarily requires additional capacity and careful data migration. Canary deployment exposes a small traffic percentage to the new version and compares error rate, latency and business indicators before expansion.

7. Networking, Security and Governance

A production container platform should implement least privilege at several layers:

• Container processes use non-root identities where possible.
• Workload identities replace long-lived cloud keys.
• Network policies restrict service-to-service communication.
• Public ingress is separated from internal service traffic.
• Images are pulled from trusted, access-controlled registries.
• Nodes and control-plane interfaces are patched and private where possible.
• Administrative actions are authenticated, authorised and audited.

TLS should protect external traffic and, where risk warrants it, internal traffic. Certificate issuance and renewal should be automated. Exposing a container port does not by itself make an application secure; it may bypass an intended gateway, authentication layer or policy.

Logs can contain personal data, tokens or business-sensitive information. Teams should define retention, access, redaction and deletion policies. Regulatory obligations may apply to data residency, breach notification, audit records and processing of personal information. A platform’s technical capability does not remove the organisation’s responsibility for lawful processing.

Supply-chain governance should include pinned base images, dependency review, reproducible builds where feasible, signed artifacts, separation of build and production privileges, and rapid response procedures for critical vulnerabilities. Automated scanning should support human risk assessment rather than become an unquestioned deployment gate: a critical issue in unreachable test code may have a different risk from a moderate issue exposed through a public endpoint.

8. Observability and Operations

Observability combines:

• Logs: event records with timestamps, severity, correlation identifiers and useful context.
• Metrics: numerical time series such as request rate, error rate, latency, saturation, replica count and queue depth.
• Traces: causal paths across distributed services.

A practical service dashboard should distinguish user impact from infrastructure symptoms. The four golden signals—latency, traffic, errors and saturation—provide a useful starting point. Alerts should be actionable, prioritised and linked to runbooks. Alerting on every container restart can create noise; alerting on sustained user-visible errors or unavailable capacity is usually more meaningful.

Operational readiness includes deployment records, ownership, escalation paths, backup tests, incident reviews and disaster-recovery exercises. A container platform without these practices can produce highly automated failure rather than reliable service.

9. Illustrative Case: Migrating an Online Learning Service

Background

Consider LearnNow, a fictional online learning provider. Its application consists of a web front end, an API, a background video-processing worker, PostgreSQL, Redis and object storage. Developers currently run the stack with Compose on laptops. A single virtual machine hosts the production application, and releases are performed by manually pulling a mutable image tag.

Problem

During enrolment periods, response times increase and the host occasionally runs out of memory. A host failure causes a prolonged outage. The team cannot determine which image is running, and a deployment can overwrite a working release without a reliable rollback. Video-processing jobs compete with interactive API requests.

Analysis

The web and API layers are suitable for horizontal scaling if sessions and uploaded files are externalised. Video processing is asynchronous and should scale according to queue depth. PostgreSQL is stateful and requires a managed database or a carefully operated HA design. Redis may be used for caching, but the team must decide whether its data is reconstructable. Object storage is more appropriate than container filesystems for videos.

The team selects a managed Kubernetes service because it already has platform expertise, requires multiple workload types and expects future growth. A smaller organisation with no Kubernetes skills might reasonably select a managed serverless container platform instead.

Approach / Solution

1. The CI pipeline builds an image from a pinned base, runs tests and scans dependencies.
2. Each image is tagged with a release identifier and deployed by digest.
3. Images are pushed to a private cloud registry with retention and audit policies.
4. Kubernetes Deployments manage the web and API replicas; a worker Deployment consumes the video queue.
5. Readiness checks prevent traffic reaching an unprepared API; liveness checks detect unrecoverable process failure.
6. Horizontal scaling increases API replicas using demand and resource signals, while worker scaling uses queue backlog.
7. A managed PostgreSQL service supplies backups, multi-zone options and tested restoration procedures.
8. Object storage holds videos; the API issues controlled upload access rather than proxying all large files.
9. Network policies restrict database access to the API and migration jobs.
10. A progressive rollout compares error rate and latency before full release.
11. Logs, metrics and traces are centralised, and alerts link to incident runbooks.
12. Infrastructure and Kubernetes manifests are managed as code and reviewed through pull requests.

Outcome

The service can add API capacity without duplicating the database, and video jobs no longer consume all interactive resources. A failed application Pod is replaced automatically, while node and zone distribution reduce common infrastructure failures. Releases are traceable and reversible. The organisation still must test database restoration, manage cloud costs and rehearse a regional outage; orchestration has reduced risk but has not eliminated it.

Learning points

The important decision was not merely to “move to Kubernetes”. The team separated stateless and stateful concerns, selected scaling signals appropriate to each workload, replaced mutable deployment practices with immutable artifacts, and matched platform complexity to operational capability.

10. Contemporary Developments and Practical Best Practices

The Cloud Native Computing Foundation ecosystem continues to influence container operations through Kubernetes, OpenTelemetry, policy tools, service meshes and supply-chain frameworks. OpenTelemetry supports common instrumentation for logs, metrics and traces. Policy-as-code can enforce requirements such as approved registries or disallowed privileged containers. Software supply-chain frameworks increasingly emphasise provenance and verifiable build claims.

AI-assisted operations can help summarise incidents, identify anomalous metrics or draft configuration, but generated changes require review, testing and access controls. An AI system should not receive unrestricted production credentials or be permitted to apply unreviewed scaling and security changes. Training and operational data may contain confidential information.

Recommended practice is to:

• choose the simplest platform that satisfies reliability and growth requirements;
• build once and promote immutable, identifiable artifacts;
• define resource requests, limits and disruption policies deliberately;
• distribute replicas across genuine failure domains;
• make health checks represent real service conditions;
• test rollback, backup restoration and disaster recovery;
• observe user impact, not just container status;
• use least privilege and short-lived identities;
• document ownership, SLOs, RTO, RPO and escalation procedures;
• review cloud cost, lock-in and operational complexity continuously.

Challenges and Limitations

Containers share the host kernel, so they are not identical to virtual machines as isolation boundaries. Misconfigured privileges, exposed management interfaces or vulnerable runtimes can create serious risk. Orchestrators increase resilience only when applications are designed for replacement and dependencies are managed correctly. Autoscaling can increase costs or overload a database. Multi-region deployment can reduce regional risk while introducing data-consistency, latency and compliance challenges. Managed platforms reduce infrastructure work but may obscure underlying behaviour and complicate migration.

Consequently, production design should be evidence-based. Load tests should approximate realistic traffic; chaos or failure exercises should be controlled; security reviews should include supply chain and identity; and capacity assumptions should be compared with observed metrics. No single tool substitutes for engineering judgement.

Chapter Summary

Production Docker deployment extends beyond packaging an application. It requires immutable and traceable images, secure configuration, health-aware processes, observability, controlled updates and tested recovery. Docker Compose is principally a local and simple single-host tool; Swarm supplies an integrated but narrower cluster model; Kubernetes provides extensive reconciliation, scheduling, networking and scaling capabilities at the cost of greater complexity.

Cloud registries provide controlled image storage, scanning, replication and auditability. Managed container platforms trade infrastructure control for reduced operational burden. Scaling requires attention to workload type, bottlenecks, startup delay and failure headroom. High availability depends on replica distribution, resilient dependencies, data protection, meaningful health checks and operational preparation. Security, privacy, cost and governance must be evaluated alongside technical capability.

Key Terms

Container orchestration: Automated management of container placement, operation, scaling and recovery.

Docker Compose: A declarative tool for defining and running multi-container applications, especially on a local or single host.

Docker Swarm: Docker’s integrated cluster mode for scheduling replicated services across nodes.

Kubernetes: An extensible platform that reconciles desired container workload state across a cluster.

Pod: Kubernetes’ smallest schedulable unit.

Deployment: A Kubernetes controller for managing replicated, replaceable application Pods.

Service: A stable network endpoint that selects workload instances.

Container registry: A repository that stores and distributes container images.

Image digest: A content-derived identifier for an exact image artifact.

Image provenance: Evidence describing where and how an image was built.

Readiness probe: A check indicating whether a workload should receive traffic.

Liveness probe: A check indicating whether a workload should be restarted.

Horizontal scaling: Increasing capacity by adding service instances or replicas.

Vertical scaling: Increasing resources assigned to an instance.

High availability: The ability of a service to remain usable despite specified failures.

RTO: The maximum acceptable time to restore service after disruption.

RPO: The maximum acceptable age of recoverable data after disruption.

Reconciliation loop: Repeated comparison of desired and observed state followed by corrective action.

Progressive delivery: Gradual exposure of a new release through canary or similar methods.

Observability: The ability to understand internal system behaviour from outputs such as logs, metrics and traces.

Review Questions

Short Answer Questions

1. Why is deploying an image by digest more reproducible than deploying by a mutable tag?
2. Distinguish readiness and liveness checks.
3. State one suitable use of Docker Compose.
4. What do RTO and RPO measure?
5. Why can a stateless service usually be scaled horizontally more easily than a stateful database?

Long Answer Questions

1. Compare Docker Compose, Docker Swarm and Kubernetes in terms of scope, complexity, scheduling and appropriate use.
2. Explain how a container image moves from a source repository to a controlled production release.
3. Discuss the security and governance controls required for a cloud container platform.
4. Explain how rolling, blue–green and canary deployments differ, including their principal risks.
5. Describe the components of a high-availability architecture for a containerised web application.

Analytical / Application Questions

1. A service receives 260 requests per second and one replica sustainably handles 85 requests per second. Calculate the minimum nominal replica count using N = ⌈λ ÷ μ⌉. Then explain why the result alone is insufficient for production capacity planning.
2. A team runs three replicas on one host and claims the service is highly available. Critically evaluate the claim and recommend a more credible failure-domain design.
3. Select Compose, Swarm, Kubernetes or a managed serverless container platform for a small organisation operating an API, a queue worker and a managed database. Justify the choice using skills, workload, reliability, cost and future-growth considerations.

Multiple Choice Questions with Answers

Question 1

Which characteristic most directly improves deployment reproducibility?

A. Using the mutable tag latest

B. Deploying an image by content digest

C. Increasing container log verbosity

D. Exposing additional host ports

Correct Answer: B. Deploying an image by content digest

Question 2

What is the primary purpose of a readiness check?

A. To determine whether a workload should receive traffic

B. To encrypt the container filesystem

C. To select the cloud region

D. To build a container image

Correct Answer: A. To determine whether a workload should receive traffic

Question 3

Which technology is primarily intended for local multi-container development and testing?

A. Docker Compose

B. A cloud registry

C. An object-storage bucket

D. A certificate authority

Correct Answer: A. Docker Compose

Question 4

Which Kubernetes object provides a stable virtual endpoint for selected Pods?

A. ConfigMap

B. Service

C. DaemonSet

D. Job

Correct Answer: B. Service

Question 5

A replica handles 50 requests per second and demand is 120 requests per second. Using N = ⌈λ ÷ μ⌉, what is the minimum nominal replica count?

A. 2

B. 2.4

C. 3

D. 4

Correct Answer: C. 3

Question 6

Which scaling signal is often most appropriate for a queue-consuming worker?

A. Queue backlog

B. Container image size

C. Number of source files

D. Registry storage age

Correct Answer: A. Queue backlog

Question 7

What does RPO specify?

A. The maximum acceptable time to restore service

B. The maximum acceptable amount of data loss measured in time

C. The number of replicas required for deployment

D. The time needed to build an image

Correct Answer: B. The maximum acceptable amount of data loss measured in time

Question 8

Which statement about high availability is correct?

A. Two replicas on one failed host eliminate the host as a single point of failure

B. High availability is guaranteed by using Kubernetes alone

C. Replicas should be distributed across credible failure domains

D. Backups are unnecessary when containers are replicated

Correct Answer: C. Replicas should be distributed across credible failure domains

Question 9

What is a principal advantage of a managed container platform?

A. It eliminates all application defects

B. It reduces the organisation’s infrastructure-management burden

C. It guarantees unlimited capacity at no cost

D. It removes the need for access control

Correct Answer: B. It reduces the organisation’s infrastructure-management burden

Question 10

Which deployment method gradually exposes a release to a small proportion of users before wider rollout?

A. Canary deployment

B. Full replacement without testing

C. Image garbage collection

D. Vertical partitioning

Correct Answer: A. Canary deployment