Video summary

Stop Debugging Docker Containers the Hard Way

Main summary

Key takeaways

Technology

Summary: Hidden/Lesser-Known Docker Commands and Tooling

The video argues that repeatedly restarting individual containers or manually troubleshooting Docker Compose stacks is inefficient. Instead, it introduces seven “hidden”/lesser-known Docker commands to initialize, copy, inspect changes, debug, and analyze container behavior more systematically.

1) docker init — initialize a container project (wizard/boilerplate)

What it does

  • Creates a new project directory with expected files:
    • Dockerfile
    • .dockerignore
    • Compose file
    • README
  • Includes a wizard to choose:
    • language, version, path, port, etc.
  • Example includes detection/alerts when something like Go modules isn’t present.

Dockerfile best practices (as mentioned)

  • Mentions generated Dockerfile patterns such as:
    • multi-stage builds
    • safer runtime execution (e.g., creating a Linux user)

Caution

  • Templates don’t know full context, so the video encourages:
    • read the generated code before using it.
  • References a related “Dockerfile mistakes” video.
  • Notes preference for distroless over Alpine, with the tradeoff discussed as:
    • safety/size vs. build/run time and flexibility.

2) .dockerignore guidance — reduce unwanted “bake-in”

  • Emphasizes using a well-crafted ignore file rather than manually excluding files one-by-one.
  • Notes that the scaffolding from docker init includes boilerplate to support this ignore behavior.

3) docker cp — copy files between containers/images/storage states

  • Demonstrates copying files into and out of containers, and between containers.
  • Key insight:
    • even if a container is stopped, it can be used as a source/target for copy operations.
  • Example described:
    • copying from a stopped Alpine container to another container using a JSON file.

4) docker diff (alias: docker container diff) — verify filesystem changes

  • Shows what changed on a container’s filesystem:
    • C = changed
    • A = added (e.g., a newly created JSON file)
  • Useful for verifying whether changes happened after operations like:
    • SCP/copy
    • mount sharing
  • Positioned as a smarter alternative to guesswork.

5) docker events — event-based debugging

  • Runs similarly to “Kubernetes events”, with a follow mode.
  • Can restart a container and immediately observe events with:
    • unique IDs, timestamps, image info, etc.
  • Supports filtering by:
    • event type
    • file name
    • output format
  • Example output format mentioned:
    • unix time + action + name.

6) docker update — resource management nuance

  • Like docker top for visibility, but then applies changes using:
    • docker update
  • Important constraint stated:
    • you generally cannot increase memory limit without killing the container
    • updated memory must generally be ≤ the already set limit

7) docker system df — storage usage (images, containers, volumes)

  • Focuses on disk usage (not CPU/memory).
  • Displays space usage for:
    • images
    • containers
    • local volumes

Additional “alpha/hidden” Docker Compose capability: docker compose alpha

The video mentions experimental options under docker compose alpha.

Highlighted features

  • Generate a Compose file from existing containers (reverse direction of the usual workflow).
  • “Analyze” and output Compose implementation details.
  • Publish applications as an OCI artifact and push to a Docker-compatible registry.
  • Another person can run the published stack via Compose using a remote OCI file, enabling:
    • shared reproducible stacks without manual copy/paste instructions.

Build analysis tooling: Buildx tracing + web UI (buildx trace)

Recap: Buildx

  • Describes Buildx as an extended suite (BuildKit-based).

Build tracing workflow

  • Use:
    • buildx history ls to view recent build runs and success/failure
    • buildx history trace to open a local web UI for detailed analysis

What the UI provides

  • Per-operation timing (down to milliseconds)
  • Visual bar charts and filtering
  • Ability to inspect slowness
  • Optional views such as flame graphs
  • A downstream “map” of build node actions

Basis mentioned

  • The tracing is stated as being based on the project Jagger.

Sponsorship (workflow automation, not Docker)

  • Sponsor: Momentic — an AI-native end-to-end testing platform
  • Claims mentioned:
    • write tests in plain English (to reduce flaky scripts)
    • automatically adapt tests as the UI changes
    • recover from failures
    • integrate with AI-first workflows via MCP, CI, and verification of shipped code

Main speakers / sources

  • Primary speaker: The video narrator/author (Docker-focused presenter)
  • Tools / sources referenced:
    • Docker (official CLI/commands/templates)
    • Jagger (build tracing basis)
    • Momentic (sponsor)

Original video