Containers & Orchestration

Chapter 2 of 6 — AI Cloud Engineer Roadmap

With a VPC and IAM model in place from Chapter 1, this chapter moves up a layer: packaging an application into a container, then running that container on a real orchestrator instead of a single EC2 box.

What you'll build: a containerized app deployed to an EKS cluster.

Tools: Docker, Helm, ArgoCD

Where AI helps: AI writes the Dockerfile boilerplate — you still own image hardening (base image choice, non-root users, multi-stage builds, minimizing the attack surface). A Dockerfile that builds isn't the same as a Dockerfile that's safe to run in production.

Modules in this chapter

• Enable WSL (Windows Subsystem for Linux) in Windows — Windows users only, skip if you're on macOS/Linux
• Docker Desktop Setup — Windows
• Docker Introduction — images, containers, layers, the build cache
• Enable Kubernetes in Docker Desktop with WSL
• Kubernetes overview — pods, services, deployments, the control plane

Why this matters

A container that only runs on your laptop isn't the point — the point is a container that behaves identically on your laptop, in CI, and on an EKS cluster serving real traffic. Kubernetes is the layer that makes that portability operational: scheduling, self-healing, rolling updates, service discovery. Almost everything downstream in this roadmap — the CI/CD pipeline in Chapter 4, the production monitoring in Chapter 5, even the RAG agent in Chapter 6 — assumes it's deploying onto something like the cluster you stand up here.

---

Next: Infrastructure as Code (Terraform)

Chapter 3 stops clicking through the AWS console and starts defining infrastructure as code — the VPC and EKS cluster you built by hand in Chapters 1–2, this time as Terraform you can version, review, and tear down on command.