Cloud Native Rebuild – Week 0: Restarting Docker from the Basics
This is Week 0 of my Cloud Native Rebuild series.
Before jumping into Kubernetes for LFX open source contributions, I decided to restart Docker from scratch. I already knew the basics — but this time, I want depth, not just familiarity.
For this reset, I followed:
The official Docker documentation:
👉 https://docs.docker.com/get-started/docker-overview/A YouTube tutorial that walks through Docker fundamentals step by step:
👉 https://youtu.be/pg19Z8LL06w?si=T8hw7PvZVKZkm3ye
This week was purely theory + basic hands-on.
🐳 What is Docker?
Docker is a containerization platform that allows developers to package applications along with all dependencies into a single, portable unit called a container.
Instead of installing:
Node
Python
System libraries
Specific versions
Docker packages everything together.
So if it works on my system, it works everywhere.
⚙️ How Docker Works (Conceptually)
Docker uses OS-level virtualization.
Here’s the flow:
You define instructions in a Dockerfile.
Docker builds an Image.
The image is used to create a Container.
The container runs your application in isolation.
Important concept:
Containers share the host OS kernel, which makes them lightweight compared to virtual machines.
🚨 What Problem Docker Solves
Before Docker:
Environment mismatch between dev and production.
“Works on my machine” problems.
Manual dependency setup.
Difficult collaboration across teams.
Docker solves:
Environment consistency
Reproducible builds
Faster onboarding
Predictable deployments
Simplified CI/CD workflows
Docker standardizes how applications are built and deployed.
💻 Development & Deployment
Without Docker
Install dependencies manually.
Different Node/Python versions cause issues.
Setup instructions are long and error-prone.
Deployment often behaves differently than development.
With Docker
Application + dependencies bundled together.
Same environment everywhere.
One command to run.
Easy to deploy across machines or servers.
This is why Docker became foundational for cloud-native systems.
🖥️ Virtual Machine vs Docker
Understanding this difference was important for me.
| Virtual Machine | Docker Container |
| Has full guest OS | Shares host OS kernel |
| Heavy (GB size) | Lightweight (MB size) |
| Slower startup | Starts in seconds |
| Uses hypervisor | Uses container runtime |
| More resource usage | Efficient |
VMs virtualize hardware.
Docker virtualizes the operating system.
This is why containers are faster and lighter.
📦 Docker Image vs Docker Container
This distinction is fundamental.
Docker Image
Blueprint or template
Read-only
Built from Dockerfile
Used to create containers
Docker Container
Running instance of an image
Executable
Has state during runtime
Can be started, stopped, removed
Image = Blueprint
Container = Running instance
🔌 Container Port vs Host Port (Port Binding)
When an app runs inside a container, it exposes a container port.
To access it from your local machine, you bind it to a host port.
Example:
docker run -p 8080:3000 my-app
3000 → container port
8080 → host port
Now:localhost:8080 maps to the container’s port 3000.
This concept is critical for real-world deployments.
🛠️ Basic Docker Commands I Revised
Pull an image:
docker pull nginx
List images:
docker images
Run a container:
docker run nginx
Run with port mapping:
docker run -p 8080:80 nginx
List running containers:
docker ps
List all containers:
docker ps -a
Stop a container:
docker stop <container_id>
Remove a container:
docker rm <container_id>
🧠 Key Takeaways from Week 0
Docker is not just about running containers — it standardizes environments.
Containers are lightweight because they share the host kernel.
Understanding image vs container is foundational.
Port binding is essential for exposing applications.
Kubernetes will make more sense only if Docker fundamentals are strong.
