14 Containers in the cloud with Microsoft Azure and Google Cloud

This chapter moves from running containers locally to delivering on Docker’s “anywhere” promise with managed container services in the cloud. It explains where these simplified platforms fit compared to full Kubernetes: they’re ideal for straightforward applications with modest scaling and operational needs, offering a developer-like deployment flow without provisioning or managing infrastructure. A central theme is using cloud-hosted private registries close to runtime for secure, fast image pulls, and adopting practical practices around cost awareness, right-sizing compute, and automating ephemeral test environments.

On Azure, the chapter shows how Azure Container Instances (ACI) provide a fast, low-friction way to run single containers with public DNS, logs, and configurable resources—great for CI-driven test environments and quick experiments, with performance tied directly to requested CPU and memory. It then introduces Azure Container Registry (ACR) for private images, covering authentication, imports from public registries, cloud-based image builds with ACR tasks, and multi-arch support. Azure Container Apps (ACA) adds orchestration features—HTTPS ingress, revisions and traffic split, autoscale/scale-to-zero, environment-level domains, secrets, and internal-only routing—and can deploy directly from Docker Compose specs or source, illustrating how to fix typical cross-service communication with updated environment variables, ingress, and secrets. The message: most day-to-day work can be as simple as cloud builds and a few deploy commands, with the flexibility to scale up complexity as needed.

Google Cloud Run provides a similarly streamlined experience with some key differences: images must come from Artifact Registry (no direct pulls from public registries), and workloads are modeled as either jobs (background/finite work) or services (HTTP endpoints) with revisions, ingress, autoscaling, and scale-to-zero. The chapter demonstrates pushing images to Artifact Registry, running a job, and deploying a web service, while noting current constraints such as Linux/Intel-only and no Compose support. It closes with guidance on choosing platforms—considering OS/architecture support (including Windows/Arm), in-cloud builders and CI/CD integration, Compose parity, observability and configuration (including secrets), identity-based service integration, ease of use versus feature depth, and the growth path to more capable platforms—emphasizing that Docker packaging keeps applications portable across clouds and services.

Running a simple container with Azure Container Instances

Publishing a web container with a public DNS name with ACI

Hosting multiple test environments with shared services and ACI containers

Compute size in ACI directly affects application performance—and your Azure bill.

Creating and authenticating to ACR using the Azure command line

Loading an image from Docker Hub into ACR using the Azure command line

Using an ACR task to build and push an image in Azure from a local source folder

Running a container in ACI from a secure image we built in ACR

Running a distributed application modeled in Compose using Azure Container Apps

Updating app configuration settings in ACA to enable communication between containers

Building and deploying to Azure Container Apps from source code

Fixing app communication with ingress and secret updates

Creating and configuring a new project in Google Cloud

Creating a repository in Artifact Registry and pushing a local image

Running a container as a Google Cloud Run job

Deploying a web app container in a Cloud Run service

• You'll want to create a new project so you can isolate this piece of work.
• The project will need to have billing and services enabled.
• In the new project, you'll need an Artifact Registry.
• The command help for gcloud builds will be useful.
• The source code and Dockerfile is in ch14/exercises/pi-web.
• Try deploying the app with more CPU, and not whether it’s faster than the previous deployment.

FAQ