Docker

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. ...

After a full-stack blog, a weather dashboard, a desktop app, and a mobile app, we close Part 2 with something different: a backend microservice in Go. Go is interesting for vibe coding because the language is simple and opinionated. There is usually one way to do things. Claude should have an easier time generating idiomatic Go than, say, idiomatic Rust. Let us find out. Total time: 2 hours 14 minutes. 6 prompts. Go’s simplicity made this the fastest Part 2 project. ...

This is the complete Docker reference for 2026. All essential commands in one place. Versions covered: Docker Engine 29+, Docker Compose v2 (Compose Specification v5). Container Commands # Run a container docker run nginx # Run in detached mode (background) docker run -d nginx # Run interactively with a shell docker run -it ubuntu:24.04 bash # Run and remove when stopped docker run --rm nginx # Run with a name docker run --name mywebserver nginx # Run with port mapping (host:container) docker run -p 8080:80 nginx # Run with environment variables docker run -e APP_ENV=production myapp:1.0 # Run with environment file docker run --env-file .env myapp:1.0 # Run with volume docker run -v mydata:/data nginx # Run with bind mount docker run -v /host/path:/container/path nginx # Run with resource limits docker run --memory 512m --cpus 1.0 myapp:1.0 # Run as non-root user docker run --user 1001:1001 myapp:1.0 # Run with read-only filesystem docker run --read-only myapp:1.0 # Run with network docker run --network mynetwork myapp:1.0 # Run with restart policy docker run --restart unless-stopped nginx # List running containers docker ps # List all containers (including stopped) docker ps -a # Stop a container (SIGTERM) docker stop mywebserver # Kill a container (SIGKILL) docker kill mywebserver # Start a stopped container docker start mywebserver # Restart a container docker restart mywebserver # Remove a stopped container docker rm mywebserver # Force-remove a running container docker rm -f mywebserver # Remove all stopped containers docker container prune # View container logs docker logs mywebserver # Follow logs in real time docker logs -f mywebserver # Show last 50 lines docker logs --tail 50 mywebserver # Execute a command in a running container docker exec -it mywebserver bash # Copy files to/from a container docker cp mywebserver:/etc/nginx/nginx.conf ./nginx.conf docker cp ./nginx.conf mywebserver:/etc/nginx/nginx.conf # Inspect container details (JSON) docker inspect mywebserver # View real-time resource usage docker stats # View stats for one container docker stats mywebserver # View running processes inside a container docker top mywebserver Image Commands # Pull an image from Docker Hub docker pull nginx # Pull specific version docker pull nginx:1.27 # List local images docker images # Build an image from Dockerfile docker build -t myapp:1.0 . # Build from specific Dockerfile docker build -f Dockerfile.prod -t myapp:prod . # Build with build args docker build --build-arg APP_VERSION=2.0 -t myapp:2.0 . # Tag an image docker tag myapp:1.0 myapp:latest docker tag myapp:1.0 kemalcodes/myapp:1.0 # Push to Docker Hub docker push kemalcodes/myapp:1.0 # Remove an image docker rmi nginx # Remove all unused images docker image prune # Remove all unused images (including tagged but not referenced) docker image prune -a # View image history (layers) docker history nginx # Inspect image details (JSON) docker inspect nginx # Save image to tar file docker save myapp:1.0 -o myapp.tar # Load image from tar file docker load -i myapp.tar Volume Commands # Create a named volume docker volume create mydata # List all volumes docker volume ls # Inspect a volume docker volume inspect mydata # Remove a volume docker volume rm mydata # Remove all unused volumes docker volume prune Network Commands # List all networks docker network ls # Create a network docker network create mynetwork # Create with specific driver docker network create --driver bridge mynetwork # Inspect a network docker network inspect mynetwork # Connect a container to a network docker network connect mynetwork mycontainer # Disconnect a container from a network docker network disconnect mynetwork mycontainer # Remove a network docker network rm mynetwork # Remove all unused networks docker network prune Docker Compose Commands Always use docker compose (v2 plugin), not docker-compose (v1, deprecated). ...

Most beginner Docker setups have serious security problems. Containers running as root. Passwords in Dockerfiles. Outdated base images with known vulnerabilities. No resource limits. This tutorial covers the most important Docker security practices. You do not need to implement all of them at once. Start with the first three — they will fix the most critical issues. 1. Never Run Containers as Root By default, processes inside Docker containers run as root (UID 0). If an attacker exploits a vulnerability in your app, they have root access inside the container — and potentially a path to the host. ...

“Works on my machine” is a classic developer problem. One developer runs Python 3.11, another runs 3.13. One uses PostgreSQL 15, another uses 16. The app behaves differently on every machine. Docker solves this. With Docker, your entire development environment — app, database, cache, message queue — is defined in a YAML file. Every developer on your team runs identical environments with one command. Why Use Docker for Development? Consistent environments — everyone runs the same versions of everything No installation required — no need to install PostgreSQL, Redis, or Node locally Easy onboarding — new team members run docker compose up and have everything Clean isolation — each project has its own versions, no conflicts between projects Production parity — dev environment matches production as closely as possible The Development Compose Pattern A common pattern is to have two Compose files: ...

A common mistake is shipping your entire build environment — compilers, package managers, SDKs — in your production Docker image. A Go application needs the Go compiler to build. But once it is built, the binary runs without Go installed at all. Why include 1 GB of Go tooling in an image that only needs a 10 MB binary? Multi-stage builds solve this. They let you compile your app in one container and copy only the final artifact into a minimal production image. ...

Containers are ephemeral. When a container stops, all data written inside it disappears. That is fine for stateless apps, but databases and file storage need to persist data. Docker solves this with volumes. And Docker solves container communication with networks. In this tutorial, you will learn both. The Ephemeral Container Problem When you run a PostgreSQL container and insert some rows, that data lives in the container’s writable layer. Stop the container, remove it, and start a new one — the data is gone. ...

Most real applications are not just one container. A typical web app has: A web server (nginx) An API server (your app) A database (PostgreSQL) A cache (Redis) Running four separate docker run commands, connecting them manually, and managing their configuration is painful. Docker Compose solves this. What is Docker Compose? Docker Compose lets you define your entire application stack in a single YAML file. Then you start everything with one command: ...