Docker Basics

So you’ve heard about containers, right? A container is a lightweight, isolated box that holds your app plus everything it needs to run. If that idea is still fuzzy, go read Containers Explained first, then come back here.

Now here’s the catch:

• Containers are a great idea, but you need an actual tool to build them and run them.
• That tool, for most people in the world, is Docker.
• When a developer says “let me dockerize this app,” they mean “let me package it into a container using Docker.”

So in this lesson we’ll keep it simple. We’ll see what Docker is, the few pieces you need to know, and the handful of commands that get you running. Let’s go.

🐳 What is Docker

Let’s define it plainly first.

• Docker is a popular tool for building, sharing, and running containers.
• That’s really it. You write a small recipe, Docker packages your app into a container, and then Docker runs that container for you.
• It became the standard way teams ship software, so knowing Docker basics is almost expected today.

The thing to remember is that Docker is the tool, and the container is the thing it makes. People mix these two up all the time, and we’ll clear that up as we go.

🧩 The Key Pieces

Docker has only a few moving parts. Once these click, the rest is easy. Let’s define each one.

• A Dockerfile is a recipe. It’s a plain text file that describes, step by step, how to build your app’s package.
• An image is the built package. When Docker follows the recipe, the result is an image, a frozen snapshot of your app and everything it needs.
• A container is a running instance of an image. You take the frozen image, press play, and now it’s alive and doing work.
• A registry is where images are stored and shared, like a library of images. The most famous public one is Docker Hub.

Here’s a way to keep it straight in your head:

📄 A Simple Dockerfile

Okay, let’s look at an actual Dockerfile. Don’t worry, it’s short. Imagine Alex has a small Node.js app and wants to package it.

FROM node:20
COPY . /app
RUN npm install
CMD ["node", "/app/server.js"]

Let’s read it line by line, top to bottom, because that’s the order Docker runs it in:

• FROM node:20 picks a starting point. Instead of building everything from scratch, Alex starts from an existing image that already has Node.js version 20 inside it. This starting image is called the base image.
• COPY . /app copies the app’s files from Alex’s folder into a folder called /app inside the image.
• RUN npm install runs a command while building, here it installs the app’s dependencies. Dependencies are the extra code libraries your app needs.
• CMD ["node", "/app/server.js"] sets the default command, which is what runs when the container starts. So when the container comes alive, it launches the server.

So in plain words, this recipe says: start from Node, copy my app in, install what it needs, and run the server when you start. That’s a complete, working Dockerfile.

⌨️ Build and Run

Now we have a recipe. Time to actually use it. There are really two commands you’ll reach for first.

First, build the image from the Dockerfile:

docker build -t myapp .

Here’s what each bit means:

• docker build tells Docker to follow the Dockerfile and produce an image.
• -t myapp tags the image with a name, myapp, so you can refer to it later. A tag is just a friendly label.
• The . at the end means “use the Dockerfile in the current folder.” That little dot trips people up, so watch for it.

Then, run a container from that image:

docker run myapp

• docker run takes your image and starts a container from it.
• It uses the CMD from the Dockerfile, so your server starts up.
• You can run this command again and get another container, all from the same image.

Here’s the whole flow in one picture. Notice how each step feeds the next:

So the path is always the same: Dockerfile to image to container. Build once, run as many times as you like.

🌍 Sharing Images

Building an image on your own machine is nice, but the real power is sharing it. This is where a registry comes in.

• A registry is a place to store images so others can grab them. Docker Hub is the big public one, kind of like GitHub but for images.
• You push your image up to the registry, and then anyone (including you, on another machine) can pull it down and run it.
• “Push” means upload, “pull” means download. Same words you’d use with Git, same idea.

The two commands look like this:

docker push alex/myapp
docker pull alex/myapp

• docker push alex/myapp uploads Alex’s image to the registry under that name.
• docker pull alex/myapp downloads it onto any machine that wants to run it.

So a teammate halfway across the world can pull alex/myapp and run the exact same container Alex built. No “but it works on my machine” arguments anymore.

⚡ Why Docker Took Over

You might wonder why Docker got so popular so fast. A few reasons stand out:

• Consistent environments. The image carries everything the app needs, so it runs the same on a laptop, a test server, and production. No more surprises from a missing library.
• Easy to share. Push to a registry, and anyone can pull and run it in seconds.
• Fast and light. Containers start quickly and don’t carry a whole operating system each, so you can pack many on one machine.
• It’s the standard. So many tools, tutorials, and cloud services speak Docker that learning it opens a lot of doors.

Put together, Docker made packaging and shipping software feel boring and reliable, which is exactly what you want.

⚠️ Common Mistakes and Misconceptions

A few things trip people up early. Let’s clear them out:

• “Docker is the same as containers.” Not quite. Containers are the concept. Docker is a tool that builds and runs them. There are other tools too, but Docker is the most common one.
• “An image and a container are the same thing.” They’re not. The image is the frozen package sitting on the shelf. The container is that package actually running. One image, many containers.
• “I’ll just store my important data inside the container.” Careful here. A container is ephemeral, which means it’s temporary. When it stops or gets replaced, anything written inside it can vanish. For data you want to keep, use a volume, which is storage that lives outside the container and sticks around.

🛠️ Design Challenge

Try this on your own to test yourself.

Imagine Alex has a small Python web app in a folder. Walk through, on paper, how Alex would ship it with Docker:

• What would the Dockerfile roughly contain? Think base image, copy, install, run command.
• Which command builds the image, and which one runs it?
• Where would Alex push the image so a teammate can pull it?
• The app needs to save user uploads. Where should those uploads live so they survive a container restart?

If you can answer all four, you’ve got the basics down cold.

🧩 What You’ve Learned

You can now explain how Docker takes an app from a recipe to a running container. Here’s what you’ve picked up.

• ✅ Docker is a tool for building, sharing, and running containers.
• ✅ A Dockerfile is the recipe, an image is the built package, and a container is a running instance of that image.
• ✅ docker build -t myapp . creates an image, and docker run myapp starts a container from it.
• ✅ A registry like Docker Hub lets you push images up and pull them down anywhere.
• ✅ Containers are ephemeral, so important data belongs in a volume, not inside the container.

🚀 What’s Next?

You’ve got Docker basics in hand. Next, zoom out and see where containers fit and how teams run lots of them at once.

• Containers Explained goes back to the core idea of what a container really is and why it beats running a full machine.
• Kubernetes Basics shows how teams run and manage many containers together at scale.

Once you’ve got those, you’ll understand the whole journey from a single container to running them across a cluster.