Docker Fundamentals: The Tip of the Iceberg

ann — Mon, 09 Mar 2026 22:27:57 +0000

Docker Fundamentals: The Tip of the Iceberg

In this AI Era, where everything is "AI this" and "AI that," I see that the industry needs people who can manage, plan, and monitor system architecture more than ever before.

That's why I chose to learn something new — SRE / DevOps / Solution Architecture — and containerizing apps is just the tip of the iceberg.

Docker is a tool that lets you containerize your app, so that the infamous "It works on my machine" problem can finally disappear. And this is what I learned about the fundamentals of Docker.

If you look at the Docker docs, there's a lot to explore — but honestly, it's not that much to grasp the fundamentals. It basically comes down to looping back and forth between four things: images, containers, Dockerfile, and basic Docker commands.

What is a Docker Image?

A Docker Image is simply a packaged app. The analogy I like to use: a Docker Image is like a video game disc, and a Docker Container is like a PlayStation — it's where you run that disc. You can play the same game on a different PlayStation using the same disc, right? Same idea here. If a Docker Image is the packaged app, the Docker Container is the instance that runs it.

Docker Container vs Virtual Machine

You might be thinking — isn't a Docker container just like a virtual machine? The answer is actually no.

A Docker container runs on top of the Host OS and shares the host's processes, while a Virtual Machine runs directly on the hardware. The most visible difference between the two is size — because a VM contains a full OS, it's much larger than a Docker container. Docker images and containers are typically megabytes (MB) in size, while VMs are usually gigabytes (GB).

What is a Dockerfile?

A Dockerfile is a new kind of required file that will live in your project. It contains a set of instructions to containerize your project.

You might be wondering — how exactly does this solve the "It works on my machine" problem? Here's the thing: with a Dockerfile, you build your own project image and share it. Inside the Dockerfile, you specify what environment the image will run on — it can be node:xx-alpine, ubuntu:xx, or many others. With those instructions starting from FROM, you can build and share your project image, and other engineers can run your project without having to replicate your local setup.

Basic Docker Commands

To run an image (whether one you built or one you pulled from DockerHub), just run:

docker run {image_name}

To see the list of currently running containers:

docker ps

Or to see all containers (including stopped ones):

docker ps -a

To build an image from your project (make sure your Dockerfile exists), run this in your project directory:

docker build -t my-project .

This will build a Docker image with my-project as the image name.

When I said Docker is just the tip of the iceberg, I wasn't lying — because within Docker itself, you can orchestrate images, manage the network between containers, manage storage and data inside containers, and much more.

I'll cover that in next week's post about Docker Compose — stay tuned!

DEV Community: ann

Docker Fundamentals: The Tip of the Iceberg