Skip to main content
Hello, and welcome to this lesson on Docker Overview. My name is Michael Levan. Kubernetes (K8s) was developed at Google from their experience running containers in production. Today it is an open source project and one of the most popular container orchestration platforms. To understand Kubernetes at a high level, we first need to grasp two foundational concepts: containers and orchestration. This lesson introduces containers and the most popular container platform: Docker. If you already know Docker, feel free to skip ahead.

​
Why containers?

A short real-world story: on a previous project we needed an end-to-end stack with a Node.js web server, MongoDB, Redis, and Ansible. We repeatedly hit the same pain points:
  • Service compatibility with the underlying OS (some versions of services didn’t work on our chosen distribution).
  • Conflicts between services over library versions and dependencies.
  • Frequent architectural changes (different DBs, upgrades) required repeating compatibility checks.
  • Long, error-prone environment setup every time a new developer joined — many manual steps and many opportunities for mistakes.
  • Different developer, test, and production environments causing inconsistent behavior across environments.
This tangled compatibility problem is often called the “matrix from hell.”
A presenter stands in front of a slide titled "Why do you need containers?" showing bullet points about compatibility/dependency, long setup time and different Dev/Test/Prod environments, plus a tangled diagram labelled "The Matrix from Hell" with logos for Node.js, MongoDB, Redis and Ansible.
We needed isolation so each component could be changed independently, and we wanted a repeatable, quick onboarding process. Docker solved this: each component runs in its own container with its own libraries and dependencies while sharing the host OS kernel. We built the Docker configuration once, and every developer could start the stack with a single command, regardless of their Linux distribution — as long as Docker was installed.

​
What are containers?

Containers are isolated user-space environments that package an application and its dependencies. They behave like lightweight virtual machines: containers have their own processes, network interfaces, and filesystem mounts, but multiple containers share the same OS kernel. Containers predate Docker (e.g., LXC, LXD). Docker provides a user-friendly tooling layer for building, distributing, and running containerized workloads. Linux distributions (Ubuntu, Fedora, SUSE, CentOS, etc.) consist of a common kernel plus distribution-specific user-space components (tools, libraries, UI). Docker containers leverage the host kernel and supply only the user-space components the containerized app needs. This is why a Linux Docker host can run containers built from different Linux distributions (Debian, Fedora, CentOS, etc.) — they share the same kernel. However, a Linux host cannot run Windows containers directly; for Windows containers you need Docker on Windows.
Containers share the host kernel. You can run different Linux distributions as containers on a Linux host, but you cannot run containers that require a different kernel (e.g., Windows containers) on that host without using a compatible host or a VM.

​
Containers vs Virtual Machines — key differences

  • Kernel: Containers share the host kernel; VMs include their own guest OS and kernel.
  • Isolation vs overhead: VMs offer stronger isolation at the cost of higher resource usage; containers are much lighter.
  • Size and startup: Containers are typically tens to hundreds of megabytes and start in seconds; VMs are often gigabytes and take longer to boot.
  • Cross-OS: VMs can run different guest OS types (Linux, Windows) on the same hypervisor; a single Docker host is tied to its own kernel type.
A presenter stands in front of a slide titled "Containers vs Virtual Machines" showing side-by-side layered diagrams comparing VM and container architectures. The graphic highlights differences in utilization, size (GB vs MB), boot-up speed, and labels like Application, Libs, Deps, Hypervisor, Docker and OS.

​
How Docker is used in practice

There are many container images publicly available in registries such as Docker Hub. Images exist for operating systems, databases, message queues, language runtimes, and more. After you identify an image and install Docker on your host, launching an application instance is usually just a docker command away. Common Docker commands and examples: If you need multiple instances, start multiple containers and place a load balancer in front of them. If a container fails, stop and remove it and start a new container from the same image. Orchestration tools (including Kubernetes) automate scaling, health checks, rolling updates, and self-healing.

​
Images vs Containers

  • Image: an immutable template that contains everything required to create a container. Images are built from Dockerfiles and stored in registries (Docker Hub, private registries).
  • Container: a running instance of an image. Containers are ephemeral by default; persistent state requires volumes or external storage.
A presenter stands at the left of a slide titled "Container vs image." The slide shows a Docker image icon on the left and three stacked Docker container icons on the right labeled Docker Container #1, #2, and #3.

​
Dockerfiles — reproducible build instructions

Developers encapsulate app build and runtime instructions inside a Dockerfile. The Dockerfile is used to build an image that runs consistently on any compliant container runtime. This shifts reproducible environment configuration into source control and simplifies operations. Example Dockerfile for a basic Node.js application:
Build and push this image to a registry; operations can then pull and run it unchanged.

​
Quick reference and resources

For hands-on learning, consider: That’s the end of this lesson on containers and Docker.

Watch Video