Docker Interview Questions & Answers Part 02

# Run a container
docker run -d -p 80:80 --name webserver nginx

# Check running containers
docker ps

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

# Client sends command to daemon
docker run nginx
# Docker client → API call → dockerd → pulls nginx image → creates container

# Basic Dockerfile example
FROM node:18-alpine          # Base image
WORKDIR /app                 # Set working directory
COPY package*.json ./        # Copy dependency files
RUN npm install              # Install dependencies
COPY . .                     # Copy application code
EXPOSE 3000                  # Document port
CMD ["node", "server.js"]    # Default command to run

# Build image from Dockerfile
docker build -t myapp:1.0 .

# Build with no cache
docker build --no-cache -t myapp:1.0 .

FROM ubuntu:22.04
LABEL maintainer="dev@example.com"
ARG APP_VERSION=1.0
ENV APP_ENV=production
WORKDIR /app
COPY . .
RUN apt-get update && apt-get install -y python3
EXPOSE 8080
USER appuser
HEALTHCHECK --interval=30s CMD curl -f http://localhost:8080/health
ENTRYPOINT ["python3"]
CMD ["app.py"]

FROM nginx
RUN apt-get update && apt-get install -y curl   # Build time only

ENTRYPOINT ["nginx"]         # Always runs nginx
CMD ["-g", "daemon off;"]    # Default args (can be overridden)

# CMD can be overridden:
docker run myimage echo "hello"   # Overrides CMD

# ENTRYPOINT stays, CMD becomes args:
docker run myimage -c /etc/nginx/nginx.conf   # "-c ..." overrides CMD only

# List networks
docker network ls

# Create custom bridge network
docker network create --driver bridge mynetwork

# Run container on custom network
docker run -d --network mynetwork --name app nginx

# Inspect network
docker network inspect mynetwork

# On same network, containers can resolve each other by name:
docker run -it --network mynetwork alpine ping app

# Step 1: Find the running container ID
docker ps

# Step 2: Run the container and install packages
docker exec -it <container_id> bash
apt-get install -y curl vim

# Step 3: Commit the container to a new image
docker commit <container_id> myimage:v2

# With author and message:
docker commit \
  --author "Dev Team" \
  --message "Added curl and vim" \
  <container_id> myimage:v2

# Verify the new image
docker images | grep myimage
docker run myimage:v2 which curl   # Test curl is available

# Step 4 (Best Practice): Update your Dockerfile instead!
# RUN apt-get install -y curl vim
# docker build -t myimage:v2 .

# Step 1: Check restart count and status
docker ps -a
# Look at RESTARTS column and STATUS

# Step 2: Check container logs (recent entries)
docker logs <container_name>

# Step 3: Check logs with timestamps
docker logs --timestamps <container_name>

# Step 4: Follow logs in real-time during restart
docker logs -f <container_name>

# Step 5: Check exit code
docker inspect <container_name> \
  --format '{{.State.ExitCode}} {{.State.Error}}'
# Exit 1 = app error, 137 = OOMKilled, 139 = segfault, 143 = SIGTERM

# Step 6: Check events
docker events --filter container=<container_name>

# Step 7: Check resource constraints
docker stats <container_name>

# Step 8: Check inside the container
docker exec -it <container_name> sh

# Tip 1: Use slim/alpine base images
FROM node:18-alpine     # 180MB vs FROM node:18 → 1.1GB

# Tip 2: Multi-stage builds (build in one stage, copy only artifacts)
FROM node:18-alpine AS builder
WORKDIR /app
COPY package*.json ./
RUN npm install
COPY . .
RUN npm run build

FROM nginx:alpine
COPY --from=builder /app/dist /usr/share/nginx/html
# Final image only contains built files + nginx, no node_modules

# Tip 3: Combine RUN commands (each RUN = one layer)
# BAD (3 layers):
RUN apt-get update
RUN apt-get install -y curl
RUN rm -rf /var/lib/apt/lists/*

# GOOD (1 layer):
RUN apt-get update && \
    apt-get install -y curl && \
    rm -rf /var/lib/apt/lists/*

# Tip 4: Use .dockerignore
echo "node_modules\n.git\n*.log\ndist" > .dockerignore

# Tip 5: Don't copy unnecessary files
COPY src/ ./src/   # Instead of COPY . .

# Check image size
docker images --format "table {{.Repository}}\t{{.Tag}}\t{{.Size}}"

# Analyze layers
docker history myimage:1.0

# Method 1: Docker Scout (built into Docker CLI)
docker scout cves myimage:1.0
docker scout recommendations myimage:1.0

# Method 2: Trivy (most popular, free, open-source)
# Install
curl -sfL https://raw.githubusercontent.com/aquasecurity/trivy/main/contrib/install.sh | sh

# Scan image
trivy image myimage:1.0

# Scan with specific severity
trivy image --severity HIGH,CRITICAL myimage:1.0

# Output as JSON for CI/CD
trivy image --format json -o results.json myimage:1.0

# Method 3: Snyk
snyk container test myimage:1.0

# Method 4: AWS ECR Scan (if using ECR)
aws ecr start-image-scan \
  --repository-name my-repo \
  --image-id imageTag=1.0

aws ecr describe-image-scan-findings \
  --repository-name my-repo \
  --image-id imageTag=1.0

# Integrate into CI/CD pipeline (Jenkins/GitHub Actions):
# Run trivy after docker build, fail pipeline if CRITICAL vulns found
trivy image --exit-code 1 --severity CRITICAL myimage:1.0

# BAD (Never do this):
ENV DB_PASSWORD=mysecret123          # Visible in image layers
docker run -e DB_PASSWORD=mysecret   # Visible in docker inspect

# Method 1: Docker Secrets (Docker Swarm)
echo "mysecret" | docker secret create db_password -
docker service create \
  --secret db_password \
  --name myapp myimage
# Secret available at: /run/secrets/db_password inside container

# Method 2: Environment variables from a file (for compose)
# .env file (not committed to git):
DB_PASSWORD=mysecret123

# docker-compose.yml:
# env_file:
#   - .env

# Method 3: AWS Secrets Manager / SSM at runtime
# In entrypoint script:
export DB_PASSWORD=$(aws secretsmanager get-secret-value \
  --secret-id prod/db-password \
  --query SecretString --output text)

# Method 4: Vault (HashiCorp) Agent Sidecar
# Vault agent auto-renews and injects secrets into container

# Method 5: Kubernetes Secrets (when in K8s)
kubectl create secret generic db-secret --from-literal=password=mysecret
# Mount as volume or envFrom in pod spec

# Immediate mitigation:

# Step 1: Confirm and assess the vulnerability
trivy image myimage:1.0 --severity CRITICAL

# Step 2: Check if the vulnerable package is actually used
docker run myimage:1.0 dpkg -l | grep <package-name>

# Step 3: If critical — isolate/rollback immediately
# Kubernetes rollback:
kubectl rollout undo deployment/myapp

# Docker Swarm rollback:
docker service rollback myapp-service

# Step 4: Fix the vulnerability
# Update base image:
# FROM node:18-alpine → FROM node:18.20-alpine (patched version)

# Update specific package:
RUN apt-get update && apt-get install -y --only-upgrade <vulnerable-package>

# Step 5: Rebuild and rescan
docker build -t myimage:1.1 .
trivy image --exit-code 1 --severity CRITICAL myimage:1.1

# Step 6: Secure the CI/CD pipeline going forward
# - Add trivy scan gate in Jenkins/GitHub Actions
# - Set up automated base image update PRs (Renovate/Dependabot)
# - Schedule weekly image rescans even for deployed images

# Namespaces used:
# PID namespace → isolated process IDs
# NET namespace → isolated networking
# MNT namespace → isolated filesystem
# UTS namespace → isolated hostname
# IPC namespace → isolated inter-process communication
# USER namespace → isolated user IDs

# cgroups control:
# CPU usage
# Memory limits
# I/O bandwidth

# Check running containers
docker ps

# Inspect container details (image, mounts, env)
docker inspect <container_name>

# Access container filesystem
docker exec -it <container_name> sh
ls -la /app/
cat /app/config.json

# Check mounted volumes
docker inspect <container_name> \
  --format '{{json .Mounts}}' | python3 -m json.tool

# Copy file from container to host for inspection
docker cp <container_name>:/app/config.json /tmp/config.json

# Check image that the container is running
docker inspect <container_name> --format '{{.Config.Image}}'

# Check container logs for startup output
docker logs <container_name> --tail 50

# Remove stopped containers
docker container prune -f

# Remove dangling images (untagged, not used)
docker image prune -f

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

# Remove unused volumes
docker volume prune -f

# Remove unused networks
docker network prune -f

# Nuclear option — remove everything unused
docker system prune -a -f --volumes

# Check disk usage before/after
docker system df

# In Jenkins pipeline — clean before build:
pipeline {
  stages {
    stage('Clean') {
      steps {
        sh 'docker system prune -f'
        sh 'docker rmi myapp:old || true'
      }
    }
  }
}

# Graceful stop (allows 10s for cleanup by default)
docker stop mycontainer

# Graceful stop with custom timeout
docker stop --time 30 mycontainer

# Force kill immediately
docker kill mycontainer

# Send specific signal
docker kill --signal SIGHUP mycontainer

# Method 1: Check env vars inside running container
docker exec mycontainer env
docker exec mycontainer printenv DB_HOST

# Method 2: Inspect from outside
docker inspect mycontainer --format '{{json .Config.Env}}'

# Method 3: Validate at entrypoint script level
#!/bin/bash
# entrypoint.sh
required_vars=("DB_HOST" "DB_PORT" "APP_SECRET")
for var in "${required_vars[@]}"; do
  if [ -z "${!var}" ]; then
    echo "ERROR: Required env var $var is not set"
    exit 1
  fi
done
exec "$@"

# Dockerfile:
COPY entrypoint.sh /entrypoint.sh
RUN chmod +x /entrypoint.sh
ENTRYPOINT ["/entrypoint.sh"]
CMD ["node", "server.js"]

# Method 4: Docker Compose env validation
# Pass from .env file and validate with compose healthcheck

# Method 1: Docker (standalone) — switch back to previous image tag
docker stop myapp
docker rm myapp
docker run -d --name myapp myimage:1.0   # Previous version

# Method 2: Docker Compose
# Revert docker-compose.yml to old image version
# image: myapp:1.0 (instead of 1.1)
docker-compose up -d

# Method 3: Docker Swarm
docker service rollback myapp-service
# Or update to previous image:
docker service update --image myimage:1.0 myapp-service

# Method 4: Kubernetes (if using K8s)
kubectl rollout undo deployment/myapp
kubectl rollout undo deployment/myapp --to-revision=3   # Specific revision

# Method 5: Scripted rollback
PREV_IMAGE=$(docker inspect myapp --format '{{.Config.Image}}')
# Store previous image tag in a file or environment variable before each deploy
docker stop myapp && docker rm myapp
docker run -d --name myapp $PREV_IMAGE

# Stage 1: Build (uses full Go/Node/Maven image)
FROM golang:1.21 AS builder
WORKDIR /app
COPY go.mod go.sum ./
RUN go mod download
COPY . .
RUN CGO_ENABLED=0 GOOS=linux go build -o myapp ./cmd/

# Stage 2: Final image (tiny, secure)
FROM alpine:3.18
RUN apk --no-cache add ca-certificates
WORKDIR /root/
COPY --from=builder /app/myapp .
EXPOSE 8080
CMD ["./myapp"]

# Build
docker build -t myapp:1.0 .

# Result: Final image is ~15MB instead of ~800MB
docker images myapp

# Stage 1: Build — full Node toolchain, only exists during build
FROM node:18-alpine AS builder
WORKDIR /app
COPY package*.json ./
RUN npm ci                     # reproducible install from package-lock.json
COPY . .
RUN npm run build              # outputs static files to /app/build

# Stage 2: Serve — tiny final image, no Node/npm at all
FROM nginx:1.25-alpine AS final
COPY --from=builder /app/build /usr/share/nginx/html
COPY nginx.conf /etc/nginx/conf.d/default.conf
EXPOSE 80
HEALTHCHECK --interval=30s CMD wget -q --spider http://localhost/ || exit 1
CMD ["nginx", "-g", "daemon off;"]

docker build -t frontend:1.0 .
docker images frontend
# builder stage: ~450MB (node_modules + build tools)
# final image:   ~25MB  (just nginx + static files)

# 1. Confirm exposure — is the vulnerable component actually in use?
trivy image --severity CRITICAL myimage:1.0
docker run myimage:1.0 dpkg -l | grep <affected-package>

# 2. Check for an available patched version
trivy image myimage:1.0 --format json | jq '.Results[].Vulnerabilities[] | select(.VulnerabilityID=="CVE-2023-44487")'

# 3. Immediate mitigation while a fix is prepared (if internet-facing and unpatched)
# e.g., rate-limit at the load balancer / WAF layer

# 4. Permanent fix — bump the base image / package to the patched version
# FROM node:18.17-alpine  →  FROM node:18.18-alpine

# 5. Rebuild, rescan, verify clean
docker build -t myimage:1.1 .
trivy image --exit-code 1 --severity CRITICAL myimage:1.1

# 6. Roll out via normal pipeline (not a manual hotfix) so it's tracked and repeatable