Build-From-Scratch

In Part 1, you isolated processes with Linux namespaces. In Part 2, you added filesystem isolation with pivot_root and OverlayFS. Now it is time to finish the container runtime. In this final part, you will: Add cgroups to limit memory and CPU Set up virtual ethernet pairs for container networking Build a CLI with Cobra Run the final container and compare it with Docker Cgroups: Resource Limits Namespaces control what a process can see. Cgroups control what a process can use. Without cgroups, a container could use all the memory on the host and crash everything. ...

In Part 1, you built a process with isolated namespaces. It has its own hostname, its own process tree, and its own network stack. But it still shares the host’s filesystem. That is dangerous. The containerized process can read /etc/shadow, write to /usr/bin, or delete anything on the host. We need to give the container its own filesystem. In this part, you will: Understand chroot and pivot_root Download and set up a minimal root filesystem Implement pivot_root in Go Add OverlayFS for layered filesystems (just like Docker images) Mount /proc inside the isolated filesystem Preparing a Root Filesystem A container needs a root filesystem — a directory that contains everything a Linux system needs: /bin, /lib, /etc, /proc, and so on. ...

Containers are not virtual machines. They are just Linux processes with extra isolation. In this series, you will build a mini Docker from scratch in Go. No frameworks. No libraries. Just Go and Linux system calls. By the end of this three-part series, you will have a working container runtime that can: Isolate processes with Linux namespaces Create a separate filesystem with OverlayFS Limit resources with cgroups Set up networking with virtual ethernet pairs Run commands through a CLI In this first part, you will learn what containers really are and how to isolate processes using Linux namespaces. ...

In Part 1, we built a TCP server with SET, GET, and DEL. In Part 2, we added expiry, persistence, and pub/sub. Now we add more data types, benchmark our implementation, and make it production-ready. In this final part, we add: INCR — atomic integer increment LPUSH, LPOP, LRANGE — list operations Benchmarks against real Redis Graceful shutdown with signal handling Better error handling throughout Adding INCR INCR atomically increments a number stored at a key. If the key does not exist, it starts at 0. If the value is not a number, it returns an error. This is how real Redis counters work. ...

In Part 1, we built a TCP server that speaks the Redis protocol. We implemented SET, GET, and DEL commands with in-memory storage. But real Redis has many more features. In this part, we add three important features: Key expiry — keys that delete themselves after a timeout Persistence — saving data to disk so it survives restarts Pub/Sub — publish and subscribe messaging between clients Key Expiry In real Redis, you can set a key with an expiration time. After that time, the key disappears. This is useful for caches, sessions, and rate limiting. ...

Have you ever wondered how Redis works under the hood? In this mini-series, we build a Redis clone from scratch in Rust. No magic. Just a TCP server, a protocol parser, and a HashMap. By the end of this series, you will have a working key-value store that speaks the real Redis protocol. You can connect to it with redis-cli and run commands. This is Part 1. We will build: ...