How Containers Differ from VMs

A virtual machine runs a full guest operating system on top of a hypervisor. Each VM has its own kernel, its own memory allocation, and its own virtual hardware — which is why VMs take minutes to boot and consume gigabytes of RAM even before your application starts. Containers take a different approach: they share the host OS kernel and use Linux kernel features (namespaces for isolation, cgroups for resource limits) to create isolated process environments. A container starts in seconds and consumes only the memory your application actually needs.

The isolation a container provides is less complete than a VM’s — a kernel vulnerability could theoretically allow container escape. But for most workloads, the trade-off is worth it. The operational benefits — fast startup, small image sizes, easy replication, portable images that run the same everywhere — have made containers the dominant packaging format for modern applications. From a sysadmin perspective, think of containers as very lightweight, portable, and reproducible application packages.

The Dockerfile: Your Repeatable Build

A Dockerfile is a script that defines how to build a container image. It starts from a base image (typically an official image from Docker Hub — things like ubuntu:22.04, python:3.12-slim, or nginx:alpine), then layers on commands that install dependencies, copy application code, set environment variables, and configure the entry point. Each command in a Dockerfile creates a new layer in the image, and Docker caches these layers — only layers that change need to be rebuilt.

Image hygiene matters for security. Use minimal base images (Alpine or distroless images where possible), avoid running processes as root inside the container, use multi-stage builds to keep build tooling out of production images, and regularly rebuild images to pick up upstream security patches. A multi-stage Dockerfile compiles code in one stage and copies only the compiled artifact into a slim final stage, keeping the production image lean and attack-surface-minimal.

# Multi-stage Dockerfile for a Go application
# Stage 1: build
FROM golang:1.22-alpine AS builder
WORKDIR /app
COPY go.mod go.sum ./
RUN go mod download
COPY . .
RUN CGO_ENABLED=0 GOOS=linux go build -o /bin/server ./cmd/server

# Stage 2: minimal runtime image
FROM gcr.io/distroless/static:nonroot
COPY --from=builder /bin/server /server
USER 65532:65532
EXPOSE 8080
ENTRYPOINT ["/server"]

Docker Compose for Multi-Container Apps

Real applications rarely consist of a single container. A typical web stack might include an application container, a database, a cache (Redis), and a reverse proxy. Docker Compose lets you define and manage all of these as a single unit with a YAML file. With one command (docker compose up -d), Compose creates all containers, the networks between them, and any required volumes. It’s ideal for local development environments and small-scale production deployments.

Compose handles service dependencies (start the database before the app), environment variable injection, log aggregation, and scaling (spin up multiple app replicas behind a load balancer). For local development, Compose can bind-mount your source code directory into the container, so code changes are reflected immediately without rebuilding the image. This eliminates the “works on my machine” problem — everyone on the team uses the exact same environment defined in the Compose file.

# docker-compose.yml — Web app with PostgreSQL and Redis
services:
  app:
    build: .
    ports:
      - "8080:8080"
    environment:
      DATABASE_URL: postgres://appuser:secret@db:5432/appdb
      REDIS_URL: redis://cache:6379
    depends_on:
      db:
        condition: service_healthy
    restart: unless-stopped

  db:
    image: postgres:16-alpine
    environment:
      POSTGRES_USER: appuser
      POSTGRES_PASSWORD: secret
      POSTGRES_DB: appdb
    volumes:
      - pgdata:/var/lib/postgresql/data
    healthcheck:
      test: ["CMD-SHELL", "pg_isready -U appuser -d appdb"]
      interval: 10s
      timeout: 5s
      retries: 5

  cache:
    image: redis:7-alpine
    volumes:
      - redisdata:/data

volumes:
  pgdata:
  redisdata:

Data Persistence with Volumes

Containers are ephemeral by default — when a container is removed, any data written inside it is lost. For stateful applications like databases, you need Docker volumes. Named volumes are managed by Docker and stored in a Docker-managed directory on the host. They survive container removal, can be backed up, and can be shared between containers. Named volumes are the recommended approach for production data.

Bind mounts map a specific path on the host filesystem directly into the container. They’re extremely useful during development (mount your source code in, see changes immediately) but less ideal for production because they create tight coupling between the container and the host filesystem layout. For production databases and stateful services, always use named volumes. For secrets and configuration, consider Docker secrets or environment variable injection rather than bind-mounting sensitive files from the host.

The post Docker for SysAdmins: Containers Without the Complexity appeared first on InfoTech Ninja.