Docker vs Virtual Machine: Key Differences, Performance & When to Use Each

#!/bin/bash
# Inspect the architecture differences between VMs and containers

# ── Container: check kernel sharing ──────────────────────────────────────────
# Run two containers and compare their kernel versions
docker run --rm alpine:3.19 uname -r
# Output: 6.1.0-18-amd64 (host kernel version)

docker run --rm ubuntu:22.04 uname -r
# Output: 6.1.0-18-amd64 (SAME kernel — they share the host kernel)

# Check namespaces for a running container
CONTAINER_PID=$(docker inspect --format '{{.State.Pid}}' <container-name>)
ls -la /proc/$CONTAINER_PID/ns/
# Output shows: ipc, mnt, net, pid, user, uts — each is an isolated namespace

# Check cgroup resource limits
cat /sys/fs/cgroup/cpu/docker/<container-id>/cpu.shares
# Default: 1024 (1 CPU share). Adjust with --cpus flag.

cat /sys/fs/cgroup/memory/docker/<container-id>/memory.limit_in_bytes
# Shows the memory limit set by --memory flag

# ── VM: check hardware virtualization ────────────────────────────────────────
# Check if the host supports hardware virtualization
egrep -c '(vmx|svm)' /proc/cpuinfo
# Output > 0 means hardware virtualization is supported

# Check loaded hypervisor modules
lsmod | grep -E 'kvm|vbox|vmw'
# kvm_intel or kvm_amd = KVM is loaded
# vboxdrv = VirtualBox is loaded

# Check VM disk driver (inside a VM)
lsblk -o NAME,TYPE,TRAN,MODEL
# virtio = paravirtualized driver (fast)
# ide/scsi = emulated driver (slow)

# ── Compare startup time ─────────────────────────────────────────────────────
# Container startup
time docker run --rm alpine:3.19 echo 'container started'
# Typical: 0.3-0.5 seconds

# VM startup (using a minimal cloud image)
time virsh start my-vm && while ! virsh dominfo my-vm | grep -q 'running'; do sleep 1; done
# Typical: 15-60 seconds depending on OS and cloud-init

#!/bin/bash
# Benchmark container vs VM performance across CPU, memory, I/O, and network

# ── CPU Benchmark ────────────────────────────────────────────────────────────
# Container: CPU performance (sysbench)
docker run --rm severalnines/sysbench sysbench cpu --cpu-max-prime=20000 run
# Look for 'events per second' — higher is better

# VM: CPU performance (run inside VM)
apt install -y sysbench
sysbench cpu --cpu-max-prime=20000 run
# Compare 'events per second' with container result

# ── Memory Benchmark ────────────────────────────────────────────────────────
# Container: memory throughput
docker run --rm severalnines/sysbench sysbench memory --memory-block-size=1M --memory-total-size=10G run
# Look for 'transferred' throughput in MiB/sec

# VM: memory throughput (run inside VM)
sysbench memory --memory-block-size=1M --memory-total-size=10G run

# ── Disk I/O Benchmark ──────────────────────────────────────────────────────
# Container: disk I/O with fio
docker run --rm -v $(pwd)/fio-test:/test loicmahieu/alpine-fio \
  fio --name=randread --ioengine=libaio --rw=randread --bs=4k \
  --numjobs=4 --size=256M --runtime=10 --time_based --filename=/test/file
# Look for 'IOPS' and 'lat avg' — IOPS higher and latency lower is better

# VM: disk I/O (run inside VM)
fio --name=randread --ioengine=libaio --rw=randread --bs=4k \
  --numjobs=4 --size=256M --runtime=10 --time_based --filename=/tmp/fio-test/file

# ── Network Benchmark ────────────────────────────────────────────────────────
# Container: network throughput with iperf3
# Server:
docker run -d --name iperf-server -p 5201:5201 networkstatic/iperf3 -s
# Client:
docker run --rm networkstatic/iperf3 -c <host-ip> -t 10
# Look for 'sender' bandwidth in Gbits/sec

# VM: network throughput (run inside VM)
iperf3 -c <host-ip> -t 10

# ── Startup Time Benchmark ───────────────────────────────────────────────────
# Container: measure cold start
time docker run --rm alpine:3.19 echo 'started'
# Typical: 0.3-0.5s

# Container: measure warm start (image already pulled)
time docker run --rm alpine:3.19 echo 'started'
# Typical: 0.1-0.2s

# VM: measure boot time (run on hypervisor)
time virsh start test-vm && sleep 1 && while ! virsh dominfo test-vm | grep -q running; do sleep 0.5; done
# Typical: 15-60s

#!/bin/bash
# Security isolation inspection and hardening

# ── Check container security features ────────────────────────────────────────

# Check seccomp profile (syscall filtering)
docker inspect <container> --format '{{.HostConfig.SecurityOpt}}'
# Output: [seccomp=/path/to/profile.json] or [seccomp=unconfined]
# Default profile blocks ~44 dangerous syscalls out of ~300+

# Check if container is running as root
docker exec <container> id
# uid=0(root) = running as root (bad in production)
# uid=1000(appuser) = running as non-root (good)

# Check capabilities (fine-grained privilege control)
docker inspect <container> --format '{{.HostConfig.CapAdd}} {{.HostConfig.CapDrop}}'
# CapDrop: [ALL] CapAdd: [NET_BIND_SERVICE] = minimal privileges

# Check AppArmor profile
docker inspect <container> --format '{{.AppArmorProfile}}'
# docker-default = AppArmor is active (good)
# unconfined = no AppArmor (bad in production)

# ── Check if running on gVisor (user-space kernel) ───────────────────────────
docker info | grep -i runtime
# runsc = gVisor runtime (enhanced isolation)
# runc = standard runtime (standard isolation)

# Run a container with gVisor
docker run --runtime=runsc --rm alpine:3.19 dmesg | head -5
# gVisor intercepts syscalls — dmesg output differs from standard Linux

# ── Check VM isolation (inside a VM) ─────────────────────────────────────────
# Each VM has its own kernel — verify with different kernel versions
docker run --rm alpine:3.19 uname -r  # Shows host kernel
# Inside VM: uname -r  # Shows guest kernel (can be different)

# Check if the hypervisor exposes hardware virtualization
egrep -c '(vmx|svm)' /proc/cpuinfo
# > 0 = hardware virtualization available

# ── Kernel CVE check (critical for container hosts) ──────────────────────────
# Check kernel version
uname -r

# Cross-reference with known CVEs
# Example: Dirty Pipe affects kernels 5.8 through 5.16.10
# If uname -r shows 5.10.0-amd64, the host is vulnerable
# Fix: apt update && apt upgrade linux-image-$(uname -r)

#!/bin/bash
# Operational comparison: scaling, density, patching, and debugging

# ── Scaling: container vs VM auto-scaling ─────────────────────────────────────

# Container: scale from 1 to 10 replicas in seconds
docker compose up -d --scale api=10
# All 10 containers are ready in 2-5 seconds

# VM: scale from 1 to 10 instances (AWS example)
aws autoscaling set-desired-capacity \
  --auto-scaling-group-name my-asg \
  --desired-capacity 10
# New VMs take 2-5 minutes to boot, run cloud-init, and become healthy

# ── Density: compare resource usage ──────────────────────────────────────────

# Container: check resource usage per container
docker stats --no-stream --format '{{.Name}}: {{.MemUsage}}'
# Typical output:
# api-1: 85MiB / 15.55GiB
# api-2: 92MiB / 15.55GiB
# postgres: 120MiB / 15.55GiB
# Total: ~300MB for 3 containers

# VM: check resource usage per VM (inside each VM)
free -h
# Typical output:
# total: 3.8GiB  used: 1.2GiB  (OS overhead alone)
# Total: 1.2GB per VM just for the OS, before the application starts

# ── Patching: container rebuild vs VM patching ───────────────────────────────

# Container: rebuild with updated base image
docker build --no-cache -t my-app:patched .
docker push my-app:patched
# Entire patch process: 2-5 minutes, fully automated, reproducible

# VM: patch guest OS (run inside VM)
apt update && apt upgrade -y
# Or rebuild golden image with packer/ansible
# Entire patch process: 10-30 minutes per VM, or hours for golden image rebuild

# ── Debugging: container vs VM ───────────────────────────────────────────────

# Container: exec into running container
docker exec -it <container> sh
# Limited tools — production containers often have no shell

# Container: use a debug sidecar
docker run --rm -it --pid=container:<target> --net=container:<target> \
  nicolaka/netshoot bash
# Full debugging toolkit without modifying the production container

# VM: SSH into running VM
ssh user@vm-ip
# Full OS environment — install any debugging tool

# ── Networking: container vs VM ──────────────────────────────────────────────

# Container: inspect network configuration
docker network ls
docker network inspect bridge
# Shows: subnet, gateway, connected containers, driver

# VM: inspect network configuration (inside VM)
ip addr show
ip route show
# Standard Linux networking — no abstraction layer

#!/bin/bash
# Configure and compare hybrid runtimes

# ── gVisor: user-space kernel ────────────────────────────────────────────────

# Install gVisor
(
  set -e
  ARCH=$(uname -m)
  URL="https://storage.googleapis.com/gvisor/releases/release/latest/${ARCH}"
  wget ${URL}/runsc ${URL}/runsc.sha512 \
    ${URL}/containerd-shim-runsc-v1 ${URL}/containerd-shim-runsc-v1.sha512
  sha512sum -c runsc.sha512 -c containerd-shim-runsc-v1.sha512
  rm -f *.sha512
  chmod a+rx runsc containerd-shim-runsc-v1
  sudo mv runsc containerd-shim-runsc-v1 /usr/local/bin
)

# Configure Docker to use gVisor
cat <<EOF | sudo tee /etc/docker/daemon.json
{
  "runtimes": {
    "runsc": {
      "path": "/usr/local/bin/runsc",
      "runtimeArgs": ["--platform=systrap"]
    }
  }
}
EOF
sudo systemctl restart docker

# Run a container with gVisor
docker run --runtime=runsc --rm alpine:3.19 uname -a
# Output shows gVisor kernel info instead of host kernel

# ── Kata Containers: lightweight VMs ────────────────────────────────────────

# Install Kata Containers (Ubuntu)
sudo apt install -y kata-runtime kata-proxy kata-shim

# Configure Docker to use Kata
cat <<EOF | sudo tee /etc/docker/daemon.json
{
  "runtimes": {
    "kata": {
      "path": "/usr/bin/kata-runtime"
    }
  }
}
EOF
sudo systemctl restart docker

# Run a container with Kata (it is actually a VM)
docker run --runtime=kata --rm alpine:3.19 dmesg | head -3
# Output shows a separate kernel — this is a VM, not a container

# ── Firecracker: microVMs for serverless ─────────────────────────────────────

# Download Firecracker
curl -LOJ https://github.com/firecracker-microvm/firecracker/releases/latest/download/firecracker-x86_64
chmod +x firecracker-x86_64
sudo mv firecracker-x86_64 /usr/local/bin/firecracker

# Create a microVM (requires kernel and rootfs)
firecracker --api-sock /tmp/firecracker.socket \
  --config-file io/thecodeforge/firecracker-config.json
# VM starts in ~125ms with 5MB overhead

# ── Compare startup times ────────────────────────────────────────────────────
echo '--- Standard container ---'
time docker run --rm alpine:3.19 echo done
# ~0.3s

echo '--- gVisor container ---'
time docker run --runtime=runsc --rm alpine:3.19 echo done
# ~0.5s (2x slower than standard, but still fast)

echo '--- Kata container (microVM) ---'
time docker run --runtime=kata --rm alpine:3.19 echo done
# ~1.5s (5x slower, but provides full kernel isolation)