Answer:

• Container: A lightweight, isolated runtime instance of a container image. It packages the application code along with all its runtime dependencies, libraries, and configurations. Containers share the host operating system's kernel, making them highly efficient, fast to start, and low-resource.
• Virtual Machine (VM): A complete virtual emulation of a physical computer. It runs a full guest operating system, virtualized hardware resources, and a hypervisor (like VMware or VirtualBox). This makes VMs more resource-intensive, slower to boot, and heavier to manage. | Feature | Container | Virtual Machine (VM) | | :--- | :--- | :--- | | OS Share | Shares the host OS kernel | Runs a full guest OS | | Boot Time | Seconds | Minutes | | Resource Usage | Lightweight (MBs) | Heavy (GBs) | | Isolation | Process-level (Namespaces/Cgroups) | Hardware-level (Hypervisor) |

Answer: Docker is an open-source platform that enables developers to build, package, ship, and run applications inside lightweight, portable containers. It is widely used in DevOps because it:

• Eliminates Environment Inconsistency: Ensures the application behaves exactly the same way in local development, testing, staging, and production ("It works on my machine" problem solved).
• Simplifies Microservices: Helps decouple large monolithic systems into independent, self-contained microservices.
• Accelerates Testing: Spin up and destroy containerized testing environments dynamically.
• Optimizes Resource Density: Allows running multiple isolated applications on a single host machine with minimal resource overhead.

Answer: Docker does not run containers directly; it delegates execution to specialized runtimes:

• dockerd: The high-level daemon that manages API commands, networks, images, and builds.
• containerd: A CNCF graduated project that manages the container lifecycle (transfers images, manages storage, supervises execution).
• runc: The low-level runtime that communicates directly with the Linux kernel to configure namespaces and cgroups, starts the container process, and exits.
• CRI-O: A lightweight alternative to containerd designed specifically for Kubernetes (CRI compliant) to run containers directly via runc.

Execution flow of docker run:#

1. Docker CLI converts the command to a REST API call and sends it to dockerd.
2. dockerd calls containerd via gRPC.
3. containerd downloads the image (if missing) and creates the runtime bundle metadata.
4. containerd calls containerd-shim (which keeps the container alive without keeping containerd active).
5. containerd-shim calls runc to create namespaces, attach cgroups, and start the container process.
6. Once the process is running, runc exits.

Answer: Namespaces are a Linux kernel feature that provides isolation for container processes, making it appear as if the container has its own dedicated operating system instance.

Key Namespaces used by Docker:#

• pid: Isolate process IDs. Processes inside the container cannot see host or other container processes.
• net: Isolate network interfaces, IP routing tables, and firewall rules.
• mnt: Isolate filesystem mount points.
• ipc: Isolate system resources like shared memory.
• uts: Isolate hostname and domain names.
• user: Isolate user and group IDs (allows mapping root inside the container to a non-root user on the host).

Answer: Control Groups (cgroups) are a Linux kernel feature that enforces resource limits and metering on processes. Docker uses cgroups to guarantee that containers do not monopolize host resources. It controls limits for:

• CPU: Allocate specific cores or limit CPU execution cycles (e.g., --cpus=2).
• Memory: Set maximum RAM and swap thresholds (e.g., -m 512m to prevent out-of-memory issues on the host).
• I/O: Limit block device write/read bandwidth.

Answer:

• Dependency Isolation: Containers bundle the exact version of the runtime (e.g., Node.js 18, Python 3.11), libraries, OS binaries, and packages required by the application. This prevents host dependency conflicts.
• Image Portability: A container image built on a developer's local workstation is the exact same immutable binary package run by staging, testing, and production servers. The environment shifts are handled only through externalized runtime variables.
• Version Control & Rollbacks: Images are tagged (e.g., v1.2.3), allowing teams to easily track, deploy, or revert back to previous releases.
• Fast Provisioning & Reproducibility: Because container startup times are measured in seconds, developers can spin up identical production replicas locally to debug complex issues.

Answer: Docker images are constructed as a stack of read-only layers. Each instruction in a Dockerfile (e.g., RUN, COPY, ADD) creates a new layer.

• Union File System: Merges all read-only layers into a single, unified filesystem view.
• Copy-On-Write (CoW): When a running container modifies a file in a read-only layer, Docker copies the file to the writable container layer before applying the edits, leaving the underlying image layers unchanged.
• OverlayFS: The union filesystem driver used by Docker. It combines:
  • Lowerdir: The read-only image layers.
  • Upperdir: The writable container layer containing modifications.
  • Merged: The combined view presented to the running container process.

Answer: Multi-stage builds use multiple FROM instructions in a single Dockerfile to divide the build process into temporary stages, separating compilation environments from the final production runtime.

Example Dockerfile:#

# Stage 1: Build & Compile
FROM golang:1.20 AS builder
WORKDIR /app
COPY . .
RUN CGO_ENABLED=0 GOOS=linux go build -o myapp
# Stage 2: Final Runtime
FROM alpine:3.18
WORKDIR /root/
COPY --from=builder /app/myapp .
CMD ["./myapp"]

Why they are used:#

• Reduces the size of the final image by excluding compilers, build logs, and source files.
• Improves security by minimizing the libraries and tools available in the running container.

Answer: Docker Compose is a tool designed to define, configure, and manage multi-container applications running on a single host. It uses a single YAML file (docker-compose.yml) to define the services, networks, volumes, and ports required for the entire application stack.

Key Roles:#

• Service Definition: Specifies how each container should be built, which image to use, and which environment variables to inject.
• Dependency Management: Uses the depends_on keyword to define startup order (e.g., ensuring a database container starts before the API backend).
• Isolated Networking: Automatically creates a shared network for the application, allowing containers to resolve and communicate with each other using their service names (e.g., http://db:5432).
• Local Development: Enables launching a complex environment (e.g., frontend, API, database, cache) with a single CLI command (docker compose up).

Answer:

1. Deconstruct & Map Dependencies: Analyze application runtimes, OS requirements, local configuration files, and persistent state storage requirements (e.g., local logs, file uploads).
2. Write Optimized Dockerfiles:
   • Use lightweight base images (Alpine, Debian-slim, or Distroless).
   • Pin specific image tags instead of using latest.
   • Use multi-stage builds to compile code in a build environment, copying only clean runtime binaries to the final image.
3. Decouple Configurations & Secrets: Externalize configurations. Modify the application code to read configurations from environment variables or mounted configuration files (e.g., ConfigMaps/Secrets).
4. Isolate State & Storage: Move local file uploads to Cloud Object Storage (AWS S3) and database states to managed databases (RDS). Containers must remain stateless.
5. Establish Container Networking: Configure port maps and health check paths (/healthz).
6. Create Orchestration Manifests: Write a docker-compose.yml for local testing. Write Kubernetes manifests (Deployments, Services, PVCs, Ingresses) for production.
7. CI/CD Pipeline Integration: Automate the process of building images, running tests, and pushing images to a secure registry on every code commit.

Answer:

• Linux Capabilities: Linux splits root permissions into smaller, distinct capabilities (e.g., CAP_NET_ADMIN, CAP_SYS_ADMIN). Docker strips all non-essential capabilities from container roots by default. You can drop all capabilities and add only what is needed: --cap-drop=ALL --cap-add=NET_BIND_SERVICE.
• seccomp (Secure Computing Mode): Filters system calls (syscalls) made by container processes. Docker applies a default seccomp profile that blocks dangerous syscalls (like reboot or ptrace).
• AppArmor / SELinux: Linux Security Modules that enforce mandatory access controls (MAC) on containers, restricting which files, directories, and ports a container can access on the host.
• Trivy: A simple, comprehensive vulnerability scanner for container images. Run Trivy in your CI/CD pipelines (trivy image <image-name>) to detect OS package and dependency vulnerabilities (CVEs) before pushing to production registries.

Answer:

1. Multi-stage Builds: Compile code in a temporary stage, and copy only the final compiled artifact into a lightweight runtime image.
2. Run as Non-Root User: Never let containers run as UID 0 (root). Declare a non-privileged user (USER appuser) to mitigate container breakout vulnerabilities.
3. Minimize Image Layers: Combine commands inside RUN statements using && and clean up package managers caches (rm -rf /var/lib/apt/lists/*) in the same layer.
4. Use Specific Tags: Avoid using latest. Pin base images to specific tags (e.g., node:18-alpine) to ensure predictable build outcomes.
5. Use .dockerignore: Exclude local build directories (node_modules), test suites, and git folders from being copied into the container context.

Answer: A container escape is a security vulnerability or exploit where a process inside a container bypasses namespace, cgroup, or storage isolation to execute commands directly on the host operating system. This is often caused by running containers with the --privileged flag or mounting the host's /var/run/docker.sock file.