Docker for Beginners

A Docker Image is a read-only, layered snapshot of your entire application environment. "Read-only" means once you build an image, it never changes. It's frozen in time. It contains:

• Your application's source code or compiled binary
• The exact runtime it needs (e.g., Python 3.10, Node.js 18, Java 17)
• All third-party libraries and dependencies
• Configuration files and environment variables
• A starting command (what the container should do when it wakes up)

Images live on disk. They're also portable — you can push them to a registry like Docker Hub and anyone in the world can pull and run them. This is exactly how open-source databases, web servers, and tools are shared.

This is one of Docker's most important and clever design choices. An image isn't one giant file — it's a stack of layers. Each instruction in a Dockerfile (we'll cover these in Lesson 4) creates a new layer on top of the previous ones.

Think of it like a stack of transparent slides:

• Layer 1: A base Linux operating system
• Layer 2: Python 3.10 installed on top of that
• Layer 3: Your requirements.txt libraries installed
• Layer 4: Your application code copied in

Why does this matter? Caching! If you rebuild your image after changing only your app code, Docker reuses Layers 1-3 from cache and only rebuilds Layer 4. Builds that would take minutes are done in seconds.

A Container is the live, running instance of an image. When you run a Docker Image, Docker reads the image layers and adds one more thin, writable layer on top. That's the container. All changes made while the container is running (files created, logs written, data saved) happen in that writable layer.

Containers are:

• Isolated — they can't see each other's file systems or processes (by default)
• Ephemeral — when you delete a container, its writable layer is destroyed (this is why Volumes exist — Lesson 6!)
• Fast — starting a container is nearly instantaneous because there's no OS to boot
• Cheap — you can run dozens or hundreds of containers on one machine

You're not locked out of a container once it's running. You can open an interactive terminal session inside it using docker exec. This is incredibly useful for debugging — you can poke around the container's file system as if you had SSH'd into a remote server.

A Virtual Machine (VM) is created by a piece of software called a Hypervisor (like VMware, VirtualBox, or Hyper-V). The Hypervisor sits on top of your real hardware and tricks each VM into thinking it's a complete, physical computer.

Each VM contains:

• A full Guest Operating System (a complete copy of Linux, Windows, etc.)
• Virtual hardware (simulated CPU, RAM, disk, network card)
• The application itself

That Guest OS alone can be 5-20 GB. Booting it is like turning on a whole new computer — it takes minutes. And because the OS is consuming RAM and CPU just to exist, you waste significant resources before your app even starts.

Docker containers take a radically different approach. Instead of virtualizing hardware, they use features built directly into the Linux kernel — specifically namespaces and cgroups — to create isolated environments.

• Namespaces give each container its own isolated view of the system — its own process list, its own network interfaces, its own file system tree — even though they're all running on the same host OS.
• cgroups (control groups) limit how much CPU, memory, and I/O each container can use, preventing one container from starving others.

The critical result: containers share the host's OS kernel. There's no Guest OS to boot up. The container starts in milliseconds because it's just a process (or a group of processes) with special isolation rules applied.

Not always! In large-scale production environments, you'll often see both used together. A cloud provider like AWS or Google Cloud creates a set of VMs (for strong isolation and OS-level guarantees), and then runs Docker containers inside those VMs. You get the security benefits of VMs combined with the speed and density of containers.

For most developers and DevOps engineers, though, Docker is the primary day-to-day tool. VMs are reserved for situations where you need to run a completely different OS, or when regulations require hardware-level isolation.

A Dockerfile is just a plain text file — no special extension needed beyond naming it literally Dockerfile. It contains a sequence of instructions, each one creating a new layer in the final image.

• FROM — The foundation. Specifies the base image to start from. Every Dockerfile MUST begin with this. Think of it as "start with a computer that already has X installed." e.g., FROM python:3.10, FROM node:18, FROM ubuntu:22.04.
• WORKDIR — Sets your working directory inside the container's file system. All following commands run from this folder. If it doesn't exist, Docker creates it. e.g., WORKDIR /app.
• COPY — Copies files from your local machine into the container image. Syntax is COPY <source> <destination>. e.g., COPY . . copies everything in your current folder into /app in the container.
• RUN — Executes a command during the image build process. Used for installing packages, compiling code, creating directories. e.g., RUN pip install -r requirements.txt.
• ENV — Sets environment variables inside the container. e.g., ENV NODE_ENV=production.
• EXPOSE — Documents which port the container listens on. Note: this doesn't actually open the port — it's documentation for whoever runs the container. e.g., EXPOSE 3000.
• CMD — The default startup command. Runs when a container is started from this image. Unlike RUN, this doesn't execute during the build — it's the instruction the container follows when it wakes up. e.g., CMD ["python", "app.py"].

Once you've written your Dockerfile, you build it into an image using docker build. The -t flag lets you give the image a human-readable name (called a tag).

Just like .gitignore tells Git which files to ignore, .dockerignore tells Docker which files to not copy into your image when you use the COPY . . instruction.

This is important for two reasons:

• Security: You don't want your .env file (which contains secrets like API keys) accidentally baked into the image.
• Size: Excluding node_modules, .git, test files, and documentation keeps your image lean and fast to transfer.

Let's trace exactly what happens when you type docker run nginx:

1. You type docker run nginx in your terminal (Docker Client).
2. The Docker Client converts this into an API request and sends it to the Docker Daemon running on your machine.
3. The Docker Daemon checks if the nginx image already exists locally (in its local image cache).
4. If not, the Daemon contacts the Docker Registry (Docker Hub) and pulls the nginx image down to your machine.
5. The Daemon builds a container from the image — creating the writable layer, setting up isolated namespaces, configuring networking.
6. The container starts running. The nginx web server is live!

Docker Hub (hub.docker.com) is the world's largest repository of container images. It hosts Official Images — curated, security-scanned images maintained by Docker and the software's own teams. These are the ones you should use as your base images.

Popular official images you'll use all the time as a developer:

• node — for Node.js applications
• python — for Python applications
• postgres — the PostgreSQL database
• redis — the Redis in-memory data store
• nginx — the Nginx web server / reverse proxy
• mongo — the MongoDB database
• ubuntu / alpine — bare-bones Linux base images

Instead of setting up a PostgreSQL database on your laptop, you just run docker run postgres and you have a fully working database in seconds, no installation needed.

Containers are intentionally designed to be temporary and disposable. This is actually a feature, not a bug! It means:

• You can destroy and recreate containers instantly without any setup
• Every container starts from a clean, known-good state
• Containers can be replaced, updated, or scaled without side effects

But this creates an obvious problem: what about your database? Your user account records? Your game save files? You can't lose all that data every time a container restarts. That's where Volumes and Bind Mounts come in.

A Docker Volume is a special, Docker-managed directory that lives on the host machine's file system — completely outside the container. You "mount" it into the container at a specific path. When the container writes to that path, the data actually gets stored in the volume on the host. When the container is destroyed, the volume survives.

Volumes are the preferred way to persist data because:

• They're managed by Docker — Docker handles where on disk they live
• They work identically on Mac, Windows, and Linux
• They can be shared between multiple containers simultaneously
• They can be backed up and restored easily

A Bind Mount links a specific folder on your host machine directly into the container. Instead of a Docker-managed volume, you're pointing at an exact path like /Users/jude/projects/myapp.

Bind mounts are extremely useful during development because any changes you make to files on your laptop are instantly reflected inside the container — no rebuild required. This lets you edit code with your normal text editor while the app runs in a Docker container.

When you run an application inside a container (say, a web server on port 80), the outside world — your browser, your teammates, the internet — can't reach it yet. The container is on a private network. You need to create a mapping from a port on your host machine to a port inside the container.

The syntax is -p <host_port>:<container_port>.

• -p 8080:80 — Traffic arriving at port 8080 on your laptop is forwarded into the container on port 80.
• -p 5432:5432 — Exposes a PostgreSQL database (port 5432) to your host.
• -p 3000:3000 — Common for Node.js dev servers.

When containers can't talk to each other, it's almost always one of these causes:

• They're not on the same network — Check docker network inspect <network_name> to confirm both containers appear in the "Containers" section.
• Wrong hostname — Make sure you're using the container's --name as the hostname, not "localhost" (localhost inside a container refers to itself, not the host machine!).
• Port not exposed inside container — The application inside the container must actually be listening on the port you expect. Check its documentation.

Docker Compose is a tool for defining and running multi-container Docker applications using a single YAML configuration file. With one command, Compose:

• Creates all the named networks your services need
• Creates all the named volumes for persistence
• Pulls or builds all the images required
• Starts all the containers in the correct dependency order
• Wires the containers together with DNS so they can communicate by service name

The result: a single docker compose up command spins up your entire application stack — your full development environment — from scratch in seconds.

The Compose file is written in YAML — a human-readable format that uses indentation to show hierarchy (similar to Python). The key sections are:

• services: — The list of containers you want to run. Each service is a container.
• image: — Which Docker image to use for this service (from Docker Hub or your own build).
• build: — Build from a Dockerfile instead of a pre-existing image.
• ports: — Port mappings (host:container).
• environment: — Environment variables to pass into the container.
• volumes: — Mount volumes or bind mounts.
• depends_on: — Declare dependencies between services (start the database before the web server).
• networks: — Put services on specific networks.

With your docker-compose.yml file written and saved in your project folder, these commands control your entire application stack:

• 🐋 Docker solves the "Works on my machine" problem by packaging your app with all its dependencies into a portable container.
• 🖼️ Images are read-only, layered blueprints. Layers enable fast rebuilds via caching.
• 📦 Containers are live, running instances of images. Ephemeral by design — writable layer disappears when deleted.
• 🏘️ Docker vs VMs — Containers share the host OS kernel (fast, lightweight). VMs include a full Guest OS (heavy, isolated).
• 📝 Dockerfiles are the step-by-step recipes that build images. FROM, RUN, COPY, CMD are the core instructions.
• 🧠 Architecture — Docker Client talks to the Docker Daemon, which pulls images from a Registry like Docker Hub.
• 💾 Volumes give containers permanent memory. Bind Mounts are great for development hot-reloading.
• 🌐 Networking — Bridge networks let containers communicate. Port mapping opens doors to the outside world.
• 🎼 Docker Compose orchestrates multi-container apps with a single YAML file and a single command.

You've climbed the first mountain. Here's what experienced Docker practitioners learn next:

• Multi-Stage Builds — Use multiple FROM statements in one Dockerfile to create tiny production images. You build in a "builder" stage (with all your compilers and dev tools), then copy only the compiled output into a minimal final image.
• Docker Security — Running containers as non-root users, scanning images for vulnerabilities (docker scout), using secrets management instead of hardcoding passwords in Compose files.
• Container Orchestration — When you need to run containers across multiple servers and auto-heal when things crash: Kubernetes (K8s). Think of it as Docker Compose's powerful big sibling for production clusters.
• CI/CD Integration — Automating Docker builds and pushes on every Git commit using GitHub Actions, GitLab CI, or Jenkins. Your pipeline builds the image, runs tests inside a container, then pushes to a registry if tests pass.