Target Duration: 60–90 seconds (~180–220 spoken words)
Goal: Deliver a clear, plain-English overview of why the project was built, its full scope, and key mental models learned, avoiding low-level implementation minutiae while dropping strategic follow-up hooks for the interviewer.
"Conductor is a lightweight, Docker-like container tool that I built from scratch using core Linux features instead of Docker. The main goal was to understand how containers actually work under the hood—process isolation, resource control, layered images, and networking.
The project has three main parts:
First is process isolation and resource control. I used Linux namespaces to isolate things like processes, networking, and the filesystem. One important detail I learned was that a new PID namespace only affects child processes, so I had to fork a child process that becomes PID 1 inside the container. I also used cgroups v2 to control CPU resources, for example limiting a container to 50% of a CPU core.
Second is layered images and build caching. I implemented a simple image builder supporting commands like FROM, RUN, and COPY. I used OverlayFS to create filesystem layers and content hashes to cache build steps, so unchanged steps don't need to be rebuilt. One interesting challenge was handling RUN differently from COPY. Since RUN can modify the filesystem—for example, installing packages—I executed it inside a temporary isolated container and captured the filesystem changes as a new layer.
Third is container networking. I connected containers to the host using veth pairs and configured iptables for internet access and port forwarding. To test the complete setup, I built a two-container microservice where a Python Flask frontend communicates with a C-based counter service over the containers' private network.
Overall, the project helped me understand what Docker is doing underneath the abstraction, particularly namespaces, cgroups, OverlayFS, and Linux networking."
| What You Mentioned | Why It Was Done (The Motivation) | Problems Faced & How Solved (The Reality) | Target Deep-Dive Document |
|---|---|---|---|
| "PID namespace & child fork as PID 1" | Isolate process trees so container applications have an independent PID space. | unshare(CLONE_NEWPID) only affects subsequent child processes via fork(). Solved by forking a child to become PID 1 and mounting private /proc. |
Topic 01: Namespaces & Syscalls |
| "cgroups v2 CPU bandwidth limiting" | Prevent rogue container processes from starving the host CPU. | Integrated cpu.max in cgroups v2. Wrote the PID to cgroup.procs before execution to eliminate unthrottled execution windows. |
Topic 02: cgroups v2 Throttling |
| "OverlayFS layered images & build caching" | Eliminate duplicate root filesystem storage and avoid re-executing identical build instructions. | Chained SHA-256 hashes transitively across layers. Executed RUN inside temporary namespace sandboxes and diffed the upperdir. |
Topic 03: OverlayFS & Layers |
| "veth pairs & iptables port forwarding" | Bridge isolated container network namespaces to the host and external network. | Created virtual Ethernet pairs, configured private subnet routing, and established Netfilter DNAT and MASQUERADE rules. | Topic 05: veth & Topic 06: iptables |
| "Two-container microservice (Flask + C)" | Validate end-to-end multi-container communication under production-like constraints. | Routed external user traffic through host DNAT to Flask frontend, which queried C counter backend over internal container network. | Topic 04: Container Lifecycle |