Docker is a tool that packs an app together with everything it needs to run: the right language version, its libraries and its settings. That package is called an image. When you start an image you get a container, which is your app running in its own small, walled-off space on the computer. Teams use Docker because a container runs the same way on a developer's laptop, a test server and the live server. That gets rid of most "it works on my machine" problems, lets a new teammate set up in minutes, and makes every deployment repeatable.
This post explains containers in plain words, then walks you through the first commands. If you have never used a terminal, read our post on Linux commands every beginner should learn first before you start. Docker is one of the main tools in DevOps, and our post on what a DevOps engineer does shows where it fits in a normal work week.
What problem does Docker solve?
Say you build a small web app on your laptop. It needs a certain Node.js version, a few npm packages and a PostgreSQL database. It works for you. Your friend clones the code and it fails, because their Node.js is older and they have no database installed. On the server it fails again, for a third reason. Every machine is set up a little differently, and each difference is one more way for the app to break.
Docker fixes this by shipping the setup along with the code. You write the setup down once, in a file called a Dockerfile, and Docker builds an image from it. Anyone who runs that image gets the same Node.js version, the same packages and the same settings, whatever is installed on their own computer.
What is a container, in plain words?
A container is a running program kept apart from the rest of the computer. It has its own files, its own installed software and its own network address. It can't see other containers or your personal files unless you allow it. To the app inside, it looks as if it has a small computer to itself.
Beginners often mix up two words. An image is the package: a read-only bundle of the app, its libraries and the command that starts it. It sits on disk and does nothing until you run it. A container is an image that is running. You can start many containers from one image, the same way you can open one app in several windows.
Images are shared through registries. Docker Hub is the public registry Docker uses by default, and it holds official images for Nginx, PostgreSQL, Python, Node.js and many more. So you rarely start from nothing. You take an official image and add your app on top.
Is a container the same as a virtual machine?
No. A virtual machine pretends to be a whole computer, with its own full operating system and its own kernel. The kernel is the core of the operating system, the part that talks to the hardware. Containers on one machine all share the host's kernel and carry only the files their app needs. That is why a container starts in a second or two and a small image can be tens of megabytes, while a virtual machine takes longer to boot and needs gigabytes.
Sharing the kernel has a cost. Containers are less sealed off from each other than virtual machines are. For running your own apps that is usually fine. Companies that run code from strangers add more isolation on top.
Why do teams use Docker?
- The app runs the same way everywhere. The image you tested is the exact image that goes to the server.
- New teammates start fast. Instead of following a page of setup steps, they run one command and get the app and its database.
- Versions stop clashing. One project can use PostgreSQL 16 and another PostgreSQL 17 on the same laptop, each in its own container.
- Deploying and rolling back get simpler. Each release is a new image with its own tag. If the new one breaks, you run the old tag again.
- Other tools build on it. CI/CD pipelines build a fresh image on every push, and Kubernetes, the system many companies use to run containers across many servers, runs those images.
How do you set up Docker on your laptop?
On Windows or a Mac, install Docker Desktop from docker.com. Containers need a Linux kernel, so Docker Desktop runs a small Linux virtual machine in the background. On Windows it uses WSL 2, the Windows Subsystem for Linux, and virtualization has to be turned on in your BIOS settings. On a Linux laptop you can install Docker Engine directly, which is free and open source.
Docker Desktop is free for personal use, education, non-commercial open source projects and small businesses with fewer than 250 employees and less than $10 million in yearly revenue. Bigger companies need a paid plan. As a learner, you are covered.
8GB of RAM is a sensible minimum for learning. Docker itself is light, but a database, your code editor and a browser running at once add up quickly.
Your first Docker commands
Once Docker is installed and running, open a terminal and check that it works:
docker run hello-worldDocker downloads a tiny image from Docker Hub, starts a container from it, prints a welcome message and stops. If you see the message, your setup works.
Now run a real web server:
docker run -d -p 8080:80 --name web nginxOpen http://localhost:8080 in your browser and you will see the Nginx welcome page. Each part of that command does one job:
-druns the container in the background.-p 8080:80connects port 8080 on your laptop to port 80 inside the container, where Nginx listens.--name webgives the container a short name, so you don't have to type its long ID.nginxis the image to run.
You will use these every day:
docker ps # list running containers
docker ps -a # list all containers, stopped ones too
docker logs web # see what the container printed
docker stop web # stop it
docker rm web # delete it
docker images # list the images on your laptopWhat does a Dockerfile look like?
A Dockerfile is a short text file of steps that builds your image. Here is one for a small Node.js app that starts from server.js:
FROM node:24-slim
WORKDIR /app
COPY package*.json ./
RUN npm ci --omit=dev
COPY . .
USER node
EXPOSE 3000
CMD ["node", "server.js"]Read it line by line. Start from the official Node.js 24 image in its slim version. Work inside a folder called /app. Copy the package files and install the packages. Copy the rest of the code. Switch to the normal node user that the official image includes, so the app doesn't run as root. Note that the app listens on port 3000, and say which command starts it. npm ci needs a package-lock.json, which npm creates the first time you install a package.
The package files are copied before the rest of the code for a reason. Docker saves the result of each step. If only your code changed since the last build, Docker reuses the saved install step and the build takes seconds instead of minutes.
Build and run it from the project folder:
docker build -t my-app .
docker run -p 3000:3000 my-appAlso add a .dockerignore file that lists node_modules and .env, so your local packages and your secrets stay out of the image.
What is Docker Compose?
Most apps need more than one container, for example the app plus a database. Docker Compose lets you describe all of them in one file, compose.yaml, and start them together:
services:
app:
build: .
ports:
- "3000:3000"
environment:
DATABASE_URL: postgres://app:secret@db:5432/app
depends_on:
- db
db:
image: postgres:17
environment:
POSTGRES_USER: app
POSTGRES_PASSWORD: secret
POSTGRES_DB: app
volumes:
- dbdata:/var/lib/postgresql/data
volumes:
dbdata:Run docker compose up and both containers start. The app finds the database at the name db, because Compose puts both containers on one private network. depends_on starts the database first, but it doesn't wait until the database is ready for connections, so a real app should retry its first connection. The password here is only for practice on your laptop. A real password never goes in a file you push to GitHub.
Mistakes beginners make with Docker
- Losing data. Files written inside a container are gone when the container is removed. Keep anything that matters, like database files, in a volume, as the Compose file above does.
- Putting secrets in the image. Anyone who gets the image can read what is inside it. Pass passwords and API keys in when the container starts, through environment variables or a secrets manager.
- Using the
latesttag for everything.latestpoints to a different version over time, so the same Dockerfile can build something different next month. Name a version for anything you deploy. - Huge images. Starting from a full operating system image when a slim one would do makes every build and download slower.
- Running as root. Many images run their process as the root user unless you change it. Switch to a normal user, as the Dockerfile above does.
What to learn after the basics
Once images, containers, volumes and Compose feel easy, build images automatically in a CI/CD pipeline on every push, push them to a registry and run them on a cloud server. After that comes Kubernetes, which runs containers across many servers and restarts them when they crash. Get comfortable with Docker before you start Kubernetes. Many problems you will debug in Kubernetes turn out to be plain container problems: a wrong port, a missing environment variable or an app that exits on start.
How our Cloud Computing and DevOps course teaches Docker
Docker is Week 5 of our Cloud Computing and DevOps course, after four weeks of Linux, scripting, Git, networking and AWS. That week covers:
- How containers share the host kernel, and the difference between an image and a container.
- Writing good Dockerfiles: choosing a base image, layer caching,
.dockerignore, a non-root user and multi-stage builds. - Ports, volumes, environment variables and secrets passed in at runtime.
- Finding out why a container broke, with
docker logs,exec,inspectand exit codes. - Running an app, a database and Nginx together with Docker Compose and health checks.
- Pushing images to a registry with clear tags, and scanning them for known security holes with Trivy.
From Week 6 the same images go through a GitHub Actions pipeline, and later in the course they run on Kubernetes. The full week-by-week plan and the syllabus PDF are on the course page.
