Docker & Container Architecture | DevOps Reference Notes
Docker & Container Architecture
DevOps Reference Notes
Concepts • Architecture • Commands • Flags
1. Why We Need Containers
• Resolve conflicts between library/dependency versions and network port clashes
• Eliminate delays in provisioning of Virtual Machines
• Utilize the full potential of host resources and reduce infrastructure cost
2. What Is a Container
A container is a lightweight, isolated execution environment that packages an application with its
dependencies (libraries, binaries, configuration files) while sharing the host operating system's kernel.
Aspect Containers vs VMs
Virtualization OS-level (process isolation) — NOT hardware virtualization
Kernel Shares the host OS kernel
Boot time Milliseconds vs minutes for VMs
Size Megabytes vs Gigabytes for VMs
3. Benefits of Containers
• Deploy multiple applications inside a single host OS
• Create isolated environments per application on the host OS
• Separate libs, binaries, and config files for each application
• Faster software provisioning time
• Resolve software migration challenges
• Lower infrastructure cost
Internal Use Only Page
Docker & Container Architecture | DevOps Reference Notes
4. Container Architecture
4.1 Container Host
• The underlying machine providing CPU, memory, storage, and network for containers
• Can be physical or virtual (VM)
• Requires a container engine installed — Docker, Podman, LXC
4.2 Container Client
• docker CLI — the user-facing command-line interface to interact with the Docker daemon
4.3 Container Image
A container image is a lightweight, immutable, read-only template used to create containers.
• Application code
• Runtime (Java, Python, [Link])
• Libraries & dependencies
• OS base layer (Alpine, Ubuntu, etc.)
Image Types
Type Description
Raw Image Minimal OS footprint (Alpine, Ubuntu, RHEL). Not a full OS. Used as a base to
build custom/service images.
Service Image Pre-packaged service (Jenkins, Nginx, Tomcat). Built on top of a raw image.
4.4 Container Image Registries
A central repository to store and distribute container images.
Type Examples
Public Docker Hub, [Link]
Private AWS ECR, Azure ACR, Harbor, Nexus
4.5 Namespaces
Namespaces isolate containers so they cannot see or interfere with each other. Each container
believes it has its own system.
Internal Use Only Page
Docker & Container Architecture | DevOps Reference Notes
Namespace Isolation Provided
PID Process isolation
NET Network (IP, ports)
MNT Filesystem mounts
UTS Hostname
IPC Inter-process communication
USER User IDs
4.6 Containers
• A running instance of an image
• Created using: Image + Namespaces + Cgroups
• Lightweight because they share the host kernel (no full OS like VMs)
4.7 Cgroups (Control Groups)
Used to limit and control resource usage by containers:
• CPU
• Memory
• Disk I/O
• Network bandwidth
4.8 Container Runtime
Responsible for running containers. Operates at two levels:
Level Examples & Role
Low-level runc, crun — Directly creates containers using Namespaces & Cgroups
Runtime
High-level Docker, containerd, CRI-O — Provides APIs and manages image lifecycle
Runtime
Kubernetes uses containerd or CRI-O (NOT Docker anymore)
Internal Use Only Page
Docker & Container Architecture | DevOps Reference Notes
5. Image & Container Commands
5.1 Image Commands
List available images
docker images
Pull an image
# From Docker Hub (public)
docker pull <image-name>:<tag>
# From private registry (Nexus / ECR / ACR)
docker pull <registry-url>/<image-name>:<tag>
Push an image
# To Docker Hub
docker push <dockerhub-username>/<image-name>:<tag>
# To private registry
docker push <registry-url>/<image-name>:<tag>
Search for an image
docker search <image-name>
docker search [Link]/nginx
docker search [Link]/nginx
Tag / Rename an image
docker tag <image-id/image-name> <new-image-name:tag>
Inspect Docker system & storage
docker system df # Show volumes and disk usage
docker info # Show Docker info
docker info | grep -i root # Show Docker root path (/var/lib/docker)
Delete images and containers
docker rmi <image-name/ID> # Delete image
docker rm <container-name/ID> # Delete container
docker rm -f <container-name/ID> # Force delete container
Internal Use Only Page
Docker & Container Architecture | DevOps Reference Notes
💡 Docker does NOT delete an image if it is used as a base layer by another image. Docker
images are layer-based and shared. An image is only deleted when no container and no
other image depends on it.
5.2 Container Run Commands
Run containers
# Run service image (detached, production use)
docker run -d --name test nginx
docker container run -d --name=test nginx
# Run raw image (interactive + detached)
docker run -itd --name=test ubuntu
# Run service image interactively (for testing/debugging)
docker run -it --name=test <image-name/ID> bash
For raw images (ubuntu, alpine), use -itd to invoke /bin/bash. In production, always test
service images interactively first, then run detached.
5.3 Container Management Commands
List containers
docker ps # Running containers only
docker ps -a # All containers (including stopped)
Stop a container
docker stop <container-name/ID>
List processes inside container
docker top <container-name>
Execute commands / Login to container
# Login to container (opens new shell, creates new PID)
docker exec -it <container-name> bash
# Run command without logging in
docker exec -it <container-name/ID> <command>
docker exec creates a new process inside the container. When you exit, the container
keeps running — it does NOT stop.
Internal Use Only Page
Docker & Container Architecture | DevOps Reference Notes
Attach to a container
docker attach <container-name/ID> # Only for raw containers
# Safe detach (no SIGHUP — container stays running)
CTRL + P + Q
docker attach connects your terminal to the container's MAIN process (no new PID
created). Use CTRL+P+Q to safely detach without stopping the container.
Inspect & Monitor
docker inspect <container-name/ID> # Full JSON details about container
docker stats <container-name/ID> # Live resource usage (CPU, mem, net, I/O)
6. Docker Flags Reference
6.1 Basic / Runtime Flags
Flag Description
-d Run container in detached mode (background)
-it Interactive + TTY (for shell access)
-p host:container Map host port to container port
-P Auto-map all exposed ports to random host ports
--name Assign a name to the container
--rm Auto-remove container when it exits
--restart Restart policy: no | always | unless-stopped | on-failure
6.2 Environment & Volume Flags
Flag Description
-e KEY=VAL Set environment variable
--env-file Load environment variables from a file
-v host:container Bind mount or named volume
--mount Advanced mount syntax (preferred over -v for clarity)
6.3 Network Flags
Flag Description
--network Attach container to a Docker network
Internal Use Only Page
Docker & Container Architecture | DevOps Reference Notes
--hostname Set container hostname
--ip Assign a static IP (user-defined networks only)
--dns Custom DNS server
--add-host Add entry to /etc/hosts
--link Legacy container linking (deprecated)
6.4 Resource Limit Flags
Flag Description
--cpus Limit CPU usage (e.g. --cpus=1.5)
--memory Limit memory (e.g. --memory=512m)
--memory-swap Swap memory limit
--pids-limit Limit number of processes
--ulimit Set ulimit options
6.5 Security Flags
Flag Description
--user Run container as specific user
--group-add Add supplementary group
--privileged Full host access — DANGEROUS, use with care
--cap-add Add a Linux capability
--cap-drop Drop a Linux capability
--security-opt Apply seccomp/AppArmor profiles
--read-only Mount container filesystem as read-only
6.6 Logging & Health Check Flags
Flag Description
--log-driver Logging driver (json-file, syslog, fluentd, etc.)
--log-opt Logging driver options
--health-cmd Command to run for health checks
--health-interval Interval between health checks
--health-retries Number of retries before marking unhealthy
--health-timeout Timeout for each health check
6.7 Misc / Advanced Flags
Flag Description
Internal Use Only Page
Docker & Container Architecture | DevOps Reference Notes
--entrypoint Override the default ENTRYPOINT of the image
--workdir Set working directory inside the container
--label Attach metadata labels to the container
--pull Control image pull behavior (always | missing | never)
--platform Set target OS/architecture (e.g. linux/amd64)
7. Image & Container File System
💡 Overlay2 is the storage driver responsible for managing the Docker container file system
in the backend.
7.1 File System Overview
• Every image and container has its own file system
• Images use Overlay2 with system-generated file system namespaces
7.2 Container File System Namespaces
Each container has two file system namespaces:
Namespace Type & Description
lowerDir (imageDir) Read-only — The image file system. Changes in the container are
NOT reflected here.
upperDir (containerDir) Writable — The container file system. All changes are written here
at runtime.
7.3 Copy-on-Write (CoW)
• Container file system operates on Copy-on-Write (CoW) principle
• If you modify anything inside a running container, Docker copies the file from the image layer into
the container's upper (writable) layer, then makes the change
• The original image data remains completely unchanged
7.4 Image Mount & Space Consumption
• Containers consume 0B of space immediately after launch — they only mount the image
• Container consumes space only after you log in and create/modify files (written to upperDir)
• The upperDir (writable layer) is LOST when the container is terminated
• After launch, mount points are created for both image and container layers
Internal Use Only Page
Docker & Container Architecture | DevOps Reference Notes
Inspect Container File System Directories
# Show container Upper Directory (writable layer)
docker inspect <container-name/ID> | grep -i upper
# Show container Lower Directory (image/read-only layer)
docker inspect <container-name/ID> | grep -i lower
8. How to Create Container Images
Method Description
Imperative (Manual) Manually install software inside a running container, then commit it as a
new image
Declarative Use a Dockerfile to define build steps — automated, repeatable, CI-
(Automated) friendly
8.1 Imperative Method (Manual Build)
Steps to manually build an image (e.g. apache2)
1. Take a base image as per requirements
2. Run the image / deploy a container
3. Attach to the container and install the required software
4. Logout and commit the container as a new image
Parent-Child concept in images: The parent is the base OS raw image (e.g. alpine,
ubuntu). The child is the service image built on top of it (e.g. nginx, tomcat).
Dangling Images
• Images that are no longer tagged or referenced — old/unused versions accumulating on disk
• Should be pruned regularly to free host server disk space
# Remove dangling images only
docker image prune
# Remove dangling AND unused images
docker image prune -a
8.2 Declarative Method (Dockerfile)
Benefits of Dockerfile
Internal Use Only Page
Docker & Container Architecture | DevOps Reference Notes
• Automates the manual image build process
• Less time-consuming and repeatable
• Fast software build practice — ideal for CI pipelines
Dockerfile Standards
• File name must be Dockerfile (or dockerfile in newer versions)
• No fixed/required path for the Dockerfile
• Contains directives (instructions) executed in order
Dockerfile Directives Reference
Directive Purpose & Key Points
FROM Defines the base (parent) image. Pulls from registry if not local. Use multiple
times for multi-stage builds. e.g. FROM python:3.7
LABEL Adds metadata (author, version, description) as key-value pairs. Best practice:
combine multiple labels in one instruction.
RUN Executes commands at IMAGE BUILD TIME. Each RUN creates a new layer.
Combine commands with && and \ to minimize layers and reduce image size.
ADD Copies files from local host OR remote URLs (http/https/ftp). Supports auto-
decompression (.[Link]) and regex patterns (*.tar).
COPY Copies files from local host only. No decompression. Can copy between build
stages. Uses WORKDIR as default destination.
WORKDIR Sets working directory for all subsequent instructions. Creates the directory if it
does not exist. Keeps layers consistent.
CMD Default command run when container STARTS. Only last CMD is used. Can be
overridden at runtime: docker run image bash
ENTRYPOINT Defines the main command (PID 1). Cannot be easily overridden. CMD passes
arguments to it. Use exec form. Recommended for production.
EXPOSE Documents the port the app uses inside the container. Does NOT publish the
port. Actual mapping done with -p in docker run.
VOLUME Creates persistent storage. Data survives container removal. Used for
databases, logs, uploads. Docker manages volume if only path is given.
ENV Sets environment variables available at build and runtime. Avoids hardcoding.
Used for DB credentials, ports, profiles.
USER Defines which user runs the container process. Default is root (security risk).
Use non-root user for improved security.
ENTRYPOINT + CMD Combined
Internal Use Only Page
Docker & Container Architecture | DevOps Reference Notes
# CMD acts as default arguments passed to ENTRYPOINT
ENTRYPOINT ["java"] # main command (PID 1)
CMD ["-jar", "[Link]"] # default argument
# Override CMD at runtime
docker run image_name bash # overrides CMD only
8.3 Build Caching
• Dockerfile checks the build cache before executing each step — unchanged steps are skipped
• Any change in an instruction invalidates cache for that step AND all steps below it
• Best practice: place new/frequently-changing instructions towards the BOTTOM of the Dockerfile
to maximize cache hits
# Remove dangling build cache only
docker builder prune
# Remove dangling + active build cache
docker builder prune -a
8.4 Multi-Stage Build
Problems Before Multi-Stage
• Single Dockerfile needed SDK + Maven + JRE — bloating the final image
• Artifact built inside container increased image size further
• Required two separate Dockerfiles: one for build, one for deploy
• Artifact had to be manually copied from the build container to host VM, then picked up by the
second Dockerfile
# Copy data from container to host VM
docker cp <container-name>:<source-path> <host-destination>
Multi-Stage Solution
• Both build and runtime stages live in a single Dockerfile — no manual docker cp needed
• First stage output is discarded by default after the build completes
• Use --target to build only up to a specific stage (useful for debugging build issues)
# Build only the first (BUILD) stage
docker build -t mybuildimage . --target BUILD
Multi-Stage Dockerfile Example
# Stage 1: Build ─────────────────────────────────────────────
FROM maven:3.9-jdk-17 AS BUILD
WORKDIR /app
Internal Use Only Page
Docker & Container Architecture | DevOps Reference Notes
COPY . .
RUN mvn clean package
# Stage 2: Runtime ───────────────────────────────────────────
FROM openjdk:17-jre
WORKDIR /app
COPY --from=BUILD /app/target/[Link] [Link]
ENTRYPOINT ["java"]
CMD ["-jar", "[Link]"]
Internal Use Only Page