Virtualization & Containers
One server has to become three machines: a VM for the odd operating system, containers for the rest. Hypervisors, images, runtimes, and where the writes go.
An interactive Linux lesson: 21 steps, about 32 minutes, on a live simulation in your browser.
Friday's staging request needs three machines and there is one server left: web01. Machine one must run a Windows-only checkout tool. Machines two and three are ordinary Linux services, a storefront and an API.
You cannot buy hardware, so you will fake the machines. That is the whole lesson: two ways of faking, and which shortage each one solves. Read the ticket first.
What you will learn
Three machines, one server
- Three machines, one server left
- Two shortages, two tools: A hypervisor fakes hardware so another kernel can boot. A container fakes a machine out of processes on the kernel you already run.
- The Windows tool decides: A container can only run binaries built for the host's kernel. A different kernel means a virtual machine.
The hypervisor: fake hardware
- A hypervisor is fake hardware: KVM plus QEMU is the machine; libvirt manages it; virsh talks to libvirt; each VM is a domain with its own kernel and memory.
- Why the odd OS needs a VM: exec understands the host kernel's binary format only. A container cannot run what the host kernel cannot exec.
- Virtual NICs and bridges: A bridge is a virtual switch and a virtual NIC is a cable end. VMs and containers both get plugged in; only the guest differs.
- Break it: a VM with no virtio drivers: Emulated hardware works everywhere and is slow. virtio drivers let the guest cooperate with the host instead of being emulated.
- Drill: list every domain
Images versus machines
- An image is a packed directory tree: An image is files plus metadata describing how to run them. A container is what happens when a runtime starts a process from those files.
- Delete a file in the container: The image is read-only at runtime. Every write a container makes lands in its own overlay layer, never in the image.
- One image, many machines: Containers share their image's layers and each adds a thin overlay. N containers from one image cost one image, not N.
Containers: one kernel
- podman run: one line, one machine: podman run -d --name NAME -p HOST:BOX IMAGE starts a detached container with a name and a published port. docker run spells it the same.
- ps, images, rmi: ps lists running machines, images lists templates, rmi deletes a template only when no container stands on it.
- No daemon to kill: The CLI and the daemon manage containers; neither is their parent. Killing management blinds you, it does not stop the workloads.
- Drill: start the shop site
- What a container does not isolate: Containers share one kernel. That sharing is their speed and their fate: native performance, and one kernel problem hits every box.
Where the writes go
- Bind mounts: your directory in the box: A bind mount shows one host directory inside the container. Writes land on the host disk at once, and they survive the container.
- Break it: logs fill the host disk: Container writes without a volume land on the host's filesystem. A chatty container can fill the host's root disk.
- Volumes: writes with their own disk: A volume is runtime-managed storage mounted into the container. Keep append-only writes in volumes, human files in bind mounts, nothing in the overlay.
Recap & playground
- Cheat sheet
- Playground