“You don’t truly understand Docker until you stop thinking in commands and start thinking in layers.”
Welcome to the ultimate deep-dive into Docker’s internal architecture – beyond the typical “10 must-know commands” and into what really makes Docker containers tick. If you’ve ever wondered “Where does my data go?”, “Why are my changes gone after a restart?” or “Isn’t a container just an image?”, you’re in the right place.
This post explains Docker conceptually, visually and practically – drawing parallels to traditional OS installation and imaging to make things crystal clear 💡.
🧊 What Is a Docker Image, Really?
A Docker image is your starting point. It’s:
- 📦 A collection of read-only layers
- 🧱 Built via
Dockerfileinstructions (FROM,RUN,COPY, etc.) - 🧬 Immutable and reusable – you can run it thousands of times
Think of a Docker image like a Windows ISO or a Linux distro installer. It’s a frozen, clean, unbooted system state.
🔁 You can copy, distribute, and reuse this image without worrying about what happens during runtime. It never changes – that’s the point.
⚙️ So What Makes a Container?
When you run a container, Docker does more than just unpack the image.
It adds a few critical components on top:
| Component | What it does |
|---|---|
| 🧱 Image Layers | Base filesystem, read-only |
| ✏️ Writable Container Layer | Stores runtime changes (files, logs, installs) |
| 🧠 Runtime Metadata | Namespaces, cgroups, container ID |
| 🌐 Networking Context | IP, ports, bridges, DNS |
| 🧩 Environment & Entrypoint | Startup configs & variables |
So, a container = image + writeable layer + runtime context.
Without that writable layer and runtime scaffolding, you’re not running a container — you’re just holding an image.
📝 Writable Layer: Your Temporary Workbench
Every running container gets its own writable layer:
- 🛠️ Anything you change in the filesystem (install a package, create a file) lives here
- 🔄 It’s unique per container
- 🧽 It’s ephemeral — deleted if the container is removed (unless committed or externalized)
💡 Analogy: It’s like booting a Live Linux distro and saving files in memory. They exist… until reboot.
🧪 What Goes Into the Writable Layer?
✅ File changes
✅ Software installations
✅ Edited config files
✅ Application logs
✅ Cached data and temp files
❌ Does not touch the original image. The base layers stay unchanged. That’s the beauty of Docker’s copy-on-write model.
💾 Where Do You Put Persistent Data?
Since the writable layer is volatile, Docker gives you two ways to store data outside the container:
📂 1. Volumes
- Managed by Docker
- Exists independently of containers
- Ideal for databases, app storage
docker run -v myvolume:/data myimage
🗂️ 2. Bind Mounts
- Mount a specific folder from the host
- Transparent and flexible, but less portable
docker run -v /host/folder:/app/data myimage
🧠 Best practice: always externalize any data you want to survive container deletion.
🧪 Experiment: What If a Container Had No Writable Layer?
Imagine starting a container without:
- A writable layer
- A process context
- Any networking
❄️ It would be frozen. Unusable. Just the image.
✅ The moment Docker runs an image, it adds context: processes, memory, IP stack, a filesystem you can write to — and that’s what we call a container.
🏗️ Is Configuration Permanent?
There are two types of configuration:
🔄 Temporary (per container)
Set via docker run or docker-compose:
--env,--name,-p,--mount, etc.- Stored in the container’s metadata
- ❗ Gone if the container is deleted
🧱 Permanent (baked into image)
Set via Dockerfile:
ENV,EXPOSE,VOLUME,ENTRYPOINT- Becomes part of every container based on that image
🧪 Want to freeze a modified container?
docker commit mycontainer alex/image:configured
That makes a new image including your changes and configuration.
💡 Docker vs Traditional Imaging (Why You’re Not Wrong)
This all sounds familiar, doesn’t it?
That’s because Docker is basically:
🖥️ Operating system imaging 2.0 — just faster, cleaner, modular and containerized.
| Traditional Imaging | Docker |
|---|---|
| Windows ISO / Ghost image | Docker Image |
| OS installation | docker run |
| System changes | Writable Container Layer |
| Capture custom system | docker commit or docker build |
| Restore / Deploy | docker run myimage |
So yes – your intuition is spot-on. Docker modernizes the old “install → customize → capture” cycle into something far more powerful and portable.
📌 Key Takeaways
✔ A Docker image is a read-only blueprint
✔ A container is a live instance with its own writable layer
✔ Runtime info (processes, IPs, mounts) only exists while the container is running
✔ Containers are ephemeral – make data persistent via volumes or bind mounts
✔ If you want changes to persist across runs, build a new image
🎯 Final Words
You now understand Docker better than many who’ve been using it for years. Why? Because you see how it works under the hood, not just which buttons to press.
If you take away one thing, let it be this:
A Docker container is more than just a running image.
It’s a composite of filesystem layers, runtime metadata, and process isolation – built to be reproducible, disposable, and efficient.
🔥 Use that knowledge. Structure your containers wisely. And don’t be afraid to build your own images — it’s how Docker is meant to shine.
✍️ Written by: OpenAi
📍 Topics: Docker Internals, Images vs Containers, Container Architecture, Data Persistence