0.1What Docker is for: containers vs virtual machines
The essentials in 30 seconds
- Docker packs the application AND its environment into a standard package, the container: no more "it works on my machine".
- The container shares the host kernel and only isolates what is needed: startup in seconds, weight in megabytes — it is not a VM.
- We run versioned images, identical everywhere; at large scale we add an orchestrator (Swarm, Kubernetes).
Running mini-case — Idir is tired of "it works on my machine" in Algiers
Idir, junior DevOps in Algiers, ships a website that runs on his laptop but breaks on the test server: different Node version, missing Redis, forgotten variable. He applies the section's checklist: the problem comes from the environment, not the code → he packs the application AND its environment into versioned images (site + Redis cache), launched as containers. Same image on his laptop, the test server and production: same behavior everywhere. He also notes the limit: for two containers, Docker is enough; for dozens of critical services, an orchestrator will be needed.
Self-contained case for this section: it returns in the lesson, diagram, script and 48h challenge of section 0.1.
1. The problem: "it works on my machine"
An application depends on its language version, its libraries, its system and its configuration. On the developer's machine everything works, in production everything breaks. Docker answers this plague by packing the application AND its environment into a standard package: the container. Idir keeps the picture: the code travels with its suitcase, not alone.
2. Container vs virtual machine: the real difference
A virtual machine virtualizes a whole computer (guest system + kernel + reserved resources): heavy and slow to start. A container shares the host kernel and only isolates what is needed (processes, files, network): it starts in seconds, weighs a few megabytes and multiplies easily. It is the microservice tool, not the universal server replacement. Idir decides: same kernel and light need → container; different kernel or strong isolation → VM.
3. Where Docker stops
Docker packs and runs, it does not orchestrate at large scale (that is Swarm's or Kubernetes' job), does not monitor and replaces neither backups nor system security. For a workstation, a small server or a CI pipeline, Docker is enough; for dozens of critical services, move to an orchestrator. Idir frames his scope: Docker to pack and run, the orchestrator later.
Did you know? The travelling canteen
Same canteen everywhere, same taste everywhere.
🔎 Concrete example — 🔎 Concrete example — One site running the same everywhere
Idir ships a Node 20 site with Redis: two containers from two versioned images, without installing Node or Redis on the machine.
docker run -d -p 3000:3000 --name site mon-app:1.0
docker run -d --name cache redis:7Reading: two containers started from two versioned images, without installing Node or Redis on the machine.
Lesson: the laptop, the test server and production run exactly the same images.
Section vocabulary
- Container
- An isolated process + its filesystem, started from an image.
Simple example: Idir starts the site container from the mon-app:1.0 image.
What it is not: a full virtual machine with its own kernel.
Reflex: light, fast, one role per container.
- Image
- The immutable, versioned template from which containers are born.
Simple example: Idir freezes mon-app:1.0: same dependencies on every machine.
What it is not: a live container you modify.
Reflex: always an explicit version tag, never latest in production.
- Docker Engine
- The engine that builds, stores and runs images and containers.
Simple example: Idir checks the engine is running before launching his site.
What it is not: the single docker command typed at the keyboard.
Reflex: engine stopped = no container starts.
- Registry
- The store of versioned images (Docker Hub, GHCR).
Simple example: Idir pulls redis:7 from the registry instead of installing it.
What it is not: the machine's local disk.
Reflex: name the image with its tag before sharing it.
- Port mapping
- The -p 3000:3000 redirection between the machine and the container.
Simple example: Idir reaches his site on port 3000 thanks to the 3000:3000 mapping.
What it is not: the internal port alone, with no exposure.
Reflex: unreachable? check the -p first.
In practice — In practice — Placing Docker in your context
- List three programs you painfully install (versions, conflicts, docs), like Idir with Node and Redis.
- For each, say whether a versioned container would fix the problem.
- Spot a case where a VM would stay preferable (different kernel, strong isolation).
- State in one sentence what Docker will bring you.
Step-by-step script — framing Idir's case before installing (3 min)
1) Write down Idir's pair: application + environment (e.g. Node 20 site + Redis) that diverges between laptop and server. 2) Split into roles: one site container, one cache container — never everything in one. 3) Note the target versioned image per role (e.g. mon-app:1.0, redis:7): same image on every machine. 4) Check the limit: 2 containers → Docker is enough; different kernel or strong isolation → VM; dozens of services → orchestrator later.
Keep this card: sections 0.2 to 0.4 turn it into real commands.
Copy-paste template — my Docker or VM card?
Case: ___ (e.g. Idir's Node 20 site + Redis).
Roles: [ ] site / [ ] database / [ ] cache → 1 container per role.
Versioned images: ___:___ + ___:___ (never latest in production).
Decider: [ ] same kernel + lightweight → container / [ ] different kernel or strong isolation → VM.
Scale: [ ] workstation / small server / CI → Docker is enough / [ ] dozens of services → orchestrator.Site + cache
Idir ships his Node 20 site with Redis: two versioned containers, zero local installation of Node or Redis.
Different kernel
Idir must test a system with a different kernel: he keeps a VM, since the container shares the host kernel.
Small server
Two or three services on a small server: Idir stays on Docker, with no orchestrator.
CI pipeline
Each build replays the same versioned images: Idir removes "it works on my machine" from CI.
✓ Best practices
- Think versioned image: never "latest" in production.
- Aim for one container = one role (web, database, cache).
- Know the limit: orchestration is the next step.
✗ Common pitfalls
- Believing Docker is a lightweight VM (the kernel is shared).
- Putting database + app + cache in the same container.
- Expecting monitoring and backups from Docker.
Key takeaways
- Docker packs the app AND its environment.
- The container shares the kernel: lightweight and fast.
- We run versioned images, identical everywhere.
- At large scale, we add an orchestrator.
48h challenge — apply tomorrow
Fill in the Docker or VM card from the template on ONE real case (Idir's or yours): roles, versioned images, container/VM decider — in one sentence, say what Docker will bring you.
- I can explain in one sentence what Docker brings (app + environment, same image everywhere).
- I can decide container (lightweight, same kernel) vs VM (different kernel, strong isolation).
- I know the limit: orchestration, monitoring and backups are outside Docker.
Frequently asked questions
Does Docker replace a virtual machine?
No: the VM isolates a full system with its kernel, the container shares the host's. For different kernels (Windows vs Linux) or strong isolation, the VM stays relevant. Idir keeps the reflex: same kernel and light need → container; otherwise → VM.
Do you need to be a system administrator for Docker?
No: the basics (run, ps, logs, volumes, Compose) are learned in a few hours. Fine administration (networks, registries, security) comes later, level by level — exactly this guide's progression.
What is Docker's real strength compared with a classic installation?