Logo
Logo
Home
Archive
AI Agent Notes
Advertise
YouTube
Login
Sign Up
Logo
  • Home
  • Posts
  • 🦥 Docker For Dummies

🦥 Docker For Dummies

Mar 25, 2026

Hello friends!

Welcome to this week’s Sloth Bytes. I hope you had an amazing week!

You don't remember that meeting. Nobody does.

I bet right now you couldn't tell me what your last meeting or lecture was about even if your life depended on it.

Don't worry, I can't either. I have the memory of a goldfish. That's why I started using Granola.

It picks up your meetings automatically and transcribes everything in the background while you take notes like normal. No bot joining your call, no “recording in progress” sound, nobody knows it's there.

After the meeting, it takes your messy notes and the full transcript and turns it into a clear summary of the meeting and what you actually need to do next.

You can even share that summary with your team because I bet they forgot too.

Now nobody has to pretend they remember.

Try Granola on your next meeting. Free for a month with code CODINGSLOTH.

Docker For Dummies

You’ve probably heard the classic joke: "It works on my machine."

Well that joke exists for a reason.

There’s lots of situations where code literally only works on your machine for some reason.

And I guess it happened enough to where a solution was needed. That solution was Docker.

What Even Is Docker?

Docker is a platform/toolset for building images and running applications in containers.

  • Your application code

  • Your runtime and dependencies

  • Filesystem/configuration needed to start the application

Secrets are the exception: API keys, passwords, and other sensitive values should usually be injected at runtime rather than baked into the image.

The build produces a portable image. When that image is started, Docker creates a container: an isolated process environment with the image filesystem plus runtime configuration.

Run a compatible image on your laptop, CI runner, or server and you can get a much more consistent environment. “Compatible” matters: container images still depend on things like CPU architecture and the container runtime/host kernel model, and Docker Desktop uses virtualization behind the scenes on macOS and Windows to run Linux containers.

Think of it like this:

Your app is a piece of IKEA furniture and Docker is the box it comes in. Every single part is in there. The instructions. The weird annoying hex key. All of it. Wherever you take that box, you can build the same thing.

Containers vs Virtual Machines

Some of you probably noticed that containers sounds similar to a VM.

Well…

  1. You’re a nerd

  2. You’re correct

Containers are similar to VMs, but there are small differences that trip people up every time, so let's quickly go over it.

A virtual machine runs a full guest operating system and its own kernel on virtualized hardware provided by a hypervisor. That usually gives stronger isolation but adds more operating-system overhead than a container.

A container is different. Linux containers isolate processes using operating-system features such as namespaces and cgroups while sharing the host’s Linux kernel rather than booting a separate guest kernel for each container.

Without getting too technical: a container gets its own view of things like processes, networking, and filesystem mounts, while the host kernel still controls the underlying CPU, memory, and devices. The isolation is useful, but a container is not automatically the same security boundary as a separate VM.

A VM is like renting a whole apartment. A container is just getting your own bedroom.

Containers are usually smaller and faster to start than full VMs because they do not boot a separate guest OS/kernel for every instance.

Parts of each. Small differences.

The Key Concepts

There are really only three things you need to understand about Docker:

1. The Dockerfile

Think of a dockerfile like a recipe. It contains instructions that tells Docker how to build your app.

# Start from an official Python base image
FROM python:3.11-slim

# Set working directory inside container
WORKDIR /app

# Copy your requirements and install them
COPY requirements.txt .
RUN pip install -r requirements.txt

# Copy the rest of your code
COPY . .

# What runs when the container starts
CMD ["python", "app.py"]

2. The Image

When you build a Dockerfile, you get an image: an immutable, layered filesystem plus metadata describing how the application should run. You can think of it loosely like a class/blueprint used to create containers.

docker build -t my-app .

3. Container

A container is an instance created from an image with runtime state and configuration. It might currently be running, paused, or stopped. If the image is the blueprint, the container is the instantiated thing.

docker run my-app

These are the 3 steps you need to “dockerize” your app:

  1. Write the dockerfile

  2. Build it

  3. Run it

Pretty simple and useful.

You can create many containers from the same image. They start from the same image layers but have separate writable layers/process namespaces; they are isolated from each other to the degree configured by the container runtime and host.

Docker Compose

We only covered a baby example, so let’s get a bit more practical.

Real apps have multiple pieces. Could be a front-end, back-end, and database.

Now technically, you could put all those pieces into one giant docker container, but I wouldn’t recommend that and Docker doesn’t either.

Why split services? It lets different processes have separate lifecycle, configuration, scaling, networking, and storage concerns. Running everything in one container is possible, but it usually makes those responsibilities harder to manage independently.

Each piece has a different job, so you should instead put each piece into it’s own container.

But managing three separate containers gets annoying fast.

This is why we have Docker Compose.

Docker Compose lets you define all of them in one file and spin them up together.

# compose.yaml
services:
  frontend:
    build: ./frontend
    ports:
      - "3000:3000"

  backend:
    build: ./backend
    ports:
      - "8000:8000"
    depends_on:
      - db

  db:
    # This pulls/runs an existing Postgres image; it does not build one.
    image: postgres:15
    environment:
      # Fine for a toy example. Use runtime secrets/config management for real credentials.
      POSTGRES_PASSWORD: dev-only-secret
    volumes:
      - postgres_data:/var/lib/postgresql/data

volumes:
  postgres_data:

And all it takes is one command to run everything:

docker compose up

That starts the services, network, and volume defined in the Compose file. One caveat: depends_on controls startup ordering, but it does not automatically mean the database is fully ready to accept connections unless you add an appropriate health check/retry strategy.

When Should You Use Docker?

Yes, use it when:

  • You're sharing code with a team

  • You're deploying to a server or the cloud

  • Your app has specific dependency versions that need to be consistent

  • You're tired of "works on my machine" ruining your life

  • You want to self-host

Probably skip it when:

  • It's a tiny personal script you'll only ever run yourself

  • You're just learning the basics of programming (don't add this complexity early)

  • Your team has zero DevOps knowledge and no time to learn (Docker gets complicated fast)

Why Devs Love It

Once you Dockerize an app well, onboarding can become dramatically easier: instead of manually installing every runtime and dependency, a developer may be able to clone the repo and run something close to docker compose up. You still need sane environment variables, secrets, data migrations, architecture-compatible images, and documentation—Docker is helpful, not sorcery.

Fun fact: Docker was released in 2013 and became so popular that it changed how most of the software industry thinks about deployment. Kubernetes a tool that orchestrates thousands of containers was built partly because Docker made containers so mainstream that companies needed something to manage them at scale.

TL;DR

Concept

What it is

Dockerfile

Instructions used to build an image

Image

Immutable layered application filesystem + runtime metadata

Container

A runtime instance created from an image

Docker Compose

A way to define and run a multi-container application

Why it matters

More repeatable application environments across development, CI, and deployment

Docker won't make your code better, and it cannot guarantee identical behavior on every possible machine. But it can make the application runtime and dependency environment far more reproducible across compatible systems.

If you’re a nerd and wanna learn more

  • The Only Docker tutorial You Need To Get Started - My tutorial

  • Official Docker Getting Started guide

  • Official Docker Guides

If you want to keep learning

  • Environment variables and secrets — keep API keys and credentials out of your source code and, especially, out of Docker image layers.

  • CI/CD explained — how Docker images get built, tested, and deployed automatically once your project leaves your machine.

  • Command Line for beginners — Docker is heavily CLI-driven, so terminal fluency makes the entire workflow less painful.

Thanks to everyone who submitted!

Manzolillom, kwame-Owusu, hamooo21112655, neilyneilynig, Nomekuma, iamsunildev, adnmzlz, sujitha483, Yaya9256, Ishaan282, and gcavelier!

Daily Temperatures

You are given an array of integers temperatures where temperatures[i] represents the daily temperatures on the ith day.

Return an array where output[i] is the number of days after the ith day before a warmer temperature appears on a future day. If there is no day in the future where a warmer temperature will appear for the ith day, set output[i] to 0 instead.

Examples

daily_temperatures([30,38,30,36,35,40,28])
output = [1,4,1,2,1,0,0]

daily_temperatures([22,21,20])
output = [0,0,0]

daily_temperatures([30,38,30,36,35,40,28])
output = [1,4,1,2,1,0,0]

How To Submit Answers

Reply with

  • A link to your solution (github, twitter, personal blog, portfolio, replit, etc)

  • or if you’re on the web version leave a comment!

  • If you want to be mentioned here, I’d prefer if you sent a GitHub link or Replit!

That’s all from me!

Have a great week, be safe, make good choices, and have fun coding.

If I made a mistake or you have any questions, feel free to comment below or reply to the email!

See you all next week.

What'd you think of today's email?

  • 🦥 Amazing! Keep it up
  • 🦥 Good, not great
  • 🦥 It sucked

Login or Subscribe to participate

Want to advertise in Sloth Bytes?

If your company is interested in reaching an audience of developers and programming enthusiasts, you may want to advertise with us here.

Keep Reading

Read all
arrow-right
envelope-simple

Join 50k+ developers and become a better programmer and stay up to date in just 5 minutes.

© 2026 Sloth Bytes.
beehiivPowered by beehiiv