Docker Interview Questions

Docker is an open-source platform that automates the deployment, scaling, and management of applications using containerization. It packages an application and its dependencies into a lightweight, portable container that runs consistently across any environment (development, staging, production).

Docker was released in 2013 by DotCloud (now Docker Inc.) and popularized container technology, making it accessible to developers worldwide.

docker --version
# Docker version 24.0.7, build afdd53b

Think of an image as a blueprint/class and a container as an object/instance. You can create many containers from one image.

Containers are not virtual machines — they are isolated processes running on the same host kernel.

VM:        [App] [Guest OS] → [Hypervisor] → [Host OS] → [Hardware]
Container: [App] → [Container Runtime] → [Host OS Kernel] → [Hardware]

A Dockerfile is a text file containing a series of instructions to build a Docker image. Each instruction creates a layer in the image.

FROM node:18-alpine          # Base image
WORKDIR /app                  # Working directory
COPY package*.json ./         # Copy dependency files
RUN npm install               # Install dependencies
COPY . .                      # Copy source code
EXPOSE 3000                   # Declare port
CMD ["node", "app.js"]        # Default command

Common instructions: FROM, RUN, COPY, ADD, CMD, ENTRYPOINT, ENV, EXPOSE, WORKDIR, USER, VOLUME

This command:

• docker run — Create and start a new container
• -d — Run in detached mode (background)
• -p 8080:80 — Map host port 8080 to container port 80
• nginx — Use the nginx image (pulled from Docker Hub if not local)

Breaking down -p 8080:80:

• Host port (left side): What you type in your browser (localhost:8080)
• Container port (right side): What the application inside the container listens on

docker run -d -p 8080:80 nginx
# Access at http://localhost:8080

Docker Hub is the official public container registry where Docker images are stored, shared, and distributed. It’s similar to GitHub for code, but for container images.

# Pull a public image
docker pull nginx:latest

# Push your own image (requires Docker Hub account)
docker push myusername/myapp:latest

# Search for images
docker search nginx

Docker Hub features:

• Official images — Maintained by Docker and software vendors (nginx, node, python, postgres)
• Public/private repos — Free public repos, paid private repos
• Automated builds — Build images from GitHub/Bitbucket
• Webhooks — Trigger actions when images are pushed

Alternatives: GitHub Container Registry (ghcr.io), AWS ECR, Google Container Registry, Harbor (self-hosted)

# List running containers
docker ps

# List all containers (including stopped)
docker ps -a

# List only container IDs (useful for scripting)
docker ps -q

# List with custom format
docker ps --format "table {{.Names}}\t{{.Status}}\t{{.Ports}}"

# List last N containers (running and stopped)
docker ps -n 5

docker ps output columns:

• CONTAINER ID — Short ID (use full ID with docker inspect)
• IMAGE — The image used
• COMMAND — The command running inside
• CREATED — When it was created
• STATUS — Running, Exited, Up X minutes
• PORTS — Port mappings
• NAMES — Container name (auto-generated or assigned with --name)

# Stop a running container (graceful: SIGTERM + 10s timeout)
docker stop container_name

# Force stop (immediate: SIGKILL)
docker kill container_name

# Remove a stopped container
docker rm container_name

# Stop and remove in one command
docker rm -f container_name

# Remove all stopped containers
docker container prune

# Remove all containers (including running with -f)
docker rm -f $(docker ps -aq)

When a container is removed, all changes in its writable layer are lost (unless saved to a volume). Use docker stop instead of docker kill for graceful shutdowns.

docker pull image:tag downloads a Docker image from a registry without running it:

# Pull latest tag
docker pull nginx

# Pull specific version
docker pull node:18-alpine

# Pull from a specific registry
docker pull ghcr.io/myorg/myapp:latest

# Pull all tags (not recommended)
docker pull -a myimage

If no tag is specified, :latest is used by default. Always specify a specific version tag for reproducible builds.

docker run automatically pulls the image if it’s not found locally (equivalent to docker pull + docker run).

A Docker Image is a lightweight, standalone, executable package that includes everything needed to run an application: code, runtime, system tools, libraries, and settings.

# Build an image from a Dockerfile in the current directory
docker build -t myapp:1.0 .

# Tag an existing image
docker tag myapp:1.0 myapp:latest

# List images
docker images

# Remove an image
docker rmi myapp:1.0

# Remove unused images
docker image prune

Images consist of read-only layers created by each Dockerfile instruction. When you change your code, only the layers above the change need to be rebuilt (caching).

# View logs from a running container
docker logs container_name

# Follow logs in real-time (like tail -f)
docker logs -f container_name

# View last N lines
docker logs --tail 100 container_name

# View logs with timestamps
docker logs -t container_name

# View logs since a specific time
docker logs --since 2024-01-01T00:00:00 container_name

# View logs from a specific period
docker logs --since 10m --until 5m container_name

For debugging crashed containers, check logs even after the container has stopped — they persist until the container is removed.

docker inspect returns detailed JSON metadata about any Docker object (containers, images, volumes, networks):

# Inspect a container
docker inspect container_name

# Get specific field (using Go template syntax)
docker inspect -f '{{.State.Status}}' container_name

# Get IP address
docker inspect -f '{{range .NetworkSettings.Networks}}{{.IPAddress}}{{end}}' container_name

# Get mount information
docker inspect -f '{{json .Mounts}}' container_name | jq

# Inspect an image
docker inspect nginx:latest

Useful for extracting runtime information like IP addresses, port mappings, mount points, environment variables, and network settings.

Use docker exec to run commands inside a running container:

# Run a command and exit
docker exec container_name ls -la

# Open an interactive shell
docker exec -it container_name sh
# (or bash, if available)

# Set environment variables for the command
docker exec -e MY_VAR=value container_name env

# Run as a different user
docker exec -u root container_name whoami

# Run in the background
docker exec -d container_name touch /tmp/healthcheck

The -it flags are important for interactive sessions:

• -i (interactive) — Keep STDIN open
• -t (tty) — Allocate a pseudo-TTY

The default network mode is bridge network. When Docker starts, it creates:

• A virtual bridge (docker0) on the host
• A private IP subnet for containers (default: 172.17.0.0/16)

# List networks
docker network ls
# NETWORK ID  NAME    DRIVER  SCOPE
# abc123      bridge  bridge  local
# def456      host    host    local
# ghi789      none    null    local

# Inspect default bridge
docker network inspect bridge

Bridge network features:

• Containers get their own IP addresses (NATed behind the host)
• Containers can communicate with each other by IP
• Ports must be explicitly published (-p) for external access
• No automatic DNS resolution between containers (use custom bridge for that)

A Docker Volume is persistent storage that exists independently of container lifecycles. Since containers are ephemeral (data inside is lost when deleted), volumes ensure data survives container restarts and removals.

# Create a named volume
docker volume create mydata

# Mount a volume when running a container
docker run -v mydata:/app/data myapp

# Using --mount syntax (preferred for more options)
docker run --mount source=mydata,target=/app/data myapp

# List volumes
docker volume ls

# Remove unused volumes
docker volume prune

Volume types:

1. Named volumes — Docker-managed, stored in /var/lib/docker/volumes/
2. Bind mounts — Mount a host directory: docker run -v /host/path:/container/path
3. Anonymous volumes — Docker generates a random name, useful for temporary data

# CMD alone — fully overridable
CMD ["node", "app.js"]
# docker run myimage → node app.js
# docker run myimage python test.py → python test.py

# ENTRYPOINT + CMD — CMD provides default args
ENTRYPOINT ["node"]
CMD ["app.js"]
# docker run myimage → node app.js
# docker run myimage server.js → node server.js

Best practice: Use ENTRYPOINT for the main command and CMD for default arguments. This gives a clear, flexible interface.

Three ways to pass environment variables:

# 1. Directly with -e flag
docker run -e NODE_ENV=production -e DB_URL=postgres://... myapp

# 2. Using an env file
docker run --env-file .env myapp

# 3. From host environment (just the variable name)
docker run -e MY_HOST_VAR myapp

Security warning: Never put secrets (passwords, API keys, tokens) in:

• Dockerfiles (ENV instruction)
• Image layers
• Version control

Use Docker Secrets (Swarm mode), external secret managers (Vault, AWS Secrets Manager), or secret injection at runtime.

.dockerignore prevents specified files/directories from being sent to the Docker build context, improving build speed and security:

node_modules
.git
.env
*.md
dist/*.map
coverage/
.gitignore
Dockerfile
.dockerignore

Why it matters:

• Faster builds — Smaller build context means faster transfer to Docker daemon
• Smaller images — Unnecessary files aren’t included (even if in .dockerignore, they don’t become layers)
• Security — Prevents secrets (.env, .git) from being added to the image

The .dockerignore file should be in the same directory as your Dockerfile.

docker commit creates a new image from a container’s current state (including all changes made to the writable layer):

# Commit changes to a new image
docker commit container_name myapp:snapshot

# Commit with a message and author
docker commit -m "Added feature X" -a "Alice" container_name myapp:v2

When to use:

• Debugging — save a container’s state for later analysis
• Quick prototyping — but not for production builds

When NOT to use (most of the time):

• Builds are not reproducible (no Dockerfile)
• No layer caching
• Hard to version control
• Opaque — no way to understand what’s in the image

Best practice: Always use a Dockerfile for reproducible builds.

docker tag creates an alias/tag for an existing image:

# Tag an image
docker tag myapp:1.0 myapp:latest

# Tag with registry information (for pushing)
docker tag myapp:1.0 myregistry.io/alice/myapp:1.0
docker tag myapp:1.0 myregistry.io/alice/myapp:latest

# Tag is a reference, not a copy (shares the same image ID)

Tagging conventions:

• :latest — Default tag (avoid for production — ambiguous)
• :1.0, :v1.0.0 — Semantic versioning (recommended)
• :sha-abc123 — Git commit SHA (traceable)
• :production, :staging — Environment-specific
• :alpine, :slim — Base image variants

Best practice: Use specific version tags for deployments, not :latest.

Several methods:

# 1. Interactive shell
docker exec -it container_name sh
# Then navigate: ls, cat, etc.

# 2. Copy files out without entering
docker cp container_name:/app/config.json ./config.json

# 3. Export container filesystem to a tar archive
docker export container_name -o container-fs.tar

# 4. Using docker diff (shows changes since container started)
docker diff container_name
# A = added, C = changed, D = deleted

docker diff is useful for debugging:

docker diff my_container
C /app          # Directory changed
A /app/config.json  # File added

# Graceful stop (recommended)
docker stop mycontainer

# Force kill
docker kill mycontainer

# Send a custom signal
docker kill --signal SIGUSR1 mycontainer

Always prefer docker stop — it gives the application time to:

• Flush pending data to the database
• Close network connections gracefully
• Clean up temporary files
• Log a clean shutdown

docker kill should only be used when a container is not responding to docker stop.

A container goes through these states:

Created → Running → Paused
   ↓                    ↓
Stopped ← (exit) ← Unpaused

1. Created — docker create ran but container hasn’t started
2. Running — Container is executing its process
3. Paused — Processes are frozen (SIGSTOP); uses docker pause
4. Unpaused — Processes resume (SIGCONT); uses docker unpause
5. Exited — Process finished (or crashed); exit code indicates status
6. Dead — Container was forcibly removed while running

# Check current state
docker inspect -f '{{.State.Status}}' container_name
# Output: running, exited, paused, created, restarting, removing, dead

Use docker cp to copy files between the host and container:

# Copy FROM container TO host
docker cp container_name:/app/logs/app.log ./logs/

# Copy FROM host TO container
docker cp ./config.json container_name:/app/config.json

# Copy entire directories
docker cp container_name:/app/data/ ./backup-data/

# Copy with current directory (.)
docker cp container_name:/app/. ./app-backup/

Limitations:

• Container doesn’t need to be running (can copy from stopped containers)
• Doesn’t work across Docker hosts (use volumes or shared storage)
• Paths are resolved relative to the container’s filesystem, not the image

The build context is the set of files and directories sent to the Docker daemon when building an image:

# Current directory (.) is the build context
docker build -t myapp .

# Specify a different context directory
docker build -t myapp -f ./docker/Dockerfile ./app

# Context with a URL (Git repo)
docker build -t myapp https://github.com/user/repo.git#main

How it works:

1. Docker CLI tars the context directory
2. Sends it to the Docker daemon
3. The daemon extracts it, making files available to COPY and ADD instructions
4. The .dockerignore file filters out files BEFORE sending

Best practices:

• Keep context small (use .dockerignore)
• Don’t put the Dockerfile in a parent directory above your app
• CI/CD should use minimal contexts

docker system prune cleans up unused Docker resources:

# Remove all unused containers, networks, images (dangling), and build cache
docker system prune

# Remove everything, including unused images (not just dangling)
docker system prune -a

# Force without confirmation
docker system prune -af

# Filter: only prune resources older than 24h
docker system prune --filter "until=24h"

# Specific prunes:
docker container prune   # Remove stopped containers
docker image prune -a    # Remove unused images
docker volume prune      # Remove unused volumes
docker network prune     # Remove unused networks

What gets removed:

• Stopped containers
• Networks not used by at least one container
• Dangling images (untagged: <none>:<none>)
• Build cache

docker stats shows real-time resource usage of running containers:

# Show stats for all running containers
docker stats

# Show stats for specific containers
docker stats container1 container2

# Show once and exit (no streaming)
docker stats --no-stream

# Format output
docker stats --format "table {{.Name}}\t{{.CPUPerc}}\t{{.MemUsage}}"

Typical output:

CONTAINER ID   NAME      CPU %   MEM USAGE / LIMIT     MEM %
abc123         web       0.25%   45.6MiB / 1.944GiB   2.29%
def456         db        5.10%   256.8MiB / 1.944GiB  13.19%

Useful for identifying containers that are consuming too much CPU or memory.

Set CPU and memory limits to prevent containers from consuming all host resources:

# Memory limits
docker run -m 512m myapp                    # Max 512MB memory
docker run --memory-swap 1g myapp           # Max 1GB (memory + swap)

# CPU limits
docker run --cpus 1.5 myapp                 # Max 1.5 CPU cores
docker run --cpuset-cpus 0-3 myapp          # Only use CPUs 0-3
docker run --cpu-shares 512 myapp           # Relative weight (default 1024)

# Combined
docker run -d --name web --restart unless-stopped \
  -m 512m --cpus 0.5 \
  -p 8080:80 nginx

In Docker Compose:

services:
  app:
    image: myapp
    deploy:
      resources:
        limits:
          cpus: '0.5'
          memory: 512M

Always set resource limits in production to prevent noisy neighbors.

# docker run = docker create + docker start
docker create --name myapp nginx  # Create (but don't start)
docker start myapp                # Start the created container

# Same as one command:
docker run --name myapp nginx     # Create and start

When to use docker start:

• Restart a container that stopped (e.g., after a crash)
• Start a container you previously stopped
• The container retains its filesystem, volumes, and network configuration

When to use docker run:

• The first time you want to run an image
• You need different configuration (ports, volumes, env vars)
• You want a clean instance

Use the --restart flag to set the restart policy:

# Restart unless explicitly stopped (recommended for most services)
docker run --restart unless-stopped nginx

# Always restart, regardless of exit code
docker run --restart always nginx

# Restart on failure (max 5 times)
docker run --restart on-failure:5 nginx

# No automatic restart (default)
docker run --restart no nginx

unless-stopped is generally the best choice for production services.

EXPOSE documents which ports the container listens on — it does NOT actually publish the ports:

EXPOSE 3000
EXPOSE 8080/tcp  # Default is TCP
EXPOSE 53/udp    # UDP also supported

What EXPOSE does:

• Acts as documentation for developers
• Creates a layer of metadata on the image
• Does NOT make ports accessible from outside

What you still need to do:

# -p publishes the port (makes it accessible from host)
docker run -p 3000:3000 myapp

You can think of EXPOSE as saying “This container will listen on port 3000” — it’s a hint to the person running the container.

Dockerfile instructions can use two forms:

# Exec form (JSON array) — RECOMMENDED
ENTRYPOINT ["node", "app.js"]
CMD ["node", "app.js"]
RUN ["apt-get", "install", "-y", "curl"]

# Shell form (string)
ENTRYPOINT node app.js
CMD node app.js
RUN apt-get install -y curl

Exec form:

• No shell processing (no variable expansion)
• PID 1 is the process itself (receives signals directly)
• Preferred for CMD and ENTRYPOINT
• Signals (SIGTERM, SIGINT) are passed correctly

Shell form:

• Runs through /bin/sh -c
• Variable expansion works ($HOME)
• PID 1 is the shell, not your app
• Signals may not reach your app (the shell doesn’t forward them)

# Bad: signals won't propagate
ENTRYPOINT npm start

# Good: signals propagate correctly
ENTRYPOINT ["node", "server.js"]

# After a container exits, check its exit code
docker inspect container_name --format='{{.State.ExitCode}}'

# List containers with their exit codes
docker ps -a

# Get exit code from docker run (foreground mode)
docker run myapp
echo $?    # Prints exit code

# Exit code meanings:
# 0    → Success
# 1    → Application error
# 125  → Docker run error (command failed)
# 126  → Command cannot be invoked (permission)
# 127  → Command not found
# 137  → SIGKILL (128 + 9) — typically OOM killed
# 139  → SIGSEGV (128 + 11) — segmentation fault
# 143  → SIGTERM (128 + 15) — graceful shutdown

Exit code 137 (128 + SIGKILL=9) often indicates the container was killed for exceeding its memory limit.

The bridge network is Docker’s default network driver. It creates an isolated virtual network on the host:

# Default bridge is created automatically
docker network inspect bridge

# Create a custom bridge network (recommended!)
docker network create mynetwork

# Run containers on the custom network
docker run --network mynetwork --name web nginx
docker run --network mynetwork --name db postgres

Default bridge vs Custom bridge:

Always use a custom bridge network for automatic DNS resolution between containers.

WORKDIR sets the working directory for subsequent RUN, CMD, ENTRYPOINT, COPY, and ADD instructions:

FROM node:18-alpine
WORKDIR /app           # Creates /app if it doesn't exist
COPY package*.json .   # Copies to /app/package*.json
RUN npm install        # Runs in /app
COPY . .               # Copies source to /app
CMD ["node", "server.js"]  # Runs in /app

Why use WORKDIR:

• Creates the directory if it doesn’t exist
• Sets the directory for all subsequent instructions
• Avoids hardcoding paths
• Use multiple WORKDIR instructions to navigate between directories

WORKDIR /app
RUN mkdir data
WORKDIR /app/data
RUN touch file.txt    # Creates /app/data/file.txt

Use docker rename to rename an existing container:

# Rename a running or stopped container
docker rename old_name new_name

# Example
docker run -d nginx
docker rename elegant_moore webserver

You can only rename a container (not an image). Container names must be unique on the host.

For images, use docker tag to create additional names/tags.

Docker Compose manages multi-container applications defined in a docker-compose.yml file:

# Start all services (build, create, start)
docker compose up

# Start in detached mode (background)
docker compose up -d

# Stop and remove all containers, networks
docker compose down

# Remove volumes too (will delete data!)
docker compose down -v

# Rebuild images and start
docker compose up --build

# View logs
docker compose logs -f

# List services
docker compose ps

A simple docker-compose.yml:

services:
  web:
    image: nginx
    ports:
      - "8080:80"
  db:
    image: postgres
    volumes:
      - pgdata:/var/lib/postgresql/data
volumes:
  pgdata:

HEALTHCHECK tells Docker how to test if a container is working properly:

HEALTHCHECK --interval=30s --timeout=3s --retries=3 \
  CMD curl -f http://localhost:3000/health || exit 1

Options:

• --interval — How often to run the check (default: 30s)
• --timeout — Maximum time for the check (default: 30s)
• --retries — Consecutive failures before marking unhealthy (default: 3)
• --start-period — Grace period before checks start (default: 0s)

Health states:

• starting — Initial state (during start-period)
• healthy — Check passed
• unhealthy — All retries failed

# View health status
docker inspect --format='{{.State.Health.Status}}' container_name

Healthchecks are critical for production — orchestration tools use them for rolling updates and automatic restarts.

Docker tags are labels for image versions. The format is image:tag:

# Format: [registry/][user/]image[:tag]

# Common tags
nginx:latest          # Most recent version (default)
nginx:1.25            # Major version
nginx:1.25.3          # Full version
node:18-alpine        # Version + variant
node:18-bullseye-slim # Version + OS + variant

Tagging conventions:

:latest     → Ambiguous (changes over time). Avoid in production.
:v1.0.0     → Semantic versioning (recommended)
:sha-abc123 → Git commit hash (traceable to source)
:production → Environment-specific

Best practice: Always pin to a specific version tag for reproducible builds. Use automation (Dependabot, Renovate) to update tags.

# Bad
FROM node:latest

# Good
FROM node:18.17.0-alpine

docker save and docker load are used to export/import images as tar archives:

# Save an image to a tar file
docker save -o myapp.tar myapp:1.0

# Compress for transfer
docker save myapp:1.0 | gzip > myapp.tar.gz

# Load an image from a tar file
docker load -i myapp.tar
docker load < myapp.tar.gz

# Transfer between hosts
docker save myapp:1.0 | ssh user@host "docker load"

Use cases:

• Transfer images between hosts without a registry
• Air-gapped environments (no internet access)
• Archiving specific image versions
• CI/CD pipelines (save → upload artifact → download → load)

Not to be confused with:

• docker export — Exports a container’s filesystem (no metadata, no layers)
• docker commit — Saves container state as an image

USER sets the username (or UID) to use when running the container:

FROM node:18-alpine

# Create a non-root user
RUN addgroup -S appgroup && adduser -S appuser -G appgroup

USER appuser
WORKDIR /app
COPY . .
CMD ["node", "server.js"]

Why use a non-root user:

• Security — If an attacker compromises the app, they don’t have root access
• Principle of least privilege — The app doesn’t need root
• Containers running as root are vulnerable to privilege escalation

Best practice: Always create and switch to a non-root user in your Dockerfile:

RUN addgroup -S mygroup && adduser -S myuser -G mygroup
USER myuser

# COPY — simple, explicit (PREFERRED)
COPY ./app /app
COPY package.json /app/package.json

# ADD — only when you need tar extraction
ADD app.tar.gz /app/     # Auto-extracts the tar.gz

Best practice: Use COPY unless you specifically need ADD’s tar extraction feature. Remote URL fetching with ADD is discouraged — use curl or wget in a RUN command instead for better caching and control.

# Bad — ADD from URL (no caching, no error handling)
ADD https://example.com/file.tar.gz /tmp/

# Good — RUN with curl (better caching, can chain commands)
RUN curl -fsSL https://example.com/file.tar.gz | tar xz -C /tmp/

A Docker Registry is a storage and distribution system for Docker images:

# Public registries
docker pull nginx                             # Docker Hub (default)
docker pull ghcr.io/myorg/myapp:latest        # GitHub Container Registry
docker pull 123456789.dkr.ecr.us-east-1.amazonaws.com/myapp  # AWS ECR

# Log in to a registry
docker login
docker login myregistry.com -u username -p password

# Push to a registry
docker tag myapp:1.0 myregistry.com/username/myapp:1.0
docker push myregistry.com/username/myapp:1.0

Popular registries:

docker image prune removes unused Docker images:

# Remove dangling images (untagged: <none>:<none>)
docker image prune

# Remove all unused images (not just dangling)
docker image prune -a

# Force without confirmation
docker image prune -af

# Filter: only images older than 24h
docker image prune --filter "until=24h"

# Labels filter
docker image prune --filter "label!=keep"

What’s removed:

• Dangling images (<none>:<none>) — images no longer tagged, usually intermediate build artifacts
• Unused images (with -a) — images not referenced by any container (running or stopped)

Run docker system df to see how much disk space is used by Docker images, containers, volumes, and build cache.

The default restart policy is no — containers do NOT restart automatically on exit.

# This is the default — no automatic restart
docker run nginx

To enable automatic restarts, use --restart:

docker run --restart unless-stopped nginx

Docker Compose also has restart:

services:
  web:
    image: nginx
    restart: unless-stopped

unless-stopped is recommended for production — it restarts the container on crashes and reboots, but not if the administrator explicitly stopped it.

Use docker inspect or docker ps to see how a container was started:

# See the full command and arguments
docker inspect -f '{{.Config.Cmd}}' container_name

# See the entrypoint
docker inspect -f '{{.Config.Entrypoint}}' container_name

# See all config
docker inspect -f '{{json .Config}}' container_name | jq

# See the original docker run command (partial)
docker ps --no-trunc

# Get full creation details
docker inspect container_name | grep -A 10 "Cmd"

For a complete “how was this container started” reconstruction, use docker inspect and look at the Config, HostConfig, and Mounts sections.

# View all logs (past)
docker logs container_name

# View last 100 lines
docker logs --tail 100 container_name

# Follow new log output
docker logs -f container_name

# Tail last 50 and follow
docker logs --tail 50 -f container_name

# With timestamps
docker logs -ft container_name

docker logs reads the container’s stdout/stderr streams, which Docker captures. It works even if the container has stopped (but not after docker rm).

Multiple ways to see port mappings:

# docker ps shows port mappings
docker ps

# docker port (specific to port mapping)
docker port container_name
# 80/tcp → 0.0.0.0:8080

# docker inspect with Go template
docker inspect -f '{{json .NetworkSettings.Ports}}' container_name
# {"80/tcp":[{"HostIp":"0.0.0.0","HostPort":"8080"}]}

# Human-readable format
docker inspect -f '{{range $p, $conf := .NetworkSettings.Ports}} \
  {{$p}} → {{(index $conf 0).HostPort}}{{end}}' container_name

docker port is the simplest and most readable option.

docker attach connects your terminal to a running container’s stdin/stdout/stderr:

# Attach to a running container
docker attach container_name

# Detach without stopping (Ctrl+P, Ctrl+Q)
# (press Ctrl+P then Ctrl+Q to detach)

Key difference from docker exec -it:

• docker attach connects to the main process (PID 1)
• docker exec -it starts a new process inside the container

When to use:

• When you started a container in the foreground and need to reconnect
• To see the main process’s output in real-time

Caution: If you send Ctrl+C while attached, it terminates the main process (which will stop the container).

ONBUILD adds a trigger instruction that runs later when the image is used as a base image in another Dockerfile:

# Base image Dockerfile (node-base)
FROM node:18-alpine
ONBUILD COPY package*.json ./
ONBUILD RUN npm install
ONBUILD COPY . .

# Child Dockerfile
FROM node-base    # ← ONBUILD triggers run here
# Triggers run automatically before any child instructions
CMD ["node", "server.js"]

How it works:

1. When building node-base, ONBUILD instructions are stored as metadata (not executed)
2. When building a child image that uses FROM node-base, the ONBUILD instructions execute first
3. The child Dockerfile’s own instructions run after ONBUILD complete

Use case: Creating reusable framework/base images that can’t know the application’s specific files.

Caution: ONBUILD can create confusing, non-transparent builds. Most projects prefer explicit Dockerfiles over ONBUILD.