Docker

A container packages an app with its dependencies so it runs the same everywhere. It shares the host OS kernel and isolates only the process, filesystem, and network — so it’s far lighter than a VM.

“Works on my machine” disappears: the image is the environment, so dev, CI, and prod run byte-identical dependencies.

• Image — a read-only template (the blueprint). Built from a Dockerfile, tagged like myapp:1.2.
• Container — a running (or stopped) instance of an image, with a thin writable layer on top.
• Registry — where images live (Docker Hub, ECR, GHCR); push/pull moves them.

An image is a stack of layers, one per build instruction. Layers are cached and shared between images — so ordering your Dockerfile well is the main build-speed lever.

A Dockerfile is the recipe for an image. Each instruction adds a layer.

FROM node:20-alpine            # base image
WORKDIR /app
COPY package*.json ./          # copy deps manifest FIRST
RUN npm ci                     # cached unless package*.json changes
COPY . .                       # then the source
EXPOSE 3000
CMD ["node", "server.js"]      # default process

• Cache order matters: copy the dependency manifest and install before copying source, so a code change doesn’t bust the (slow) dependency layer.
• CMD vs ENTRYPOINT — CMD sets the default command (easily overridden); ENTRYPOINT sets the fixed executable, with CMD as its default args.
• Multi-stage builds — build in a heavy image, copy only the artifact into a tiny runtime image; smaller, safer final images.
• Use a .dockerignore to keep node_modules/.git out of the build context.

The everyday commands an SDET should be fluent in:

docker run -d --name web -p 8080:3000 -e NODE_ENV=test myapp:1.2
#        |    |            |             |
#   detached  name    host:container  env var

docker exec -it web sh        # shell into it
docker logs -f web            # follow the logs
docker rm -f web             # stop + remove

A container’s writable layer is ephemeral — delete the container and its data is gone. Volumes persist data outside the container lifecycle.

• Named volume — Docker-managed storage (-v mydata:/var/lib/postgresql/data); the right choice for databases.
• Bind mount — maps a host directory into the container (-v $(pwd):/app); great for live-reloading source in dev.
• tmpfs — in-memory only; fast and wiped on stop.

• bridge (default) — containers on the same user-defined bridge network reach each other by name (built-in DNS).
• host — share the host’s network stack (no port mapping, less isolation).
• none — no networking.

Inside a Compose network a service connects to another by its service name as the hostname — e.g. the app reaches the DB at postgres:5432, not localhost.

Compose defines a multi-container app in one YAML file and brings it all up with a single command — perfect for a test stack (app + DB + mock server).

services:
  app:
    build: .
    ports: ["8080:3000"]
    environment:
      DB_URL: postgres://db:5432/test
    depends_on: [db]
  db:
    image: postgres:16
    environment:
      POSTGRES_DB: test
    tmpfs: ["/var/lib/postgresql/data"]   # ephemeral test DB

• docker compose up -d / down — start / tear down the whole stack.
• depends_on controls start order (not readiness — add a healthcheck for that).
• One network is created automatically, so services resolve each other by name.

This is where containers earn their keep for an SDET — disposable, identical environments on every run.

• Ephemeral dependencies — spin up a real Postgres/Redis/Kafka in a container for integration tests instead of mocking, then throw it away.
• Testcontainers — a library (Java/.NET/Python/Node) that starts containers from your test code and tears them down after, with dynamic ports — no leftover state.
• Selenium/Playwright in Docker — official browser images and Selenium Grid containers give consistent, headless browsers in CI.
• CI — GitHub Actions / GitLab run jobs inside containers (services: / container:), so the build environment is version-pinned and reproducible.

// Testcontainers (Java) — a throwaway Postgres for one test class
@Container
static PostgreSQLContainer<?> db =
    new PostgreSQLContainer<>("postgres:16");
// db.getJdbcUrl() gives a dynamic URL; container is removed after tests