What is Docker? Containers, images and Dockerfiles explained
Docker is a platform and toolset for building, packaging and running applications in containers — lightweight, portable units that bundle an application with everything it needs to run consistently anywhere. Before it, moving code from a developer’s laptop to a test server to production was a recurring source of friction: each environment had its own installed libraries, its own operating system patches, its own quietly different configuration. Docker made “package it once, run it anywhere” a practical default rather than an aspiration. This guide keeps to the concepts — what an image and a container actually are, how a Dockerfile builds one, where images live, and how Docker relates to the orchestration layer that sits above it — and points to certification study where the topic is examined directly.
The problem it solves: “it works on my machine”
The phrase “works on my machine” names a specific, familiar failure: software behaves correctly in the environment it was built in and breaks somewhere else, because that other environment has a different library version, a missing dependency, or a subtly different operating system configuration. Before containers, teams fought this with detailed setup documentation, configuration management scripts, and a fair amount of hope.
Docker’s answer is to package the application together with its dependencies, runtime and configuration into a single unit that runs identically regardless of what is installed on the host underneath. Our explainer on containers versus virtual machines covers the technical distinction between a container and a full VM in detail — this article assumes that background and focuses on what Docker specifically does with the idea.
The core concepts, plainly
A handful of terms cover almost everything Docker does day to day:
- Image — a read-only blueprint: the application code, runtime, libraries and configuration bundled together, but not yet running.
- Container — a running instance of an image; you can start many containers from the same image, each isolated from the others.
- Dockerfile — a plain-text recipe of instructions (start from this base, copy in this code, install these dependencies, run this command) that Docker follows to build an image.
- Registry — a place images are stored and shared, most commonly Docker Hub, so a team (or a deployment pipeline) can pull an image by name instead of rebuilding it from scratch.
How Docker relates to Kubernetes
Docker and Kubernetes are frequently mentioned in the same breath but do different jobs, and confusing them is a common early mistake. Docker builds images and runs individual containers on a single machine. Kubernetes is an orchestrator: it takes many containers, schedules them across a fleet of machines, restarts ones that fail, scales them up and down, and manages networking between them.
Put simply, Docker answers “how do I package and run this one thing consistently?” and Kubernetes answers “how do I run hundreds of these things reliably, across many servers, without doing it by hand?” Our explainer on what Kubernetes is covers the orchestration layer in depth; here, the point is only that the two sit at different levels of the same stack, and images built with Docker are typically exactly what Kubernetes goes on to run.
Why it changed software delivery
Docker’s impact went beyond convenience. Because an image behaves the same in every environment, teams could trust that a container tested in staging would behave identically in production — collapsing a whole category of environment-specific bugs. Packaging and starting a container is also fast compared with provisioning and configuring a full server, which shortened the path from code to a running deployment.
The consistency also made microservices practical at scale: instead of one large application that had to be deployed as a unit, a system could be split into many small services, each packaged as its own container with its own dependencies, deployed and scaled independently. That shift underpins much of what modern cloud-native architecture looks like today.
Where containers run in the cloud
Every major cloud offers managed ways to run containers, so the same Docker image travels wherever it is deployed. On AWS, the options include Amazon ECS (a managed container orchestrator), Amazon EKS (managed Kubernetes) and AWS Fargate (serverless compute for containers, usable under either). Azure offers Azure Container Instances for simple single-container workloads and Azure Kubernetes Service (AKS) for full orchestration. Google Cloud offers Cloud Run for containers that scale on demand and Google Kubernetes Engine (GKE) for full orchestration.
None of these replace Docker — they are places to run the images it builds. Choosing between them is largely a question of how much orchestration a workload actually needs, which is exactly the kind of trade-off the architecture-focused certifications examine.
Where Docker and containers appear in certification study
Containers are core material on the developer and architecture tracks. The AWS Developer Associate (DVA-C02) exam expects working knowledge of building and deploying containerised applications on ECS and EKS. The AWS Solutions Architect Associate (SAA-C03) exam expects you to reason about when a container-based service is the right architectural choice versus serverless or traditional compute. If you plan to work with Kubernetes specifically, the Kubernetes and Cloud Native Associate (KCNA) builds directly on the concepts in this article before moving into cluster operation.
Original practice questions, timed mock exams and revision notes. No card, nothing to pay.