Skip to main content

Documentation Index

Fetch the complete documentation index at: https://resources.devweekends.com/llms.txt

Use this file to discover all available pages before exploring further.

Docker Architecture Overview

​
Docker Crash Course

“Docker containers wrap a piece of software in a complete filesystem that contains everything needed to run.” - Solomon Hykes
Docker killed the “it works on my machine” problem. Before Docker, deploying software was a nightmare of environment mismatches, dependency hell, and configuration drift. Containers changed everything. This course takes you from zero to production-ready Docker skills.

​
Why Docker Matters

Consistency

The “it works on my machine” problem is dead. Containers guarantee identical environments everywhere.

Isolation

Each container is a fortress. No more dependency conflicts or “but I have Python 2.7 installed” disasters.

Efficiency

Containers share the OS kernel. We are talking MBs instead of GBs, seconds instead of minutes.

Portability

Build once, run anywhere. Your laptop, staging server, production cluster, any cloud provider.

​
The Story Behind Docker

2013: Solomon Hykes gave a five-minute lightning talk at PyCon demoing Docker. The audience immediately understood: this was the answer to the “works on my machine” problem that had plagued software teams for decades. Within a year, every major tech company was adopting containers. The Problem: Before Docker, deploying software was like moving houses — you had to carefully pack everything, hope nothing broke in transit, and spend hours unpacking and configuring at the destination. Each server was a unique snowflake with subtly different library versions, configuration files, and system dependencies.
  • “Works on my machine” syndrome — the developer’s laptop has Python 3.9, the server has 3.7
  • Complex deployment processes — 50-page runbooks for deploying a single service
  • Environment inconsistencies — “staging looked fine, production broke” became a weekly ritual
  • Slow VM startup times — spinning up a VM took minutes; developers needed something faster
The Solution: Docker containers package your application with everything it needs to run. The container is identical whether it runs on your laptop, in CI, or on a production server in Singapore. Today: Docker powers:
  • Millions of applications across startups and Fortune 500 companies
  • Every major cloud platform (AWS ECS/EKS, Google GKE, Azure AKS)
  • CI/CD pipelines worldwide (GitHub Actions, GitLab CI, Jenkins all run steps in containers)
  • Kubernetes (the container orchestration standard, built entirely on container primitives)

​
What You’ll Learn

1

Fundamentals

Images, containers, Docker architecture, essential commands. The foundation everything else builds on. Start Here
2

Internals Deep Dive

Namespaces, cgroups, union filesystems, the Docker daemon. If you love understanding how things actually work, this one is for you. Explore Internals
3

Building Images

Dockerfile mastery, layer caching, multi-stage builds. Craft production-grade images that are secure and optimized. Build Images
4

Networking and Volumes

Container networking, bridge vs host vs overlay, port mapping, data persistence. How containers talk to each other and the outside world. Learn Networking
5

Docker Compose

Multi-container applications, service orchestration, development workflows. The bridge between Docker and Kubernetes. Use Compose
6

Best Practices

Security hardening, image optimization, production deployment patterns. Ship with confidence. Best Practices

​
Docker vs Virtual Machines

Think of VMs as separate houses (each with its own foundation, plumbing, and electricity), while containers are apartments in a building (shared infrastructure, private living spaces). Apartments are cheaper and faster to set up, but you share walls with your neighbors.
FeatureDocker ContainersVirtual Machines
SizeMBs (Alpine: ~7MB)GBs (Ubuntu VM: ~2GB)
StartupSeconds (no OS boot)Minutes (full OS boot)
PerformanceNear-native (shared kernel)5-20% overhead (hypervisor)
IsolationProcess-level (namespaces)Hardware-level (hypervisor)
Resource UsageShared kernelSeparate OS per VM
SecurityWeaker (shared kernel attack surface)Stronger (hardware isolation)
When to use Docker: Microservices, CI/CD pipelines, development environments, any workload where you control what runs inside.
When to use VMs: Running different operating systems, workloads requiring strong security isolation (multi-tenant), legacy applications that need a full OS, or when compliance requires hardware-level separation.

​
Course Structure

​
Module 1: Fundamentals (2-3 hours)

Docker architecture, images vs containers, the container lifecycle, essential commands you will use daily.

​
Module 2: Internals Deep Dive (2-3 hours)

How Docker actually works under the hood. Namespaces, cgroups, union filesystems, OCI specification. If you love internals, continue. If not, skip to Module 3.

​
Module 3: Building Images (2-3 hours)

Dockerfile mastery, layer caching strategies, multi-stage builds, building for production.

​
Module 4: Networking and Volumes (2 hours)

Bridge networks, overlay networks, port mapping, volumes vs bind mounts, data persistence patterns.

​
Module 5: Docker Compose (2 hours)

Multi-container applications, service dependencies, development vs production configs.

​
Module 6: Best Practices (2 hours)

Security hardening, rootless containers, image scanning, production deployment patterns.

​
Interview Deep-Dive

Strong Answer:
  • This is not an either/or decision — in most production environments, you use both. Containers run inside VMs. The question is really about the granularity of isolation and the deployment model.
  • Containers are the right choice for microservices you control: your API services, background workers, web frontends. They give you fast startup (seconds), efficient resource usage (shared kernel, minimal overhead), and portable deployment artifacts (same image from dev to production). The CI/CD story is straightforward: build an image, push to a registry, deploy everywhere.
  • VMs are the right choice when you need strong isolation (multi-tenant workloads where tenants do not trust each other), when you need a different operating system (Windows services alongside Linux), or when compliance requires hardware-level separation (PCI-DSS, HIPAA in some interpretations). VMs are also necessary for workloads that need kernel modifications or custom kernel modules.
  • The typical production architecture at scale is containers running inside VMs, orchestrated by Kubernetes. AWS EKS runs your pods on EC2 instances (VMs). GKE runs them on Compute Engine VMs. The VM provides the security boundary between tenants or failure domains; the container provides the deployment unit.
  • The key trade-off to articulate: containers give you density and speed at the cost of weaker isolation. VMs give you strong isolation at the cost of resource overhead and slower operations. For a new microservices application where you control the code, containers are the clear starting point.
Follow-up: A security-conscious architect pushes back, saying container escapes are a real risk. How do you address this?Container escapes are real but increasingly rare with modern security practices. I would layer defenses: run as non-root (USER directive), drop all capabilities (--cap-drop=ALL), enable seccomp profiles, use read-only filesystems, and scan images for CVEs in CI. For truly untrusted workloads, I would use Kata Containers or gVisor, which add VM-like isolation to the container model. The broader point is that security is not a binary property of the technology — it is a function of how you configure and operate it.
Strong Answer:
  • The “works on my machine” problem has three root causes: different OS libraries, different runtime versions, and different configuration. Docker solves all three by packaging the application with its complete filesystem — from the OS libraries up through the runtime and application code.
  • Mechanically, a Docker image contains every file the application needs, starting from a base OS layer (e.g., Alpine Linux, Debian) through installed system packages, language runtimes, application dependencies, and your source code. When you run this image, the kernel features (namespaces, cgroups, OverlayFS) create an isolated environment where the process sees only the files from the image — not the host’s libraries or configuration.
  • Concretely: if your application needs Python 3.11 with a specific version of OpenSSL, the image contains exactly that. It does not matter if the host runs Python 3.8 or has a different OpenSSL. The container sees only what is in the image. This is not PATH manipulation or virtual environments — it is filesystem-level isolation via mount namespaces.
  • The second mechanism is declarative configuration via Dockerfiles. Instead of a wiki page saying “install these 12 packages, set these 8 environment variables, configure this file,” you have an executable specification that produces an identical artifact every time. A new developer runs docker build and gets the exact same environment as production.
  • The third mechanism is image registries. The built artifact (image) is stored in a registry and pulled by any environment. The image on your laptop is byte-identical to the image in CI and in production. There is no “building from source” variation.
Follow-up: Docker solved “works on my machine” but introduced “works on my Docker version.” How do you handle that?OCI (Open Container Initiative) standards address this. OCI defines the image format, runtime behavior, and distribution protocol. An OCI-compliant image built with Docker works with Podman, containerd, CRI-O, and any other OCI-compliant runtime. In practice, the most common remaining variation is between Docker Desktop (which runs a Linux VM on macOS/Windows) and native Linux Docker. Performance characteristics, file-watching behavior, and networking differ. For CI/CD, I standardize on a specific Docker engine version pinned in the CI configuration, and I validate in a Linux-native environment that matches production.
Ready to master Docker? Start with Docker Fundamentals or jump straight to Internals Deep Dive if you want to understand how containers really work.