BLOG06: Containerization Concepts

BLOG15: Containerization Concepts

Can we simulate container environment manually?

1. Building a final image by combining multiple image layers (Overlaying graphics)

If you want to take folder of images (PNG/JPG etc.) and overlay them to generate a final composite image (e.g., NFT layers, logos on top of base images, watermarks, etc.) — yes, absolutely possible.

Example with Python (Pillow library)

from PIL import Image

base = Image.open("layers/base/background.png").convert("RGBA")
layer1 = Image.open("layers/body/body1.png").convert("RGBA")
layer2 = Image.open("layers/head/head3.png").convert("RGBA")
layer3 = Image.open("layers/accessories/hat2.png").convert("RGBA")

final = Image.alpha_composite(base, layer1)
final = Image.alpha_composite(final, layer2)
final = Image.alpha_composite(final, layer3)

final.save("output/final.png")

This overlays each layer on top of the previous one.

2. Using Docker to build an image from folders (Docker layering)

If your question means building a Docker image from folders and overlay file systems, then yes — Docker already uses an overlay filesystem.

Example:

Dockerfile
project/
 ├── app/
 ├── public/
 ├── config/

Docker puts these into layers during build.

3. Building a filesystem image (ISO, squashfs, qcow2) by overlaying folders

If you mean building OS images, like overlaying:

rootfs/
apps/
configs/

You can use:

OverlayFS (Linux)

upperdir=custom/
lowerdir=base/
workdir=work/
mount -t overlay overlay -o lowerdir=$lowerdir,upperdir=$upperdir,workdir=$workdir merged/

Creates a merged filesystem.

mksquashfs

mksquashfs merged/ final-image.squashfs

To understand how Docker images and layers function, this document provides a step-by-step demonstration of manually assembling a Docker image using core Linux tools.

Part 1: Understand How Docker Images Work

A Docker image = a stack of tarred filesystem layers + a config.json.

Internally:

image/
 ├── manifest.json
 ├── config.json
 ├── layer1.tar
 ├── layer2.tar
 └── layer3.tar

Each layer.tar is a complete snapshot of changes between layers.

Part 2: Manually Build a Root Filesystem

1. Create working directories

mkdir -p manual-image/rootfs
cd manual-image

2. Populate a base filesystem

For example, use BusyBox static binary (very small):

wget https://busybox.net/downloads/binaries/1.36.1-x86_64-linux-musl/busybox
chmod +x busybox

Create essential dirs:

mkdir -p rootfs/{bin,dev,proc,sys}
cp busybox rootfs/bin/

Link busybox applets:

(cd rootfs/bin && for cmd in $(./busybox --list); do ln -s busybox $cmd; done)

3. Create required dev nodes (minimal)

sudo mknod rootfs/dev/null c 1 3
sudo mknod rootfs/dev/zero c 1 5

You now have a working tiny Linux root filesystem.

Part 3: Verify it works (optional)

Use chroot:

sudo chroot rootfs /bin/sh

The output will be:

/ #

Exit using exit.

Part 4: Create a Docker Layer (layer.tar)

Docker expects a tar file representing the layer.

cd rootfs
sudo tar --numeric-owner -cf ../layer.tar .
cd ..

This is layer 1.

Part 5: Create the Docker metadata

Docker requires:

manifest.json

[
  {
    "Config": "config.json",
    "RepoTags": ["manual:latest"],
    "Layers": ["layer.tar"]
  }
]

config.json

Minimal config:

{
  "architecture": "amd64",
  "os": "linux",
  "rootfs": {
    "type": "layers",
    "diff_ids": ["sha256:<LAYER_SHA256>"]
  },
  "config": {
    "Cmd": ["/bin/sh"]
  }
}

Compute the diffid:

sha256sum layer.tar

Put that value into config.json.

Part 6: Import the Image into Docker

tar -cf manual-image.tar manifest.json config.json layer.tar
docker load < manual-image.tar

Check:

docker images
docker run -it manual:latest

The output should show a BusyBox shell:

/ #

Part 7: Build More Layers (Optional)

To add files:

mkdir layer2
echo "hello" > layer2/hello.txt
tar -cf layer2.tar -C layer2 .

Then add to:

manifest.json
config.json → add new diffid

Summary

Step

What you did

Build rootfs

Created a minimal filesystem (like Docker does)

Tar it

This becomes a Docker layer

Add metadata

Docker uses manifest + config

docker load

Loads your manually-built image

This section covers how Docker physically stores images and containers on disk. This includes where image layers and container filesystems are stored, how Docker assembles everything so containers can run, and what happens under the hood.

/var/lib/docker/overlay2/

and how OverlayFS works under the hood.

This section covers:

How Docker overlays layers
How to manually overlay folders
How to get the "top merged view"
How this matches Docker container storage

1. Quick Overview: How Docker Uses OverlayFS

When Docker launches a container:

lowerdir = read-only image layers
upperdir = container writes (copy-on-write)
workdir  = OverlayFS work area
merged   = what the container sees

Example path:

/var/lib/docker/overlay2/<layer-id>/diff/

When a container runs:

/var/lib/docker/overlay2/<container-id>/diff/  ← upperdir
/var/lib/docker/overlay2/<container-id>/merged  ← overlay mount

You can inspect with:

docker inspect <container>

Look for:

"GraphDriver": {
  "Data": {
    "LowerDir": "...",
    "UpperDir": "...",
    "MergedDir": "...",
    "WorkDir": "..."
  }
}

2. Manually Overlay Two Folders (Like Docker Does)

We simulate Docker’s overlay using your own folders.

Step 1: Create lower (base image layer)

mkdir -p /tmp/lower
echo "I am base file" > /tmp/lower/base.txt
echo "FROM LOWER" > /tmp/lower/same.txt

Step 2: Create upper (container's writable layer)

mkdir -p /tmp/upper
echo "I am updated" > /tmp/upper/same.txt
echo "NEW FILE" > /tmp/upper/new.txt

Step 3: Create work + merged dirs

mkdir -p /tmp/work
mkdir -p /tmp/merged

Step 4: Mount Overlay

sudo mount -t overlay overlay \
  -o lowerdir=/tmp/lower,upperdir=/tmp/upper,workdir=/tmp/work \
  /tmp/merged

3. Check the Top (Merged) View

Check the merged directory:

ls /tmp/merged

The output should show:

base.txt
new.txt
same.txt

Open the overlapped file:

cat /tmp/merged/same.txt

Output:

I am updated

This is copy-on-write!

4. OverlayFS Delete Example (Docker Whiteout)

Simulate deletion in upper layer (delete file in a read-only layer):

rm /tmp/merged/base.txt

Now check:

ls /tmp/merged

The file base.txt will not be visible.

Upperdir will contain a whiteout marker:

ls /tmp/upper

The output will show something like:

.wh.base.txt

This hides the file from the lower layer — Docker does this internally.

5. Compare With How Docker Does It

To inspect a running container:

docker inspect <container>

The output will show something like:

LowerDir: "/var/lib/docker/overlay2/123/diff:/var/lib/docker/overlay2/456/diff"
UpperDir: "/var/lib/docker/overlay2/abc/diff"
WorkDir: "/var/lib/docker/overlay2/abc/work"
MergedDir: "/var/lib/docker/overlay2/abc/merged"

If you enter the merged dir:

sudo ls /var/lib/docker/overlay2/abc/merged

This is exactly the overlay mount we created manually.

6. Multi-layer Overlay Example (like Docker Image Layers)

Docker might have 5 layers:

layer1
layer2
layer3
layer4
layer5

OverlayFS supports stacking:

lowerdir=/layer5:/layer4:/layer3:/layer2:/layer1

Example:

sudo mount -t overlay overlay \
  -o lowerdir=/img/5:/img/4:/img/3,upperdir=/container-write,workdir=/work \
  /merged

7. Why merged view feels like "final Docker image"

Because Docker literally uses OverlayFS as the live root filesystem.

Summary

Concept

Meaning

lowerdir

read-only layers from image

upperdir

writable layer (container)

merged

what container sees (both merged)

whiteout

hides deleted files from lower layers

workdir

OverlayFS internal use

This section explains Docker networking using only Linux primitives — network namespaces + veth pairs + bridges + routing + iptables — the same way Docker builds networking internally (via containerd + netns + bridge).

Before we dive in, consider these questions to help guide your understanding:

What does a "network namespace" actually isolate in Linux?
What is a veth pair, and how does it simulate a network interface inside a container?
Why does Docker use a software bridge (like docker0) rather than connecting containers directly to the host network?
How does Docker make it possible for containers to access the internet without being directly exposed?
What roles do iptables and NAT play in container networking?
How are all these pieces (namespaces, veths, bridges, routing) connected together in practice?

These questions will be answered as we step through building Docker-style networking from scratch.

This is the equivalent of your previous request about overlay filesystem but now for Docker networking.

How Docker Networking Works Internally

When executing:

docker run -it ubuntu

Docker creates:

Network Namespace → isolated network stack for the container
veth pair → one end inside container, one end on host
Bridge on host (docker0) → virtual switch
IP assignment → via Docker’s built-in DHCP
NAT → iptables MASQUERADE for internet access
Routing → default route via bridge

The following steps demonstrate how to build all this manually.

STEP 1: Create a Network Namespace (Container Equivalent)

sudo ip netns add mycontainer

Check:

ip netns list

STEP 2: Create a veth Pair (Like Docker Does)

A veth pair is like a virtual ethernet cable.

sudo ip link add veth0 type veth peer name veth1

veth0 → on the host
veth1 → inside the container namespace

STEP 3: Move One End Into the Namespace

sudo ip link set veth1 netns mycontainer

Now:

Host has: veth0
Namespace has: veth1

STEP 4: Create docker0 Bridge (Docker Default Network)

Docker normally creates:

docker0: 172.17.0.1/16

We simulate:

sudo ip link add name br0 type bridge
sudo ip addr add 10.0.0.1/24 dev br0
sudo ip link set br0 up

STEP 5: Attach veth0 to the Bridge

sudo ip link set veth0 master br0
sudo ip link set veth0 up

STEP 6: Set IP Inside Container Namespace

Assign IP to veth1:

sudo ip netns exec mycontainer ip addr add 10.0.0.2/24 dev veth1
sudo ip netns exec mycontainer ip link set veth1 up

STEP 7: Bring Up Loopback in Namespace

sudo ip netns exec mycontainer ip link set lo up

STEP 8: Set Default Route (Like Docker Does)

sudo ip netns exec mycontainer ip route add default via 10.0.0.1

TEST: Ping Host from Container Namespace

sudo ip netns exec mycontainer ping 10.0.0.1

This should work successfully.

TEST: Ping Between Containers

If you create a second netns with IP 10.0.0.3/24, both can communicate via br0.

STEP 9: Enable NAT (Docker Does This)

Docker sets:

iptables -t nat -A POSTROUTING -s 172.17.0.0/16 ! -o docker0 -j MASQUERADE

Equivalent for your 10.0.0.0/24 network:

sudo iptables -t nat -A POSTROUTING -s 10.0.0.0/24 -j MASQUERADE

Enable IP forwarding:

sudo sysctl -w net.ipv4.ip_forward=1

Now outgoing packets from namespace → NAT → internet.

TEST: Ping Google DNS (8.8.8.8)

sudo ip netns exec mycontainer ping 8.8.8.8

Summary

The full Docker networking model has been manually recreated:

Component

Manual Equivalent

Container namespace

ip netns add

veth pair

ip link add veth0 type veth peer veth1

docker0 bridge

ip link add name br0 type bridge

IP assignment

ip addr add

Routing

ip route add default

NAT

iptables -t nat -A POSTROUTING

This is exactly what Docker’s libnetwork / containerd do behind the scenes.

This section covers the third core concept of Docker, after:

Storage (OverlayFS)
Networking (Namespace + veth + bridge)

Now we look at:

Docker User Process Isolation using Linux Namespaces + cgroups

Docker is NOT a VM. It simply launches your process in a set of isolated namespaces:

PID namespace   → isolated process tree
NET namespace   → isolated networking
MNT namespace   → isolated filesystem
UTS namespace   → hostname isolation
IPC namespace   → message queues
USER namespace  → UID remapping
CGROUPS         → resource limits

The following steps demonstrate how to manually build a mini-container by:

creating namespaces
starting a process inside them
applying isolation
mounting a filesystem

This is the closest raw version of what docker run actually does.

1. Launch a Process in New Namespaces (container-like)

Use the unshare command (part of util-linux).

Smallest "container" ever:

sudo unshare -pfmu --mount-proc bash

Flags:

Flag

Namespace

-p

PID namespace

-f

fork into new PID namespace

-m

mount namespace

-u

UTS (hostname)

--mount-proc

create new /proc

Inside this “container” shell:

bash$ ps aux

The output will show:

PID 1  = bash
PID 2  = ps

You are PID 1 inside a container (like Docker does).

2. Set a Hostname (UTS Namespace)

Inside the unshared shell:

hostname mini-container
hostname

Output:

mini-container

On the host, your hostname remains unchanged.

This is exactly how Docker lets each container have its own hostname.

3. Create an Isolated Root Filesystem (mount namespace)

In another terminal:

mkdir -p /tmp/rootfs/{bin,lib,lib64}
cp /bin/bash /tmp/rootfs/bin
cp /lib/x86_64-linux-gnu/libtinfo* /tmp/rootfs/lib
cp /lib/x86_64-linux-gnu/libc* /tmp/rootfs/lib
cp /lib64/ld-linux* /tmp/rootfs/lib64

Now launch new namespaces and change root:

sudo unshare -pfmu chroot /tmp/rootfs /bin/bash

Inside this chroot container:

/# ls
bin  lib  lib64

You now have:

own filesystem
own PID tree
own mount table
own hostname

This is basically Docker without networking.

4. Combine Namespaces + Chroot → Full Minimal Container

Full example:

sudo unshare --pid --mount --uts --ipc --net --user --map-root-user bash

Inside:

mount -t proc proc /proc
hostname sandbox

Your mini-container now has:

PID namespace
Mount namespace
Network namespace
UTS (hostname)
IPC namespace
USER namespace

Exactly what Docker uses.

5. Add cgroups → Resource limits (like `docker run --cpus 1 --memory=256m`)

Create a cgroup:

sudo mkdir /sys/fs/cgroup/mygroup

Limit CPU:

echo 50000 | sudo tee /sys/fs/cgroup/mygroup/cpu.max

Limit memory:

echo 100M | sudo tee /sys/fs/cgroup/mygroup/memory.max

Now add your bash process to the cgroup:

echo $$ | sudo tee /sys/fs/cgroup/mygroup/cgroup.procs

Now that process and its children cannot exceed that resource limit.

Docker does exactly the same.

6. Understanding Docker in 1 Sentence

Docker = Linux namespaces + cgroups + overlay filesystem + networking tools + container runtime wrapper

All Docker does is:

1. prepare filesystems

2. prepare networking

3. isolate namespaces

4. apply cgroups

5. run process inside isolation

Final Full Example: Starting a Process in "Container Mode"

sudo unshare --pid --mount --uts --ipc --fork --mount-proc \
  bash -c "
    hostname demo-container;
    mount -t proc proc /proc;
    echo 'Inside container:'; ps aux;
    sleep 1000;
"

You have now launched a real container-like environment without Docker.

Next Steps

The following topics can be covered:

How Docker uses containerd + runc + OCI runtime spec

How `docker run` translates into runc commands

Build your own container runtime (40 lines of Go!)

How Docker namespaces map to `docker inspect` output

How Docker really launches a container under the hood using containerd + runc + OCI bundle

You will understand exactly what happens when you run docker run ubuntu bash.

This is the most important piece of all the Docker internals.

1. Docker Architecture in Reality

Docker is not the “runtime”. It's a wrapper.

Here’s the true pipeline:

Docker CLI
    ↓
Dockerd (Docker daemon)
    ↓
containerd (container manager)
    ↓
runc (OCI runtime)
    ↓
Linux kernel (namespaces + cgroups)
    ↓
Your process (PID 1)

So the real container engine is runc, NOT Docker.

2. runc Needs an OCI Bundle (RootFS + Config)

Every container runc runs needs:

bundle/
 ├── config.json   ← OCI Spec
 └── rootfs/       ← filesystem of container

We will build this manually.

3. Create a Minimal Root Filesystem

Same as before:

mkdir -p bundle/rootfs

Populate with busybox:

cp busybox bundle/rootfs/bin/
chmod +x bundle/rootfs/bin/busybox
(cd bundle/rootfs/bin && for i in $(./busybox --list); do ln -s busybox $i; done)

Now your rootfs contains a working BusyBox environment.

4. Generate a Default OCI Config

If you have runc installed:

cd bundle
runc spec

This will create:

config.json

This is what Docker would generate automatically.

This JSON describes:

namespaces
mounts
process command
user id mapping
capabilities
cgroups
hostname

Everything.

5. Modify config.json to run a command

Inside config.json, change:

"args": ["sh"]

You can set hostname:

"hostname": "demo"

6. Run the Container Using ONLY runc

From inside the folder:

sudo runc run demo-container

You now have a real Linux container without Docker.

Inside you will see:

/ # hostname
demo
/ # ps
PID 1 – busybox sh

This is the exact same thing Docker does.

7. Summary of what has been built:

Component

Docker Does

You Did

Extract image layers

yes

you created rootfs yourself

Create OCI config.json

yes

you generated with runc spec

Create namespaces

containerd + runc

runc created them

Set cgroups

dockerd

runc used default cgroup rules

Set hostname

docker

config.json hostname

Mount /proc

docker

mount-proc auto in runc

Launch PID1

bash/sleep/node

you ran sh

8. Compare With What Docker Would Run

To see Docker's actual call:

When you run:

docker run -it ubuntu bash

Docker builds an OCI bundle under:

/run/containerd/io.containerd.runtime.v2.task/moby/<container-id>/

Inside you will find:

config.json
rootfs/

Docker then calls:

runc run <id> --bundle /path/to/bundle

Exactly same thing you just did manually.

This section covers Docker volumes, how they work under the hood, and how files are mounted inside containers. This is the storage counterpart to what we already explored with OverlayFS and namespaces.

Before we start, consider these questions:

Why do containers need volumes if OverlayFS already provides a layered filesystem?
How do Docker volumes differ from bind mounts or tmpfs?
Where does Docker store the actual data for a volume on the host?
What happens to the data in a Docker volume when the container is deleted?
How does Docker "mount" a volume inside a running container?
How can you inspect which volumes are attached to a container?

Keep these in mind as we explore Docker volumes and storage!

1. Docker Volumes Overview

A Docker volume is a persistent storage mechanism that lives outside of the container’s UnionFS layer.

Key points:

Feature

Description

Persistence

Survives container deletion

Location

Managed by Docker on the host

Isolation

Mounted into container via mount point

Types

Named volumes, anonymous volumes, bind mounts, tmpfs

2. Where Docker Stores Volumes on the Host

By default:

/var/lib/docker/volumes/<volume-name>/_data

Example:

docker volume create mydata
docker volume inspect mydata

Output:

[
  {
    "Name": "mydata",
    "Driver": "local",
    "Mountpoint": "/var/lib/docker/volumes/mydata/_data",
    "Scope": "local"
  }
]

Mountpoint → actual host path storing files.
_data → the folder that will be mounted into containers.

3. Mounting Volume into a Container

Suppose we run:

docker run -it -v mydata:/app/data ubuntu bash

Docker mounts:

Host: /var/lib/docker/volumes/mydata/_data
Container: /app/data

Any read/write to /app/data in container directly reflects on host.

4. How This Works Internally

Docker uses mount namespaces + bind mounts.

A bind mount is essentially:

mount --bind /var/lib/docker/volumes/mydata/_data /path/in/container

Container sees /app/data but the kernel maps it to host storage.
OverlayFS is not involved here — Docker volumes bypass container filesystem layers for performance and persistence.

5. Example: Manual Volume Mount

Suppose you want to simulate Docker volume without Docker:

mkdir /tmp/myvolume
echo "Hello from host" > /tmp/myvolume/file.txt

# Create a container namespace
sudo unshare --mount --uts --pid --fork bash

# Inside the namespace, mount the host folder
sudo mount --bind /tmp/myvolume /mnt/data

ls /mnt/data
cat /mnt/data/file.txt

Output:

file.txt
Hello from host

This is exactly how Docker mounts volumes.

6. Named vs Bind Mounts

Named volume: Docker manages /var/lib/docker/volumes/<name>/_data
Bind mount: You mount any host folder:

docker run -v /home/user/config:/app/config ubuntu

Host path /home/user/config directly appears in container /app/config.

7. Key Takeaways

Concept

Host

Container

Notes

Volume storage

/var/lib/docker/volumes/<name>/_data

/mount/point/in/container

Bind mount behind the scenes

Persistence

Yes

Independent of container lifecycle

OverlayFS involvement

Volume bypasses image layers

Bind mount

Any folder

Mounted into container

Useful for dev/test

8. How Docker actually does it

When you run:

docker run -v mydata:/app/data ubuntu

Docker (via containerd + runc) performs:

Prepares rootfs for container (OverlayFS)
Prepares mount namespace for container
Binds the volume directory from host into container namespace:

mount --bind /var/lib/docker/volumes/mydata/_data /app/data

Launches container process (PID 1) in the namespace

Everything inside /app/data maps to host path directly.

1. Containers and Namespaces

When Docker launches a container, it creates isolated namespaces for:

PID → process tree
MNT → filesystem mounts
NET → networking
UTS → hostname
IPC → inter-process communication

Important: Each namespace is isolated logically, but they all share the same kernel.

Namespaces are not separate machines — they are kernel-level isolation.
They can see the kernel and the host’s storage, but only what is mounted into their mount namespace.

2. How a Container Can See Host Files

Docker uses bind mounts to share host paths with the container.

Example:

docker run -v /var/lib/docker/volumes/mydata/_data:/app/data ubuntu

Host path: /var/lib/docker/volumes/mydata/_data
Container mount point: /app/data

Internally, Docker does:

mount --bind /var/lib/docker/volumes/mydata/_data /app/data

Even though the container has a different mount namespace, the kernel allows this bind mount, so the container can see and write to the host directory.

3. Why it Works Across Namespaces

Mount namespace isolation only isolates mount points, not the underlying filesystem objects.
Bind mount creates a reference from host FS into container FS.
The kernel manages access; processes in different mount namespaces can see the same inode if it’s bind-mounted.

So even in a different MNT namespace:

container1: /app/data → host: /var/lib/docker/volumes/mydata/_data
container2: /app/data → host: /var/lib/docker/volumes/mydata/_data

Both containers see the same underlying data.
This is why volumes are shared storage.

4. Manual Example Without Docker

# Host
mkdir /tmp/shared
echo "Hello Host" > /tmp/shared/file.txt

# Container1 namespace
sudo unshare --mount --uts --pid --fork bash
sudo mount --bind /tmp/shared /mnt/data
cat /mnt/data/file.txt
# Output: Hello Host

Open a second terminal:

# Container2 namespace
sudo unshare --mount --uts --pid --fork bash
sudo mount --bind /tmp/shared /mnt/data
cat /mnt/data/file.txt
# Output: Hello Host

Both namespaces see the same data because it's bind-mounted from host.

5. Key Takeaways

Concept

Detail

Mount namespaces

Isolate mount points, not the underlying FS

Bind mount

Exposes host directory into container namespace

Same kernel

All containers share kernel, so underlying storage is accessible

Docker volume

Just a managed host path, bind-mounted into containers

Isolation

Containers can’t see host FS outside bind mounts

So the container sees the host volume because:

The host path exists on the kernel.
Docker uses a bind mount into the container’s mount namespace.
Kernel enforces access; namespace isolation doesn’t block it.

PreviousBLOG05: Creating User Access NextLAB06: Play with Cluster

Last updated 1 month ago

Good night

hashtagBLOG15: Containerization Concepts

hashtagCan we simulate container environment manually?

hashtag1. Building a final image by combining multiple image layers (Overlaying graphics)

hashtagExample with Python (Pillow library)

hashtag2. Using Docker to build an image from folders (Docker layering)

hashtag3. Building a filesystem image (ISO, squashfs, qcow2) by overlaying folders

hashtagOverlayFS (Linux)

hashtagmksquashfs

hashtagPart 1: Understand How Docker Images Work

hashtagPart 2: Manually Build a Root Filesystem

hashtag1. Create working directories

hashtag2. Populate a base filesystem

hashtag3. Create required dev nodes (minimal)

hashtagPart 3: Verify it works (optional)

hashtagPart 4: Create a Docker Layer (layer.tar)

hashtagPart 5: Create the Docker metadata

hashtagmanifest.json

hashtagconfig.json

hashtagPart 6: Import the Image into Docker

hashtagPart 7: Build More Layers (Optional)

hashtagSummary

hashtag1. Quick Overview: How Docker Uses OverlayFS

hashtag2. Manually Overlay Two Folders (Like Docker Does)

hashtagStep 1: Create lower (base image layer)

hashtagStep 2: Create upper (container's writable layer)

hashtagStep 3: Create work + merged dirs

hashtagStep 4: Mount Overlay

hashtag3. Check the Top (Merged) View

hashtag4. OverlayFS Delete Example (Docker Whiteout)

hashtag5. Compare With How Docker Does It

hashtag6. Multi-layer Overlay Example (like Docker Image Layers)

hashtag7. Why merged view feels like "final Docker image"

hashtagSummary

hashtagHow Docker Networking Works Internally

hashtagSTEP 1: Create a Network Namespace (Container Equivalent)

hashtagSTEP 2: Create a veth Pair (Like Docker Does)

hashtagSTEP 3: Move One End Into the Namespace

hashtagSTEP 4: Create docker0 Bridge (Docker Default Network)

hashtagSTEP 5: Attach veth0 to the Bridge

hashtagSTEP 6: Set IP Inside Container Namespace

hashtagSTEP 7: Bring Up Loopback in Namespace

hashtagSTEP 8: Set Default Route (Like Docker Does)

hashtagTEST: Ping Host from Container Namespace

hashtagTEST: Ping Between Containers

hashtagSTEP 9: Enable NAT (Docker Does This)

hashtagTEST: Ping Google DNS (8.8.8.8)

hashtagSummary

hashtagDocker User Process Isolation using Linux Namespaces + cgroups

hashtag1. Launch a Process in New Namespaces (container-like)

hashtagSmallest "container" ever:

hashtag2. Set a Hostname (UTS Namespace)

hashtag3. Create an Isolated Root Filesystem (mount namespace)

hashtag4. Combine Namespaces + Chroot → Full Minimal Container

hashtag5. Add cgroups → Resource limits (like docker run --cpus 1 --memory=256m)

hashtag6. Understanding Docker in 1 Sentence

hashtag1. prepare filesystems

hashtag2. prepare networking

hashtag3. isolate namespaces

hashtag4. apply cgroups

hashtag5. run process inside isolation

hashtagFinal Full Example: Starting a Process in "Container Mode"

hashtagNext Steps

hashtagHow Docker uses containerd + runc + OCI runtime spec

hashtagHow docker run translates into runc commands

hashtagBuild your own container runtime (40 lines of Go!)

hashtagHow Docker namespaces map to docker inspect output

hashtagHow Docker really launches a container under the hood using containerd + runc + OCI bundle

hashtag1. Docker Architecture in Reality

hashtag2. runc Needs an OCI Bundle (RootFS + Config)

hashtag3. Create a Minimal Root Filesystem

hashtag4. Generate a Default OCI Config

hashtag5. Modify config.json to run a command

hashtag6. Run the Container Using ONLY runc

hashtag7. Summary of what has been built:

hashtag8. Compare With What Docker Would Run

hashtag

hashtag

hashtag1. Docker Volumes Overview

hashtag2. Where Docker Stores Volumes on the Host

BLOG15: Containerization Concepts

Can we simulate container environment manually?

1. Building a final image by combining multiple image layers (Overlaying graphics)

Example with Python (Pillow library)

2. Using Docker to build an image from folders (Docker layering)

3. Building a filesystem image (ISO, squashfs, qcow2) by overlaying folders

OverlayFS (Linux)

mksquashfs

Part 1: Understand How Docker Images Work

Part 2: Manually Build a Root Filesystem

1. Create working directories

2. Populate a base filesystem

3. Create required dev nodes (minimal)

Part 3: Verify it works (optional)

Part 4: Create a Docker Layer (layer.tar)

Part 5: Create the Docker metadata

manifest.json

config.json

Part 6: Import the Image into Docker

Part 7: Build More Layers (Optional)

Summary

1. Quick Overview: How Docker Uses OverlayFS

2. Manually Overlay Two Folders (Like Docker Does)

Step 1: Create lower (base image layer)

Step 2: Create upper (container's writable layer)

Step 3: Create work + merged dirs

Step 4: Mount Overlay

3. Check the Top (Merged) View

4. OverlayFS Delete Example (Docker Whiteout)

5. Compare With How Docker Does It

6. Multi-layer Overlay Example (like Docker Image Layers)

7. Why merged view feels like "final Docker image"

Summary

How Docker Networking Works Internally

STEP 1: Create a Network Namespace (Container Equivalent)

STEP 2: Create a veth Pair (Like Docker Does)

STEP 3: Move One End Into the Namespace

STEP 4: Create docker0 Bridge (Docker Default Network)

STEP 5: Attach veth0 to the Bridge

STEP 6: Set IP Inside Container Namespace

STEP 7: Bring Up Loopback in Namespace

STEP 8: Set Default Route (Like Docker Does)

TEST: Ping Host from Container Namespace

TEST: Ping Between Containers

STEP 9: Enable NAT (Docker Does This)

TEST: Ping Google DNS (8.8.8.8)

Summary

Docker User Process Isolation using Linux Namespaces + cgroups

1. Launch a Process in New Namespaces (container-like)

Smallest "container" ever:

2. Set a Hostname (UTS Namespace)

3. Create an Isolated Root Filesystem (mount namespace)

4. Combine Namespaces + Chroot → Full Minimal Container

5. Add cgroups → Resource limits (like `docker run --cpus 1 --memory=256m`)

6. Understanding Docker in 1 Sentence

1. prepare filesystems

2. prepare networking

3. isolate namespaces

4. apply cgroups

5. run process inside isolation

Final Full Example: Starting a Process in "Container Mode"

Next Steps

How Docker uses containerd + runc + OCI runtime spec

How `docker run` translates into runc commands

Build your own container runtime (40 lines of Go!)

How Docker namespaces map to `docker inspect` output

How Docker really launches a container under the hood using containerd + runc + OCI bundle

1. Docker Architecture in Reality

2. runc Needs an OCI Bundle (RootFS + Config)

3. Create a Minimal Root Filesystem

4. Generate a Default OCI Config

5. Modify config.json to run a command

6. Run the Container Using ONLY runc

7. Summary of what has been built:

8. Compare With What Docker Would Run

1. Docker Volumes Overview

2. Where Docker Stores Volumes on the Host

3. Mounting Volume into a Container

4. How This Works Internally

5. Example: Manual Volume Mount