🔥 New: Full-Stack Next.js 15 Bootcamp — live cohort starts Jan 27. Grab your seat →
By Sarah Jenkins • Oct 24, 2023 • 8 min read
From Zero to Deployed

How to Actually Learn Docker
Without Getting Lost in the Docs.

The official documentation is a reference, not a guide. Here is the practical path to mastering containerization, written for developers who want to ship.

Command line interface showing Docker build and run commands

The Problem with Official Docs

You’ve probably clicked the Docker documentation. You’ve scrolled through the architecture diagrams. And you’ve probably closed the tab feeling more confused than when you started.

Official docs are reference material. They assume you understand the underlying kernel, the concept of namespaces, and how cgroups work. They don't explain why you should care, or how to set up a development environment that doesn't break when you pull down a dependency.

Learning Docker from scratch without a guide is like trying to learn to drive by reading the manual for the engine block. You can do it, but it’s painful and inefficient. RunIt exists to bridge that gap.

What Docker Actually Is (and Isn't)

The most common misconception is that Docker is just a virtual machine. It isn't.

A Virtual Machine (VM) includes a full operating system (Guest OS) and the application. It's heavy, it takes minutes to boot, and it consumes gigabytes of RAM.

Docker uses the host operating system's kernel. It shares the kernel with the host but isolates the file system, processes, and network stack. This makes containers incredibly lightweight and fast—booting in milliseconds.

Your First Container in 10 Commands

Forget the complex Dockerfiles for a moment. Here is how to get a container running in your terminal right now.

1. Pull an image:

docker pull ubuntu:22.04

2. Run it interactively:

docker run -it ubuntu:22.04 bash

3. Inside the container, install something:

apt update && apt install -y htop

4. Exit the container:

exit

5. List running containers:

docker ps

See that container is still there? That's the power of Docker. You can inspect it, attach to it, or commit it to an image later.

Docker Compose for Real Projects

You don't run databases and web servers in the same container. You define them as services in a docker-compose.yml file.

version: '3.8'
services:
  web:
    build: .
    ports:
      - "5000:5000"
    depends_on:
      - db

  db:
    image: postgres:13
    environment:
      POSTGRES_PASSWORD: secret

This simple file spins up a web app and a PostgreSQL database on your local machine. No manual port forwarding, no complex shell scripts.

Common Mistakes and How to Avoid Them

Forgetting .dockerignore

You copy your entire project into the container, including node_modules and .git, making the build slow and the image bloated. Always create a .dockerignore file.

Hardcoding Secrets

Don't put API keys or passwords in your Dockerfile or compose file. Use environment variables or Docker secrets instead.

Using FROM scratch unnecessarily

While minimal images are great, starting from scratch means you have to install the OS yourself. Start with a Debian or Alpine base image unless you have a specific security reason not to.

Ready to go deeper?

Want the full course?
RunIt Docker & DevOps is 28 lessons deep.

Conclusion

Docker is no longer a niche tool for DevOps engineers. It is the standard for how we build, test, and ship software today. By understanding containers, images, and Compose, you've unlocked a new level of control over your development environment.

The best way to learn is by doing. Build a personal project, containerize it, and deploy it. If you hit a wall, don't just read the docs—join the RunIt community and get feedback from engineers who are doing it every day.

Discussion

COMMENT

DevMike: The section on .dockerignore saved my project size by 40%. Thanks for this breakdown.

— Oct 25, 2023