Stage 1 - Containerization Fundamentals
Before learning commands, you need to understand the exact problem Docker solves. Most teams do not adopt containers because they like extra tooling. They adopt them because application setup becomes too dependent on individual machines.
The problem in plain words
A developer says: “it works on my machine”. Usually that means the code is not the whole system. The system also includes Java version, OS libraries, database version, open ports, local files, environment variables, and startup commands. If those parts are installed manually, every machine slowly becomes unique.
A virtual machine solves this by packaging a whole guest operating system. It is strong isolation, but it is heavy: each VM needs its own OS, memory, boot process, and maintenance. A container takes a smaller boundary. It packages a process and its filesystem dependencies while sharing the host kernel.
Docker became popular because it combined containers with a practical workflow: Dockerfile for build instructions, image for a repeatable artifact, registry for distribution, and Docker CLI for daily work.
Runtime becomes a declared artifact
1. Source code
2. Dockerfile describes runtime
3. Image is built once
4. Container runs from image
5. CI/server run same image
This is the core idea: Docker moves environment knowledge from a developer's memory into files, images, and commands that the team can review.
How to think about the boundary
The most important containerization idea is the boundary. Without Docker, the boundary of an application is fuzzy: some parts live in Git, some live in a wiki, some live in a developer laptop, and some live in CI configuration. Docker does not remove the need to understand those parts, but it forces the team to name them.
A container boundary usually includes the process, filesystem dependencies, environment variables, user, network interfaces, and resource limits. It does not include the whole operating system in the same way a virtual machine does. This is why containers start quickly and why they are usually cheaper to run than VMs.
For a beginner, this distinction matters because it prevents wrong expectations. A container can isolate an application process, but it still depends on the host kernel and Docker runtime. It is repeatable, not magical.
Where Docker helps first
The first useful Docker scenario is onboarding. Instead of asking a new developer to install PostgreSQL, Redis, Java, and a set of command-line tools manually, the project can provide a Compose file or a documented set of Docker commands. The new developer still needs to understand the services, but the startup path becomes repeatable.
The second scenario is CI. A pipeline can pull the same image tag that developers use locally, run tests against real dependencies, and avoid a hidden dependency on whatever happens to be installed on the CI worker.
The third scenario is deployment. A server should run a known image version, not rebuild the application from an unknown local state. This makes rollback and investigation possible.
Where Docker actually runs
Docker is installed on a real machine. That machine can be your laptop, a CI runner, or a Linux server. Docker does not run in the browser and it does not automatically run somewhere in the cloud. When a learner types docker run, they usually type it in a terminal on their own computer.
The command is handled by Docker CLI, the command-line client. The CLI sends a request to Docker Engine. Docker Engine includes the Docker daemon, a background service that creates images, containers, networks, and volumes on that machine.
On Linux, the daemon works directly with the Linux kernel. On macOS and Windows, Docker Desktop usually runs a small Linux virtual machine in the background, because containers need Linux kernel features. The user still types commands in the normal terminal, but the containers actually run inside Docker Desktop’s Linux environment.
Docker Hub or another registry is remote. It stores images. Your machine pulls an image from the registry, then the local Docker daemon creates a container from it. After that, the container runs locally unless you are connected to a remote Docker host.
Commands to run and inspect
Run these commands in a terminal on the machine where Docker is installed. For local learning, that is your laptop terminal. For a VPS, first connect to the server with SSH, then run the commands there. Do not paste commands blindly: run one command, inspect what changed, then run the next one.
docker version
docker run hello-world
docker ps -a
docker rm <container-id>
Reference table
| Topic | What it means | Practical consequence |
|---|---|---|
| Manual setup | Dependencies installed by hand on every machine | Fast at first, unstable later |
| Virtual machine | Full guest OS with strong isolation | Useful when OS-level isolation matters |
| Container | Isolated process plus packaged filesystem | Best default for repeatable app runtime |
Environment audit
Before using Docker in a project, write down what is currently hidden in the developer machine. Include runtime versions, external services, ports, local files, and environment variables.
If a new teammate cannot recreate that list from the repository, the project still has undocumented environment state. Docker should make that state visible.
Checkpoint
You are ready to continue when you can explain why a container is lighter than a virtual machine, why an image is not the same as a container, and why Docker helps CI run the same thing developers run locally.
Practical environment exercise
Take a real project and write two columns: what belongs to the application repository and what currently belongs to a developer machine. Put Java version, database version, Redis, ports, environment variables, and startup commands into the second column if they are not described in the repository. Then mark which items Docker can make explicit through a Dockerfile, Compose file, image tag, or documented command. This exercise makes the phrase “works on my machine” concrete instead of emotional.