Advanced

# Initialize swarm on manager node (first node)
docker swarm init --advertise-addr 192.168.1.10
# => Swarm initialized: current node (abc123) is now a manager
# => Outputs: docker swarm join --token SWMTKN-1-xxx 192.168.1.10:2377
 
# Get join token for worker nodes
docker swarm join-token worker
# => docker swarm join --token SWMTKN-1-worker-xxx 192.168.1.10:2377
 
# Get join token for manager nodes
docker swarm join-token manager
# => docker swarm join --token SWMTKN-1-manager-xxx 192.168.1.10:2377
 
# On worker nodes: Join swarm as worker
docker swarm join --token SWMTKN-1-worker-xxx 192.168.1.10:2377
# => This node joined a swarm as a worker.
 
# On additional manager nodes: Join as manager
docker swarm join --token SWMTKN-1-manager-xxx 192.168.1.10:2377
# => This node joined a swarm as a manager.
 
# List swarm nodes (from manager)
docker node ls
# => abc123def456 * manager1 Ready Active Leader     (current node)
# => def456ghi789   manager2 Ready Active Reachable
# => jkl012mno345   worker1  Ready Active
# => Leader = primary manager (Raft consensus election)
 
# Inspect swarm cluster
docker info | grep -A 10 Swarm
# => Swarm: active, Managers: 3, Nodes: 6
# => Default Address Pool: 10.0.0.0/8, SubnetSize: 24
 
# Promote worker to manager
docker node promote worker1
# => Node worker1 promoted to a manager in the swarm.
 
# Demote manager to worker
docker node demote manager3
# => Manager manager3 demoted in the swarm.
 
# Drain node (stop scheduling new tasks, move existing tasks away)
docker node update --availability drain worker1
# => worker1 availability: drain — no new tasks scheduled here
 
# Activate drained node
docker node update --availability active worker1
# => worker1 availability: active — eligible for scheduling again
 
# Add labels to node (for placement constraints)
docker node update --label-add environment=production worker1
docker node update --label-add datacenter=us-east worker1
# => Labels allow constraint-based task placement (see Example 67)
 
# Inspect node details
docker node inspect worker1 --pretty
# => Hostname: worker1, State: Ready, Availability: Active
# => Labels: environment=production, datacenter=us-east
 
# Leave swarm from worker node
docker swarm leave
# => Node left the swarm.
 
# Leave swarm from manager (requires force)
docker swarm leave --force
# => Manager left the swarm. Cluster may be unstable.
 
# Remove node from swarm
docker node rm worker1
# => worker1 removed from swarm

# File: docker-compose.yml
 
version: "3.8"
# => Docker Compose format version
 
services:
# => Service definitions for swarm deployment
 web:
# => Web frontend service
 image: nginx:alpine
# => Nginx web server image
 deploy:
# => Swarm deployment configuration
 replicas: 3
 # => Maintains 3 running replicas across swarm
 update_config:
# => Rolling update configuration
 parallelism: 1
 # => Update 1 replica at a time
 delay: 10s
 # => Wait 10 seconds between updates
 failure_action: rollback
 # => Rollback on update failure
 restart_policy:
# => Container restart policy
 condition: on-failure
# => Restart only when container exits with non-zero code
 delay: 5s
# => Wait 5s before restarting
 max_attempts: 3
# => Max 3 restart attempts before giving up
 placement:
# => Swarm placement configuration
 constraints:
# => Hard placement constraints
 - node.role == worker
 # => Only schedule on worker nodes
 preferences:
# => Soft placement preferences
 - spread: node.labels.datacenter
 # => Spread across different datacenters
 ports:
# => Port publishing configuration
 - "8080:80"
 # => Published port accessible on all nodes (ingress routing mesh)
 networks:
# => Network connections
 - frontend
# => Connect to frontend overlay network
 
 api:
# => API backend service
 image: my-api:latest
# => Custom API application image
 deploy:
# => Swarm deployment configuration
 replicas: 5
 # => 5 API replicas distributed across worker nodes
 resources:
# => Resource constraints
 limits:
# => Maximum resource usage
 cpus: "0.5"
 # => Hard limit: container throttled at 0.5 CPU
 memory: 512M
 # => Container killed if exceeds 512M
 reservations:
# => Guaranteed minimum resources
 cpus: "0.25"
 # => Guaranteed 0.25 CPU for scheduling
 memory: 256M
 # => Guaranteed 256M memory for scheduling
 update_config:
# => Rolling update configuration
 parallelism: 2
 # => Update 2 replicas simultaneously
 delay: 5s
# => Wait 5s between batches
 order: start-first
 # => Start new task before stopping old (zero-downtime)
 placement:
# => Placement configuration
 constraints:
# => Hard scheduling constraints
 - node.labels.environment == production
 # => Only schedules on nodes labeled "production"
 networks:
# => Network connections
 - frontend
 # => Receives traffic from web service
 - backend
 # => Connects to database
 
 database:
# => PostgreSQL database service
 image: postgres:15-alpine
# => PostgreSQL 15 Alpine image
 deploy:
# => Swarm deployment configuration
 replicas: 1
 # => Stateful service: single replica
 placement:
# => Placement constraints
 constraints:
# => Pin to specific node
 - node.hostname == worker1
 # => Pin to specific node (stateful data)
 environment:
# => Environment variables
 POSTGRES_PASSWORD: secret
# => Database password (use Docker secrets in production)
 volumes:
# => Volume mounts
 - db-data:/var/lib/postgresql/data
 # => Persistent data volume
 networks:
# => Network connections
 - backend
 # => Internal network only (not exposed to frontend)
 
networks:
# => Network definitions
 frontend:
# => External-facing overlay network
 driver: overlay
 # => Overlay network spans all swarm nodes
 backend:
# => Internal backend network
 driver: overlay
# => Overlay for internal communication
 internal: true
 # => Internal-only (no external access)
 
volumes:
# => Named volume definitions
 db-data:
# => Database persistent storage
 driver: local
 # => Local volume pinned to database node

# Deploy stack to swarm
docker stack deploy -c docker-compose.yml myapp
# => Creating network myapp_frontend
# => Creating network myapp_backend
# => Creating service myapp_web
# => Creating service myapp_api
# => Creating service myapp_database
 
# List services
docker service ls
# => ID NAME MODE REPLICAS IMAGE
# => abc123def456 myapp_web replicated 3/3 nginx:alpine
# => def456ghi789 myapp_api replicated 5/5 my-api:latest
# => ghi789jkl012 myapp_database replicated 1/1 postgres:15-alpine
 
# Inspect service
docker service ps myapp_web
# => ID NAME NODE DESIRED STATE CURRENT STATE
# => abc123 myapp_web.1 worker1 Running Running 2 minutes ago
# => def456 myapp_web.2 worker2 Running Running 2 minutes ago
# => ghi789 myapp_web.3 worker3 Running Running 2 minutes ago
 
# Scale service manually
docker service scale myapp_api=10
# => myapp_api scaled to 10
# => Swarm creates 5 additional replicas across nodes
 
docker service ps myapp_api --filter desired-state=running
# => Shows 10 running replicas distributed across worker nodes
 
# Update service image (rolling update)
docker service update --image my-api:v2 myapp_api
# => myapp_api
# => overall progress: 5 out of 10 tasks
# => 1/10: running [====================>]
# => 2/10: running [====================>]
# => Updates 2 replicas at a time (parallelism: 2)
# => Zero-downtime deployment (order: start-first)
 
# Rollback service update
docker service rollback myapp_api
# => myapp_api
# => rollback: manually requested rollback
# => overall progress: rolling back update
 
# View service logs (aggregated from all replicas)
docker service logs -f myapp_web
# => myapp_web.1.abc123 | 192.168.1.50 - - [29/Dec/2025:11:20:00] "GET / HTTP/1.1" 200
# => myapp_web.2.def456 | 192.168.1.51 - - [29/Dec/2025:11:20:01] "GET / HTTP/1.1" 200
# => myapp_web.3.ghi789 | 192.168.1.52 - - [29/Dec/2025:11:20:02] "GET / HTTP/1.1" 200
 
# Test ingress routing mesh (access service from any node)
curl http://worker1:8080
# => <!DOCTYPE html>.. (nginx welcome page from any replica)
 
curl http://worker2:8080
# => <!DOCTYPE html>.. (load balanced across all replicas)
 
# Remove stack
docker stack rm myapp
# => Removing service myapp_database
# => Removing service myapp_api
# => Removing service myapp_web
# => Removing network myapp_backend
# => Removing network myapp_frontend

# Create secret from file
echo "db_password_value" | docker secret create db_password -
# => Pipes password via stdin to create secret
# => Secret created: db_password
 
# Create secret from existing file
echo "api_key_12345" > api_key.txt
# => Write API key to temporary file
docker secret create api_key api_key.txt
# => Create Docker secret from file
rm api_key.txt # Remove plaintext file
# => Delete plaintext file after creating secret
 
# List secrets
docker secret ls
# => ID NAME CREATED UPDATED
# => abc123def456 db_password 2 minutes ago 2 minutes ago
# => def456ghi789 api_key 1 minute ago 1 minute ago
 
# Inspect secret (data NOT shown)
docker secret inspect db_password
# => [
# => {
# => "ID": "abc123def456",
# => "Version": { "Index": 10 },
# => "CreatedAt": "2025-12-29T11:25:00Z",
# => "UpdatedAt": "2025-12-29T11:25:00Z",
# => "Spec": {
# => "Name": "db_password",
# => "Labels": {}
# => }
# => }
# => ]
# => Secret value NOT visible (encrypted)
 
# Create service using secrets
docker service create \
# => Create Swarm service with secret
 --name postgres \
# => Service name
 --secret db_password \
# => Mount the named secret into container
 --env POSTGRES_PASSWORD_FILE=/run/secrets/db_password \
# => Tell postgres to read password from file
 postgres:15-alpine
# => Mounts secret at /run/secrets/db_password
# => Read-only, in-memory filesystem (tmpfs)
 
# Verify secret mount inside container
docker exec $(docker ps -q -f name=postgres) ls -l /run/secrets/
# => total 0
# => -r--r--r-- 1 root root 18 Dec 29 11:26 db_password
 
docker exec $(docker ps -q -f name=postgres) cat /run/secrets/db_password
# => db_password_value
# => Secret readable from within the container
 
# Use secrets in docker-compose (swarm mode)
cat > docker-compose.yml << 'EOF'
# => Create Docker Compose file with secrets configuration
version: '3.8'
# => Docker Compose format version
 
services:
# => Service definitions
 database:
# => PostgreSQL database service
 image: postgres:15-alpine
# => PostgreSQL Alpine image
 secrets:
# => Secret mounts for this service
 - db_password
 # => Mounts secret at /run/secrets/db_password
 environment:
# => Environment variables
 POSTGRES_PASSWORD_FILE: /run/secrets/db_password
 # => PostgreSQL reads password from file
 deploy:
# => Swarm deployment settings
 replicas: 1
# => Single database instance
 
 api:
# => API service
 image: my-api
# => Custom API image
 secrets:
# => Secret mounts for this service
 - source: api_key
# => Secret name in Docker secrets store
 target: /run/secrets/api_key
 # => Custom mount path
 uid: '1000'
# => File owner UID
 gid: '1000'
# => File owner GID
 mode: 0400
 # => File permissions: read-only for uid 1000
 environment:
# => Environment variables
 API_KEY_FILE: /run/secrets/api_key
# => App reads key from file path
 deploy:
# => Swarm deployment settings
 replicas: 3
# => 3 API replicas
 
secrets:
# => External secret references
 db_password:
# => Database password secret
 external: true
 # => Uses existing secret (created with docker secret create)
 api_key:
# => API key secret
 external: true
# => Must be pre-created with docker secret create
EOF
# => End of docker-compose.yml heredoc
 
# Deploy stack with secrets
docker stack deploy -c docker-compose.yml myapp
# => Services automatically get secrets mounted
 
# Update secret (requires service recreation)
docker service update \
# => Update running service configuration
 --secret-rm db_password \
# => Remove old secret from service
 --secret-add source=db_password_new,target=db_password \
# => Add new secret at same mount path
 myapp_database
# => Removes old secret, adds new secret
# => Service recreated with new secret
 
# Rotate secret safely
echo "new_password" | docker secret create db_password_v2 -
# => Create new version of the secret
docker service update \
# => Update service to use new secret
 --secret-rm db_password \
# => Remove old secret
 --secret-add source=db_password_v2,target=db_password \
# => Mount new secret at same path
 myapp_database
# => Zero-downtime secret rotation
# => Old tasks use old secret until replaced
 
# Remove secret (must not be in use)
docker secret rm api_key
# => Error: secret 'api_key' is in use by service 'myapp_api'
 
# Remove service first, then secret
docker service rm myapp_api
# => Remove service before deleting secret
docker secret rm api_key
# => api_key removed

# File: docker-compose.yml
 
version: "3.8"
# => Docker Compose format version
 
services:
# => Service definitions
 api:
# => API service with read-only filesystem
 image: my-api:latest
# => Custom API application image
 read_only: true
 # => Root filesystem is read-only
 # => Prevents malicious code from modifying system files
 tmpfs:
# => In-memory writable directories
 - /tmp:size=100M,mode=1777
 # => Writable temporary directory in memory
 - /var/run:size=10M,mode=755
 # => Writable runtime directory
 volumes:
# => Named volume mounts
 - logs:/var/log/app:rw
 # => Writable volume for application logs
 environment:
# => Environment variables
 NODE_ENV: production
# => Set production mode
 deploy:
# => Swarm deployment settings
 replicas: 3
# => Run 3 replicas for high availability
 
 nginx:
# => Nginx web server with read-only filesystem
 image: nginx:alpine
# => Nginx Alpine image
 read_only: true
# => Root filesystem is read-only
 tmpfs:
# => In-memory writable directories for Nginx
 - /var/cache/nginx:size=50M
 # => Nginx cache directory (writable)
 - /var/run:size=5M
 # => PID file location
 volumes:
# => Volume mounts
 - ./nginx.conf:/etc/nginx/nginx.conf:ro
 # => Configuration (read-only)
 - static-content:/usr/share/nginx/html:ro
 # => Static files (read-only)
 ports:
# => Port publishing
 - "8080:80"
# => Published on host port 8080
 
volumes:
# => Named volume definitions
 logs:
# => Application log volume
 static-content:
# => Static web content volume

# Run container with read-only root filesystem
docker run -d --name readonly-test \
 --read-only \
 # => Makes all container layers read-only
 --tmpfs /tmp:size=100M \
 # => Writable tmpfs at /tmp (in RAM, not persisted)
 nginx:alpine
# => Root filesystem is read-only
# => /tmp is writable (in memory)
 
# Try to modify root filesystem (fails)
docker exec readonly-test sh -c 'echo "test" > /test.txt'
# => sh: can't create /test.txt: Read-only file system
# => Attacker cannot write anywhere on root filesystem
 
# Writable tmpfs works
docker exec readonly-test sh -c 'echo "test" > /tmp/test.txt'
# => Success (tmpfs is writable)
 
docker exec readonly-test cat /tmp/test.txt
# => test
# => /tmp writes work as expected by applications
 
# Verify read-only setting
docker inspect readonly-test --format='{{.HostConfig.ReadonlyRootfs}}'
# => true
# => Confirms read-only is enforced at runtime
 
# Test application functionality
curl http://localhost:8080
# => <!DOCTYPE html>.. (works normally)
# => Read-only filesystem doesn't affect normal operation
 
# Deploy to swarm with read-only root
docker stack deploy -c docker-compose.yml myapp
# => Swarm enforces read_only: true on all replicas
 
# Verify security improvement (simulate intrusion attempt)
# Attacker gains access to container shell
docker exec -it $(docker ps -q -f name=myapp_api) sh
 
# Inside container: Try to install malware (fails)
/ # apk add --no-cache curl
# => ERROR: Unable to lock database: Read-only file system
# => Package manager cannot write to /var/cache/apk
 
# Try to modify system files (fails)
/ # echo "malicious" >> /etc/passwd
# => sh: can't create /etc/passwd: Read-only file system
# => Cannot modify user database or add backdoor accounts
 
# Try to write to writable tmpfs (succeeds but data lost on restart)
/ # echo "temp data" > /tmp/file.txt
/ # exit
 
# Restart container (tmpfs data lost)
docker restart $(docker ps -q -f name=myapp_api.1)
# => tmpfs wiped on restart (in-memory only)
 
docker exec $(docker ps -q -f name=myapp_api.1) cat /tmp/file.txt
# => cat: can't open '/tmp/file.txt': No such file or directory
# => Temporary data not persisted

# Default capabilities (root user in container)
docker run --rm alpine sh -c 'apk add --no-cache libcap && capsh --print'
# => Current: = cap_chown,cap_dac_override,cap_fowner,cap_fsetid,cap_kill,cap_setgid,cap_setuid,cap_setpcap,cap_net_bind_service,cap_net_raw,cap_sys_chroot,cap_mknod,cap_audit_write,cap_setfcap+eip
# => Many dangerous capabilities enabled by default
# => 14 capabilities by default - reduce to minimum needed
 
# Drop all capabilities, add only necessary ones
docker run --rm \
# => Temporary container to verify capabilities
 --cap-drop=ALL \
 # => Removes all default capabilities
 --cap-add=NET_BIND_SERVICE \
 # => Adds back only the needed capability
 alpine sh -c 'apk add --no-cache libcap && capsh --print'
# => Current: = cap_net_bind_service+eip
# => Only NET_BIND_SERVICE capability (bind to ports < 1024)
 
# Example: Web server needs only NET_BIND_SERVICE
docker run -d --name web \
# => Start Nginx web server in detached mode
 --cap-drop=ALL \
# => Drop all default Linux capabilities
 --cap-add=NET_BIND_SERVICE \
# => Add only port-binding capability
 -p 80:80 \
# => Publish port 80
 nginx:alpine
# => Runs with minimal capabilities
# => nginx can bind port 80 but has no other elevated privileges
 
# Try to use dropped capability (fails)
docker exec web sh -c 'apk add --no-cache libcap && capsh --print | grep cap_sys_admin'
# => (no output - CAP_SYS_ADMIN not available)
# => Attacker cannot perform admin operations even if shell is gained
 
# Example: Application needs no special capabilities
docker run -d --name api \
# => Start API in detached mode
 --cap-drop=ALL \
# => Drop all Linux capabilities
 --user 1000:1000 \
 # => Non-root user + no capabilities = maximum security
 -p 3000:3000 \
# => Publish API port
 my-api
# => No capabilities at all (most secure)
 
# Compose example with dropped capabilities
cat > docker-compose.yml << 'EOF'
# => Create Docker Compose configuration
version: '3.8'
# => Docker Compose format version
 
services:
# => Service definitions
 web:
# => Web service
 image: nginx:alpine
# => Nginx Alpine image
 cap_drop:
# => Capabilities to remove
 - ALL
# => Remove all Linux capabilities
 cap_add:
# => Capabilities to add back
 - NET_BIND_SERVICE
 # => Only capability needed for binding to port 80
 ports:
# => Port publishing
 - "80:80"
# => Publish HTTP port
 
 api:
# => API service
 image: my-api
# => Custom API image
 cap_drop:
# => Capabilities to remove
 - ALL
 # => No capabilities needed (runs on port > 1024)
 user: "1000:1000"
# => Run as non-root user UID/GID 1000
 ports:
# => Port publishing
 - "3000:3000"
# => Publish API port
 
 database:
# => PostgreSQL database service
 image: postgres:15-alpine
# => PostgreSQL 15 Alpine image
 cap_drop:
# => Remove all capabilities first
 - ALL
# => Start from zero capabilities
 cap_add:
# => Add only required capabilities
 - CHOWN
 # => PostgreSQL needs to change file ownership
 - DAC_OVERRIDE
 # => Read/write files regardless of permissions
 - FOWNER
 # => Bypass ownership checks for file operations
 - SETGID
 # => Switch to postgres group
 - SETUID
 # => Switch to postgres user
 # => Minimal set for PostgreSQL operation
 environment:
# => Environment variables
 POSTGRES_PASSWORD: secret
# => Database password
EOF
# => End of docker-compose.yml heredoc
 
# Common capability uses:
# CAP_NET_BIND_SERVICE: Bind to ports < 1024
# CAP_CHOWN: Change file ownership
# CAP_DAC_OVERRIDE: Bypass file permission checks
# CAP_FOWNER: Bypass permission checks on file operations
# CAP_SETGID: Set GID
# CAP_SETUID: Set UID
# CAP_SYS_ADMIN: Mount filesystems, admin operations (DANGEROUS - never use)
# CAP_NET_RAW: Use raw sockets (DANGEROUS - enables network attacks)
 
# Dangerous capabilities to NEVER add:
# CAP_SYS_ADMIN: Full system administration (container escape risk)
# CAP_SYS_MODULE: Load kernel modules (container escape risk)
# CAP_SYS_RAWIO: Direct hardware access
# CAP_SYS_PTRACE: Trace processes (can dump secrets from memory)
 
# Check container capabilities at runtime
docker inspect web --format='{{.HostConfig.CapDrop}}'
# => [ALL]
# => Confirms all capabilities dropped
 
docker inspect web --format='{{.HostConfig.CapAdd}}'
# => [NET_BIND_SERVICE]
# => Only NET_BIND_SERVICE added back

# Install Trivy scanner
curl -sfL https://raw.githubusercontent.com/aquasecurity/trivy/main/contrib/install.sh | sh -s -- -b /usr/local/bin
# => Trivy scanner installed
 
# Scan image for vulnerabilities
trivy image nginx:alpine
# => 2025-12-29T11:30:00.000Z INFO Vulnerability scanning is enabled
# => 2025-12-29T11:30:05.000Z INFO Detected OS: alpine
# => 2025-12-29T11:30:05.000Z INFO Detected vulnerabilities: 15
# =>
# => nginx:alpine (alpine 3.19.0)
# => Total: 15 (UNKNOWN: 0, LOW: 5, MEDIUM: 8, HIGH: 2, CRITICAL: 0)
# =>
# => +------------------+------------------+----------+-------------------+
# => | LIBRARY | VULNERABILITY ID | SEVERITY | INSTALLED VERSION |
# => +------------------+------------------+----------+-------------------+
# => | openssl | CVE-2023-12345 | HIGH | 3.1.0-r1 |
# => | libcurl | CVE-2023-67890 | HIGH | 8.4.0-r0 |
# => | zlib | CVE-2023-11111 | MEDIUM | 1.3-r0 |
# => +------------------+------------------+----------+-------------------+
 
# Scan only for HIGH and CRITICAL vulnerabilities
trivy image --severity HIGH,CRITICAL nginx:alpine
# => Shows only serious vulnerabilities
 
# Scan and fail build if vulnerabilities found
trivy image --exit-code 1 --severity CRITICAL nginx:alpine
# => Exit code 0: No critical vulnerabilities
# => Exit code 1: Critical vulnerabilities found (fails CI/CD)
 
# Scan local Dockerfile before building
trivy config Dockerfile
# => Scans Dockerfile for misconfigurations
# => Detects: Running as root, missing health checks, etc.
 
# Scan built image with detailed output
trivy image --format json my-app:latest > scan-results.json
# => JSON output for automated processing
 
# Extract vulnerability summary
cat scan-results.json | jq '.Results[0].Vulnerabilities | group_by(.Severity) | map({Severity: .[0].Severity, Count: length})'
# => [
# => { "Severity": "CRITICAL", "Count": 2 },
# => { "Severity": "HIGH", "Count": 5 },
# => { "Severity": "MEDIUM", "Count": 12 }
# => ]
 
# CI/CD integration (GitHub Actions example)
cat > .github/workflows/scan.yml << 'EOF'
# => Create GitHub Actions vulnerability scanning workflow
name: Container Scan
# => Workflow name in GitHub Actions UI
 
on: [push]
# => Trigger on every push
 
jobs:
# => Workflow jobs
 scan:
# => Single job for scanning
 runs-on: ubuntu-latest
# => Use Ubuntu runner with Docker pre-installed
 steps:
# => Sequential workflow steps
 - uses: actions/checkout@v3
# => Checkout source code
 
 - name: Build image
# => Step 1: Build Docker image
 run: docker build -t my-app:${{ github.sha }} .
# => Tag with git commit SHA for traceability
 
 - name: Run Trivy vulnerability scanner
# => Step 2: Scan for vulnerabilities
 uses: aquasecurity/trivy-action@master
# => Official Trivy GitHub Action
 with:
# => Action configuration
 image-ref: my-app:${{ github.sha }}
# => Scan the image built in previous step
 format: 'sarif'
# => SARIF format for GitHub Security tab integration
 output: 'trivy-results.sarif'
# => Save results to file for upload
 severity: 'CRITICAL,HIGH'
# => Only report actionable severities
 exit-code: '1'
 # => Fails build if CRITICAL or HIGH vulnerabilities found
 
 - name: Upload Trivy scan results to GitHub Security tab
# => Step 3: Upload to GitHub Security
 uses: github/codeql-action/upload-sarif@v2
# => Upload SARIF to GitHub Code Scanning
 with:
# => Upload configuration
 sarif_file: 'trivy-results.sarif'
# => Path to the SARIF results file
EOF
# => End of GitHub Actions workflow heredoc
 
# Scan multi-stage build (scan final stage only)
trivy image --image-src my-app:latest
# => Scans only production stage, not build artifacts
 
# Ignore specific vulnerabilities (use with caution)
cat > .trivyignore << 'EOF'
# False positive - not applicable to our use case
CVE-2023-12345
 
# Accepted risk - no patch available, mitigated at network level
CVE-2023-67890
EOF
 
trivy image --ignorefile .trivyignore nginx:alpine
# => Skips ignored CVEs
 
# Scan running container
trivy container $(docker ps -q -f name=web)
# => Scans running container filesystem
 
# Regular scanning schedule (cron job)
cat > scan-images.sh << 'EOF'
# => Create daily container scanning script
#!/bin/bash
# Scan all running containers daily
 
for container in $(docker ps --format '{{.Names}}'); do
# => Loop over all running container names
 echo "Scanning $container.."
# => Progress indicator for each container
 trivy container $container --severity HIGH,CRITICAL
# => Scan and report HIGH/CRITICAL vulnerabilities
done
# => End of container loop
EOF
# => End of scan-images.sh heredoc
 
chmod +x scan-images.sh
# => Make script executable
# => Add to cron: 0 2 * * * /path/to/scan-images.sh

# File: Dockerfile.distroless (Go application)
 
# Build stage
FROM golang:1.21-alpine AS builder
# => Go 1.21 Alpine build environment
 
WORKDIR /app
# => Set working directory
 
COPY go.mod go.sum ./
# => Copy module files for dependency caching
RUN go mod download
# => Download all Go dependencies
 
COPY .
# => Copy all source files
RUN CGO_ENABLED=0 GOOS=linux go build -a -installsuffix cgo -o server .
# => Static binary (no dynamic linking)
# => CGO_ENABLED=0: pure Go binary, no C dependencies
# => -a: force rebuild of packages
 
# Production stage with distroless
FROM gcr.io/distroless/static-debian12
# => No shell, no package manager, no utilities
# => Only contains: /etc/passwd, /etc/group, tzdata, ca-certificates
 
COPY --from=builder /app/server /server
# => Copy only the compiled binary from builder
 
EXPOSE 8080
# => Document the port the server listens on
 
USER nonroot:nonroot
# => Runs as non-root user (UID 65532)
 
CMD ["/server"]
# => Array syntax (no shell needed)
# => Directly executes /server binary

# File: Dockerfile.distroless-node (Node.js application)
 
# Build stage
FROM node:18-alpine AS builder
# => Node.js 18 Alpine build environment
 
WORKDIR /app
# => Set working directory
 
COPY package*.json ./
# => Copy package files for dependency caching
RUN npm ci --only=production
# => Install only production dependencies (faster, smaller)
 
COPY .
# => Copy all source files
RUN npm run build
# => Compile TypeScript/bundle for production
 
# Production stage with distroless
FROM gcr.io/distroless/nodejs18-debian12
# => Contains Node.js runtime only
# => No npm, no shell, no package manager
 
COPY --from=builder /app/package.json /app/package-lock.json ./
# => Copy package metadata for runtime
COPY --from=builder /app/node_modules ./node_modules
# => Copy production dependencies
COPY --from=builder /app/dist ./dist
# => Copy compiled application code
 
EXPOSE 3000
# => Document the API port
 
CMD ["dist/main.js"]
# => Runs node dist/main.js automatically
# => Node.js runtime provided by distroless base

# Build distroless image
docker build -f Dockerfile.distroless -t my-app:distroless .
# => Build distroless production image
 
# Compare image sizes
docker images | grep my-app
# => my-app alpine 15MB (alpine base)
# => my-app distroless 10MB (distroless base - 33% smaller)
# => my-app debian 80MB (debian base - 8x larger!)
 
# Try to access shell (fails - no shell in distroless)
docker run --rm my-app:distroless sh
# => docker: Error response: OCI runtime create failed: exec: "sh": executable file not found
 
# Debugging distroless containers (use debug variant)
FROM gcr.io/distroless/static-debian12:debug
# => Includes busybox shell for debugging
 
docker run --rm -it my-app:distroless-debug sh
# => / # (busybox shell available)
 
# Inspect distroless container filesystem
docker run --rm my-app:distroless ls /
# => docker: Error response: executable file not found
# => ls command doesn't exist!
 
# Use multi-stage to inspect
docker build -t my-app:inspect --target builder -f Dockerfile.distroless .
docker run --rm my-app:inspect ls -la /
# => Inspects builder stage (has shell and tools)
 
# Scan distroless image (minimal vulnerabilities)
trivy image my-app:distroless
# => Total: 0 (UNKNOWN: 0, LOW: 0, MEDIUM: 0, HIGH: 0, CRITICAL: 0)
# => No vulnerabilities! (minimal attack surface)
 
# Compare with alpine
trivy image my-app:alpine
# => Total: 8 (LOW: 3, MEDIUM: 4, HIGH: 1)
# => Alpine has more packages = more vulnerabilities
 
# Available distroless base images:
# gcr.io/distroless/static-debian12 - Static binaries only (Go, Rust)
# gcr.io/distroless/base-debian12 - glibc, libssl, ca-certificates
# gcr.io/distroless/cc-debian12 - libc, libssl (C/C++ apps)
# gcr.io/distroless/java17-debian12 - Java 17 runtime
# gcr.io/distroless/nodejs18-debian12 - Node.js 18 runtime
# gcr.io/distroless/python3-debian12 - Python 3 runtime
 
# Health check in distroless (use HEALTHCHECK in Dockerfile)
FROM gcr.io/distroless/static-debian12
 
COPY --from=builder /app/server /server
COPY --from=builder /app/healthcheck /healthcheck
 
HEALTHCHECK --interval=30s --timeout=3s \
 CMD ["/healthcheck"]
# => Custom healthcheck binary (no curl/wget available)
 
# Logging from distroless (stdout only)
# Ensure application logs to stdout (no need for log files)

# Enable user namespace remapping in Docker daemon
cat > /etc/docker/daemon.json << 'EOF'
{
 "userns-remap": "default"
}
EOF
# => Creates dockremap user/group automatically
# => Container UID 0 (root) maps to unprivileged UID on host
 
# Restart Docker daemon
sudo systemctl restart docker
# => Restart required for user namespace remapping to take effect
 
# Check user namespace mapping
cat /etc/subuid | grep dockremap
# => dockremap:100000:65536
# => Container UIDs 0-65535 map to host UIDs 100000-165535
 
cat /etc/subgid | grep dockremap
# => dockremap:100000:65536
# => Container GIDs mapped similarly
 
# Run container with user namespace
docker run -d --name test-userns alpine sleep 3600
 
# Check process on host (remapped UID)
ps aux | grep sleep | grep -v grep
# => 100000 12345 0.0 0.0 1234 567 ? Ss 11:35 0:00 sleep 3600
# => Process runs as UID 100000 on host (not 0!)
 
# Inside container: Check UID (appears as root)
docker exec test-userns id
# => uid=0(root) gid=0(root) groups=0(root),1(bin),2(daemon)..
# => Container sees UID 0 (root)
 
# On host: Verify actual UID
ps -o user,uid,pid,cmd -p $(pgrep -f "sleep 3600")
# => USER UID PID CMD
# => 100000 100000 12345 sleep 3600
# => Host sees unprivileged UID
 
# Try to access host resources from container root
docker exec test-userns sh -c 'ls -la /hostdata'
# => ls: can't open '/hostdata': Permission denied
# => Even as "root" in container, no access to host directories
 
# Test privilege escalation attempt
docker exec test-userns sh -c 'echo "malicious" > /host-etc-passwd'
# => sh: can't create /host-etc-passwd: Permission denied
# => User namespace prevents host file access
 
# Disable user namespace for specific container (requires privilege)
docker run --userns=host -d alpine sleep 3600
# => Runs with host user namespace (dangerous - only for trusted containers)
 
# Compose with user namespace
cat > docker-compose.yml << 'EOF'
version: '3.8'
 
services:
 app:
 image: my-app
 # User namespace enabled automatically if daemon configured
 # OR explicitly disable for specific service:
 # userns_mode: "host" # Dangerous - bypasses isolation
EOF
 
# Check files created by container on host
docker run --rm -v /tmp/test:/data alpine sh -c 'touch /data/file.txt'
 
ls -ln /tmp/test/
# => total 0
# => -rw-r--r-- 1 100000 100000 0 Dec 29 11:40 file.txt
# => File owned by remapped UID (100000), not root (0)
 
# Security benefit: Root exploit in container
# Attacker gains root in container
docker exec test-userns sh -c 'whoami'
# => root
 
# On host: Still unprivileged user
ps aux | grep test-userns | head -1
# => 100000 12345 ..
# => Host sees unprivileged UID (defense in depth)

# File: .github/workflows/security.yml (GitHub Actions)
 
name: Security Scan
# => Workflow name shown in GitHub Actions UI
 
on:
# => Workflow triggers
 push:
 # => Push event trigger
 branches: [main, develop]
 # => Triggers on every push to main/develop
 pull_request:
 # => PR event trigger
 branches: [main]
 # => Also scans PRs targeting main before merge
 
jobs:
# => Workflow job definitions
 security-scan:
 # => Single security scanning job
 runs-on: ubuntu-latest
 # => Runs on GitHub-hosted Ubuntu runner
 
 steps:
 # => Sequential security scan steps
 - name: Checkout code
 # => Step 1: Get repository source
 uses: actions/checkout@v3
 # => Clones repository for scanning
 
 - name: Set up Docker Buildx
 # => Step 2: Configure advanced builder
 uses: docker/setup-buildx-action@v2
 # => Enables BuildKit for improved caching
 
 - name: Build Docker image
 # => Step 3: Build image for scanning
 run: |
 # => Shell command to build image
 docker build -t ${{ github.repository }}:${{ github.sha }} .
 # => Tags with SHA for unique identification
 
 - name: Run Trivy vulnerability scanner
 # => Step 4: Scan for OS and library CVEs
 uses: aquasecurity/trivy-action@master
 # => Official Trivy GitHub Action
 with:
 # => Trivy scan configuration
 image-ref: ${{ github.repository }}:${{ github.sha }}
 # => Scan the freshly built image
 format: "sarif"
 # => SARIF format integrates with GitHub Security tab
 output: "trivy-results.sarif"
 # => Save results for upload
 severity: "CRITICAL,HIGH"
 # => Scans only for critical and high severity
 exit-code: "1"
 # => Fails build if CRITICAL or HIGH vulnerabilities found
 
 - name: Upload Trivy results to GitHub Security
 # => Step 5: Publish scan results to Security tab
 uses: github/codeql-action/upload-sarif@v2
 # => GitHub SARIF upload action
 if: always()
 # => Always uploads (even if scan failed)
 with:
 # => Upload configuration
 sarif_file: "trivy-results.sarif"
 # => Results visible in GitHub Security tab
 
 - name: Run Hadolint (Dockerfile linter)
 # => Step 6: Lint Dockerfile for best practices
 uses: hadolint/hadolint-action@v3.1.0
 # => Official Hadolint GitHub Action
 with:
 # => Hadolint configuration
 dockerfile: Dockerfile
 # => Dockerfile to lint
 failure-threshold: error
 # => Fails on Dockerfile errors (not warnings)
 
 - name: Scan for secrets in code
 # => Step 7: Detect accidentally committed secrets
 uses: trufflesecurity/trufflehog@main
 # => Official TruffleHog GitHub Action
 with:
 # => TruffleHog configuration
 path: ./
 # => Scan entire repository
 base: ${{ github.event.repository.default_branch }}
 # => Compare from default branch
 head: HEAD
 # => Scans git history diff for accidentally committed secrets
 
 - name: Docker Scout CVEs
 # => Step 8: Additional CVE scan with Docker Scout
 uses: docker/scout-action@v1
 # => Official Docker Scout action
 with:
 # => Docker Scout configuration
 command: cves
 # => Run CVE scanning command
 image: ${{ github.repository }}:${{ github.sha }}
 # => Scan this specific image
 only-severities: critical,high
 # => Filter to actionable severities
 exit-code: true
 # => Alternative scanner using Docker Scout
 
 - name: Generate SBOM (Software Bill of Materials)
 # => Step 9: Generate software inventory
 run: |
 # => Shell command to generate SBOM
 docker sbom ${{ github.repository }}:${{ github.sha }} > sbom.json
 # => Lists all packages in the image for supply chain audit
 
 - name: Upload SBOM artifact
 # => Step 10: Store SBOM as build artifact
 uses: actions/upload-artifact@v3
 # => GitHub artifact upload action
 with:
 # => Artifact upload configuration
 name: sbom
 # => Artifact name for download
 path: sbom.json
 # => SBOM stored as downloadable build artifact

# File: .gitlab-ci.yml (GitLab CI/CD)
 
stages:
  # => Pipeline stages run in order
  - build
  # => Build image and push to registry
  - security
  # => Run all security checks in parallel
  - deploy
  # => Only runs if build and security pass
 
variables:
  # => Pipeline-wide variables
  IMAGE_NAME: $CI_REGISTRY_IMAGE:$CI_COMMIT_SHA
  # => Unique image per commit (immutable)
 
build:
  # => Build job in build stage
  stage: build
  # => Belongs to build stage
  script:
    # => Commands to run
    - docker build -t $IMAGE_NAME .
    # => Build Docker image
    - docker push $IMAGE_NAME
    # => Image available for subsequent stages
 
trivy-scan:
  # => Trivy security scan job
  stage: security
  # => Runs in parallel with other security jobs
  image: aquasec/trivy:latest
  # => Run inside Trivy container
  script:
    # => Trivy scan command
    - trivy image --exit-code 1 --severity CRITICAL,HIGH $IMAGE_NAME
    # => Exit code 1 fails the job and blocks pipeline
  allow_failure: false
  # => Blocks pipeline if vulnerabilities found
 
hadolint:
  # => Dockerfile linting job
  stage: security
  # => Runs in parallel with trivy-scan
  image: hadolint/hadolint:latest
  # => Run inside Hadolint container
  script:
    # => Hadolint lint command
    - hadolint Dockerfile
    # => Lints Dockerfile for best practice violations
  allow_failure: false
  # => Errors block the pipeline
 
grype-scan:
  # => Grype vulnerability scan job
  stage: security
  # => Third security scanner in parallel
  image: anchore/grype:latest
  # => Run inside Grype container
  script:
    # => Grype scan command
    - grype $IMAGE_NAME --fail-on high
  # => Alternative vulnerability scanner (Anchore)
 
deploy:
  # => Deployment job in deploy stage
  stage: deploy
  # => Runs only if all security jobs pass
  script:
    # => Kubernetes deployment command
    - kubectl set image deployment/myapp app=$IMAGE_NAME
    # => Updates Kubernetes deployment image
  only:
    # => Conditions for running this job
    - main
    # => Only deploys from main branch
  when: on_success
  # => Only deploys if security scans pass

# Local pre-commit hook for security
cat > .git/hooks/pre-commit << 'EOF'
# => Create pre-commit hook script
#!/bin/bash
# => Bash shebang for hook script
 
echo "Running security checks.."
# => Notify developer that checks are running
 
# Scan Dockerfile
echo "Checking Dockerfile.."
# => Dockerfile lint check
docker run --rm -i hadolint/hadolint < Dockerfile
# => Pipes Dockerfile via stdin to hadolint container
if [ $? -ne 0 ]; then
# => Check if hadolint found errors
 echo "Dockerfile has issues. Fix them before committing."
 # => Inform developer of Dockerfile issues
 exit 1
 # => Non-zero exit blocks the commit
fi
 
# Check for secrets
echo "Scanning for secrets.."
# => Secret detection check
docker run --rm -v $(pwd):/src trufflesecurity/trufflehog:latest filesystem /src
# => Scans entire repo filesystem for credential patterns
if [ $? -ne 0 ]; then
# => Check if secrets were found
 echo "Potential secrets found. Remove them before committing."
 # => Alert developer about potential credential exposure
 exit 1
 # => Block commit with exposed secrets
fi
# => End of secrets check
 
echo "Security checks passed."
# => All checks passed, commit proceeds
EOF
 
chmod +x .git/hooks/pre-commit
# => Runs security checks before each commit
 
# Manual security scan before pushing
docker build -t myapp:latest .
# => Build fresh image for scanning
 
# Multiple scanners for comprehensive coverage
trivy image myapp:latest
# => Scans for OS and library vulnerabilities (fast)
grype myapp:latest
# => Anchore scanner (second opinion on vulnerabilities)
docker scout cves myapp:latest
# => Docker's own CVE scanner (uses Docker Hub data)
 
# Generate compliance report
trivy image --format json --output report.json myapp:latest
# => JSON output for programmatic processing
cat report.json | jq '.Results[0].Vulnerabilities | length'
# => Total vulnerability count
# => Example: 15 (need to remediate before deploy)
 
# Track vulnerabilities over time
git add scan-results/$(date +%Y-%m-%d).json
# => Version-controlled vulnerability tracking

# File: docker-compose.yml (Private registry with authentication)
 
version: "3.8"
# => Docker Compose format version
 
services:
# => Service definitions
 registry:
# => Private Docker Registry service
 image: registry:2
 # => Official Docker Registry v2 image
 ports:
# => Port publishing
 - "5000:5000"
 # => Standard registry port
 environment:
# => Registry configuration via environment variables
 REGISTRY_AUTH: htpasswd
 # => Enables htpasswd-based authentication
 REGISTRY_AUTH_HTPASSWD_PATH: /auth/htpasswd
 # => Path to htpasswd credentials file
 REGISTRY_AUTH_HTPASSWD_REALM: Registry Realm
 # => Realm shown in authentication prompt
 REGISTRY_STORAGE_FILESYSTEM_ROOTDIRECTORY: /data
 # => Store image layers in /data volume
 # TLS configuration
 REGISTRY_HTTP_TLS_CERTIFICATE: /certs/domain.crt
 # => TLS certificate (enables HTTPS)
 REGISTRY_HTTP_TLS_KEY: /certs/domain.key
 # => Private key for TLS certificate
 volumes:
# => Volume mounts
 - registry-data:/data
 # => Persistent storage for image layers
 - ./auth:/auth:ro
 # => htpasswd file (read-only for security)
 - ./certs:/certs:ro
 # => TLS certificates (read-only)
 restart: unless-stopped
# => Auto-restart on failure
 
 registry-ui:
# => Optional web UI for registry management
 image: joxit/docker-registry-ui:latest
# => Popular open-source registry UI
 ports:
# => UI port publishing
 - "8080:80"
 # => Web UI accessible at http://localhost:8080
 environment:
# => UI configuration
 REGISTRY_TITLE: My Private Registry
# => Displayed title in the UI
 REGISTRY_URL: https://registry.example.com:5000
 # => UI connects to registry on this URL
 DELETE_IMAGES: "true"
 # => Enables image deletion from UI
 SINGLE_REGISTRY: "true"
 # => Optimizes UI for single registry mode
 depends_on:
# => Service dependency
 - registry
 # => UI starts after registry is running
 
volumes:
# => Named volume definitions
 registry-data:
 # => Named volume persists image data

# Create authentication file
mkdir -p auth certs
# => Create directories for auth and TLS files
 
# Generate htpasswd file
docker run --rm \
# => Temporary container to generate htpasswd file
 --entrypoint htpasswd \
# => Override default entrypoint to use htpasswd
 httpd:2 -Bbn admin secretpassword > auth/htpasswd
# => Creates htpasswd file with user: admin, password: secretpassword
# => -B: bcrypt (strong hashing), -b: batch mode, -n: output to stdout
 
# Generate self-signed TLS certificate (production: use Let's Encrypt)
openssl req -newkey rsa:4096 -nodes -sha256 \
# => Generate new 4096-bit RSA key and certificate
 -keyout certs/domain.key -x509 -days 365 \
# => Output private key, self-signed cert valid 365 days
 -out certs/domain.crt \
# => Output certificate file
 -subj "/CN=registry.example.com"
# => Creates TLS certificate for HTTPS
# => CN must match the registry hostname
 
# Start private registry
docker compose up -d
# => Start registry and UI in detached mode
 
# Trust self-signed certificate (Linux)
sudo cp certs/domain.crt /usr/local/share/ca-certificates/registry.crt
# => Copy cert to system CA store
sudo update-ca-certificates
# => Adds certificate to system trust store
# => Required for docker to trust self-signed registry cert
 
# Login to private registry
docker login registry.example.com:5000
# => Username: admin
# => Password: secretpassword
# => Login Succeeded
 
# Tag image for private registry
docker tag my-app:latest registry.example.com:5000/my-app:latest
# => Tags with "latest" for default pull
docker tag my-app:latest registry.example.com:5000/my-app:1.0.0
# => Tags with version for pinned deployments
 
# Push to private registry
docker push registry.example.com:5000/my-app:latest
# => Pushes latest tag to private registry
docker push registry.example.com:5000/my-app:1.0.0
# => Pushes version tag to private registry
# => Uploads image to private registry
 
# List images in registry (API)
curl -u admin:secretpassword https://registry.example.com:5000/v2/_catalog
# => {"repositories":["my-app"]}
# => Lists all image repositories in registry
 
# List tags for image
curl -u admin:secretpassword https://registry.example.com:5000/v2/my-app/tags/list
# => {"name":"my-app","tags":["latest","1.0.0"]}
# => Shows all available tags for my-app
 
# Pull from private registry (on another machine)
docker login registry.example.com:5000
# => Authenticates with htpasswd credentials
docker pull registry.example.com:5000/my-app:1.0.0
# => Downloads image from private registry
 
# Delete image tag from registry
curl -X DELETE -u admin:secretpassword \
 https://registry.example.com:5000/v2/my-app/manifests/sha256:<digest>
# => Deletes specific image manifest (layers still present until GC)
 
# Run garbage collection to free space
docker exec registry bin/registry garbage-collect /etc/docker/registry/config.yml
# => Removes unreferenced layers after manifest deletion
 
# Registry with S3 storage (production)
cat > registry-s3.yml << 'EOF'
# => Create registry configuration with S3 storage backend
version: '3.8'
# => Docker Compose format version
 
services:
# => Service definitions
 registry:
# => Registry service with S3 backend
 image: registry:2
# => Official Docker Registry image
 ports:
# => Port publishing
 - "5000:5000"
# => Standard registry port
 environment:
# => S3 storage configuration
 REGISTRY_STORAGE: s3
# => Use S3 as storage driver
 REGISTRY_STORAGE_S3_REGION: us-east-1
# => AWS region for S3 bucket
 REGISTRY_STORAGE_S3_BUCKET: my-docker-registry
 # => Bucket must exist with appropriate IAM permissions
 REGISTRY_STORAGE_S3_ACCESSKEY: ${AWS_ACCESS_KEY_ID}
# => AWS access key from environment variable
 REGISTRY_STORAGE_S3_SECRETKEY: ${AWS_SECRET_ACCESS_KEY}
 # => Credentials from environment (not hardcoded)
EOF
# => Uses S3 for scalable, durable storage
 
# Registry with Redis cache (performance)
cat >> docker-compose.yml << 'EOF'
# => Append Redis cache config to existing docker-compose.yml
 redis:
# => Redis cache service
 image: redis:7-alpine
# => Redis 7 Alpine image
 restart: unless-stopped
# => Auto-restart on failure
 
 registry:
# => Registry service override with Redis cache
 environment:
# => Additional environment variables
 REGISTRY_STORAGE_CACHE_BLOBDESCRIPTOR: redis
 # => Cache blob descriptor lookups in Redis
 REGISTRY_REDIS_ADDR: redis:6379
# => Redis connection address
 REGISTRY_REDIS_DB: 0
# => Redis database number
EOF
# => Caches blob descriptors in Redis for faster pulls

# File: .github/workflows/ci-cd.yml
 
name: CI/CD Pipeline
# => Full pipeline: build → test → scan → deploy
 
on:
# => Workflow trigger events
 push:
 # => Trigger on push to branches and tags
 branches: [main, develop]
 # => Build on every push to these branches
 tags:
 # => Trigger on version tags
 - "v*"
 # => Also builds on version tags (e.g., v1.0.0)
 pull_request:
 # => Trigger on PR events
 branches: [main]
 # => Validates PRs before merge
 
env:
# => Global environment variables
 REGISTRY: ghcr.io
 # => GitHub Container Registry
 IMAGE_NAME: ${{ github.repository }}
 # => e.g., username/repo-name
 
jobs:
# => Four jobs: build-test, security-scan, deploy-staging, deploy-production
 # Job 1: Build and test
 build-test:
 # => Builds Docker image and runs tests
 runs-on: ubuntu-latest
 # => Uses GitHub-hosted Ubuntu runner
 permissions:
 # => Minimal required permissions
 contents: read
 # => Read repository contents
 packages: write
 # => write permission to push images to GHCR
 
 steps:
 # => Sequential build steps
 - name: Checkout code
 # => Step 1: Get repository source
 uses: actions/checkout@v3
 # => Checks out repository code
 
 - name: Set up Docker Buildx
 # => Step 2: Configure advanced Docker builder
 uses: docker/setup-buildx-action@v2
 # => Enables advanced build features (caching, multi-platform)
 
 - name: Log in to GitHub Container Registry
 # => Step 3: Authenticate with image registry
 uses: docker/login-action@v2
 # => Docker login action
 with:
 # => Login credentials
 registry: ${{ env.REGISTRY }}
 # => Authenticate to ghcr.io
 username: ${{ github.actor }}
 # => Use workflow-triggering user
 password: ${{ secrets.GITHUB_TOKEN }}
 # => Authenticates using workflow-scoped token
 
 - name: Extract metadata
 # => Step 4: Generate image tags and labels
 id: meta
 # => Reference this step's outputs as steps.meta.outputs.*
 uses: docker/metadata-action@v4
 # => Official Docker metadata action
 with:
 # => Metadata action configuration
 images: ${{ env.REGISTRY }}/${{ env.IMAGE_NAME }}
 # => Base image name for tag generation
 tags: |
 # => Tag patterns to generate
 type=ref,event=branch
 # => Branch name tag (e.g., main, develop)
 type=ref,event=pr
 # => PR number tag (e.g., pr-42)
 type=semver,pattern={{version}}
 # => Full semver tag (e.g., v1.0.0)
 type=semver,pattern={{major}}.{{minor}}
 # => Major.minor tag (e.g., 1.0)
 type=sha
 # => Generates tags: main, pr-123, v1.0.0, 1.0, sha-abc123
 
 - name: Build and push Docker image
 # => Step 5: Build and push to registry
 uses: docker/build-push-action@v4
 # => Official Docker build-push action
 with:
 # => Build configuration
 context: .
 # => Build context is repository root
 push: ${{ github.event_name != 'pull_request' }}
 # => Only pushes for non-PR events (PRs just build)
 tags: ${{ steps.meta.outputs.tags }}
 # => Apply all generated tags
 labels: ${{ steps.meta.outputs.labels }}
 # => Apply OCI standard labels
 cache-from: type=registry,ref=${{ env.REGISTRY }}/${{ env.IMAGE_NAME }}:buildcache
 # => Pull cached layers from registry
 cache-to: type=registry,ref=${{ env.REGISTRY }}/${{ env.IMAGE_NAME }}:buildcache,mode=max
 # => Registry cache for faster subsequent builds
 
 - name: Run tests in container
 # => Step 6: Execute test suite in built image
 run: |
 # => Shell command to run tests
 docker run --rm ${{ env.REGISTRY }}/${{ env.IMAGE_NAME }}:sha-${{ github.sha }} npm test
 # => Runs tests inside the built image
 
 # Job 2: Security scanning
 security-scan:
 # => Scans built image for vulnerabilities
 runs-on: ubuntu-latest
 # => Ubuntu runner for security scanning
 needs: build-test
 # => Only runs after build-test succeeds
 permissions:
 # => Permission to upload security results
 security-events: write
 # => Required to upload SARIF results
 
 steps:
 # => Security scan steps
 - name: Run Trivy scanner
 # => Step 1: Scan image for CVEs
 uses: aquasecurity/trivy-action@master
 # => Official Trivy GitHub Action
 with:
 # => Trivy scan configuration
 image-ref: ${{ env.REGISTRY }}/${{ env.IMAGE_NAME }}:sha-${{ github.sha }}
 # => Scan the image built in build-test job
 format: "sarif"
 # => SARIF format for GitHub Security integration
 output: "trivy-results.sarif"
 # => Save results to file
 severity: "CRITICAL,HIGH"
 # => Scans for high and critical vulnerabilities
 
 - name: Upload Trivy results
 # => Step 2: Upload to GitHub Security tab
 uses: github/codeql-action/upload-sarif@v2
 # => GitHub SARIF upload action
 with:
 # => Upload configuration
 sarif_file: "trivy-results.sarif"
 # => Visible in GitHub Security tab
 
 # Job 3: Deploy to staging
 deploy-staging:
 # => Deploys to staging from develop branch
 runs-on: ubuntu-latest
 # => Ubuntu runner for deployment
 needs: [build-test, security-scan]
 # => Both build and scan must pass before staging deploy
 if: github.ref == 'refs/heads/develop'
 # => Only deploys staging from develop branch
 environment:
 # => GitHub environment configuration
 name: staging
 # => Environment name for protection rules
 url: https://staging.example.com
 # => GitHub environment with protection rules
 
 steps:
 # => Staging deployment steps
 - name: Deploy to staging
 # => SSH deploy to staging server
 run: |
 # => Shell commands for staging deployment
 # SSH to staging server and update deployment
 echo "${{ secrets.STAGING_SSH_KEY }}" > staging_key
 # => Write SSH key from secrets to file
 chmod 600 staging_key
 # => Secure key file permissions
 ssh -i staging_key -o StrictHostKeyChecking=no deploy@staging.example.com << 'EOF'
 # => SSH to staging server and run commands
 docker pull ${{ env.REGISTRY }}/${{ env.IMAGE_NAME }}:develop
 # => Pull latest develop image
 docker stop myapp || true
 # => Stop current container (ignore if not running)
 docker rm myapp || true
 # => Remove old container
 docker run -d --name myapp -p 80:3000 \
 # => Start new container
 ${{ env.REGISTRY }}/${{ env.IMAGE_NAME }}:develop
 # => Use newly pulled develop image
 EOF
 
 # Job 4: Deploy to production
 deploy-production:
 # => Deploys to production from version tags
 runs-on: ubuntu-latest
 # => Ubuntu runner for production deployment
 needs: [build-test, security-scan]
 # => Both jobs must pass before production deploy
 if: startsWith(github.ref, 'refs/tags/v')
 # => Only deploys to production from version tags
 environment:
 # => Production environment configuration
 name: production
 # => Production environment with approval gates
 url: https://example.com
 # => Can require manual approval (GitHub environment protection)
 
 steps:
 # => Production deployment steps
 - name: Deploy to production Kubernetes
 # => Kubernetes rolling deployment
 run: |
 # => Commands to update Kubernetes deployment
 echo "${{ secrets.KUBECONFIG }}" > kubeconfig
 # => Write kubeconfig from secrets
 kubectl --kubeconfig=kubeconfig set image \
 # => Update deployment image
 deployment/myapp \
 # => Target deployment name
 app=${{ env.REGISTRY }}/${{ env.IMAGE_NAME }}:${{ github.ref_name }}
 # => Set new image tag from git tag
 kubectl --kubeconfig=kubeconfig rollout status deployment/myapp
 # => Waits for rollout to complete
 
 - name: Create GitHub release
 # => Creates GitHub release for tagged version
 uses: actions/create-release@v1
 # => Official GitHub release action
 env:
 # => Release action environment variables
 GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
 # => Token for creating release
 with:
 # => Release configuration
 tag_name: ${{ github.ref }}
 # => Use triggering git tag
 release_name: Release ${{ github.ref }}
 # => Release title
 draft: false
 # => Publish immediately (not a draft)
 prerelease: false
 # => Creates GitHub release after successful deploy

# Trigger workflow by pushing to main
git add .
# => Stage all changes
git commit -m "feat: add new feature"
# => Commit with conventional commit message
git push origin main
# => Triggers CI/CD pipeline
# => Builds, tests, scans, deploys to staging
 
# Create release tag (triggers production deployment)
git tag -a v1.0.0 -m "Release version 1.0.0"
# => Create annotated version tag
git push origin v1.0.0
# => Triggers production deployment workflow
 
# View workflow runs
# GitHub UI: Actions tab shows all workflow runs
 
# Pull image built by GitHub Actions
docker pull ghcr.io/username/repo:v1.0.0
# => Downloads image from GitHub Container Registry

# File: docker-compose-stack.yml
# Stack deployment with production features
 
version: "3.8"
 
services:
 web:
 image: nginx:alpine
 # => Uses official Nginx Alpine image
 deploy:
 replicas: 3
 # => Creates 3 web service replicas
 update_config:
 parallelism: 1
 # => Updates 1 replica at a time
 delay: 10s
 # => Waits 10s between updates
 failure_action: rollback
 # => Rolls back if update fails
 restart_policy:
 condition: on-failure
 # => Restarts only on failure
 delay: 5s
 # => Waits 5s before restart
 max_attempts: 3
 # => Maximum 3 restart attempts
 placement:
 constraints:
 - node.role == worker
 # => Deploys only on worker nodes
 ports:
 - "8080:80"
 # => Maps port 8080 on host to port 80 in container
 networks:
 - frontend
 # => Connects to frontend overlay network
 
 app:
 image: myapp:latest
 # => Uses custom application image
 deploy:
 replicas: 5
 # => Creates 5 app service replicas
 resources:
 limits:
 cpus: "0.5"
 # => Limits each replica to 0.5 CPU
 memory: 512M
 # => Limits each replica to 512MB RAM
 reservations:
 cpus: "0.25"
 # => Reserves minimum 0.25 CPU
 memory: 256M
 # => Reserves minimum 256MB RAM
 placement:
 preferences:
 - spread: node.labels.datacenter
 # => Spreads replicas across datacenters
 environment:
 DATABASE_URL: postgresql://db:5432/prod
 # => Database connection string
 networks:
 - frontend
 - backend
 # => Connects to both networks
 depends_on:
 - db
 # => Starts after db service (ordering hint)
 
 db:
 image: postgres:15-alpine
 # => Uses PostgreSQL 15 Alpine
 deploy:
 replicas: 1
 # => Single database instance (stateful)
 placement:
 constraints:
 - node.labels.database == true
 # => Deploys only on nodes labeled for database
 restart_policy:
 condition: any
 # => Always restart database
 volumes:
 - db-data:/var/lib/postgresql/data
 # => Persistent database storage
 networks:
 - backend
 # => Only accessible from backend network
 secrets:
 - db_password
 # => Mounts secret as file
 
networks:
 frontend:
 driver: overlay
 # => Creates overlay network for frontend
 backend:
 driver: overlay
 # => Creates overlay network for backend
 
volumes:
 db-data:
 driver: local
 # => Creates local volume for database
 
secrets:
 db_password:
 external: true
 # => References externally created secret

# Create secret before stack deployment
echo "super_secret_password" | docker secret create db_password -
# => Secret created: db_password
# => Secret is encrypted at rest and in transit
 
# Label node for database placement
docker node update --label-add database=true worker1
# => Node worker1 labeled with database=true
 
# Deploy stack
docker stack deploy -c docker-compose-stack.yml myapp
# => Creating network myapp_frontend
# => Creating network myapp_backend
# => Creating service myapp_web
# => Creating service myapp_app
# => Creating service myapp_db
# => Stack deployed successfully
 
# List stacks
docker stack ls
# => NAME SERVICES ORCHESTRATOR
# => myapp 3 Swarm
 
# List stack services
docker stack services myapp
# => ID NAME MODE REPLICAS IMAGE
# => abc123 myapp_web replicated 3/3 nginx:alpine
# => def456 myapp_app replicated 5/5 myapp:latest
# => ghi789 myapp_db replicated 1/1 postgres:15-alpine
 
# Inspect service
docker service inspect myapp_app --pretty
# => ID: def456ghi789
# => Name: myapp_app
# => Mode: Replicated
# => Replicas: 5
# => Placement:
# => Preferences: spread=node.labels.datacenter
# => UpdateConfig:
# => Parallelism: 1
# => Delay: 10s
# => Failure action: rollback
# => Resources:
# => Limits: 0.5 CPUs, 512MB Memory
# => Reservations: 0.25 CPUs, 256MB Memory
 
# View service logs
docker service logs myapp_app --tail 10
# => Shows last 10 log lines from all app replicas
# => [myapp_app.1] Application started on port 3000
# => [myapp_app.2] Application started on port 3000
# => [myapp_app.3] Application started on port 3000
 
# Scale service
docker service scale myapp_app=10
# => myapp_app scaled to 10 replicas
# => Swarm schedules 5 additional tasks
 
# Update service image
docker service update --image myapp:v2 myapp_app
# => myapp_app updated
# => Rolling update: 1 replica at a time
# => Waits 10s between updates
# => Automatically rolls back on failure
 
# Rollback service update
docker service rollback myapp_app
# => myapp_app rolled back to previous version
 
# View stack networks
docker stack ps myapp --filter "desired-state=running"
# => Shows all running tasks in stack
# => ID NAME NODE CURRENT STATE
# => abc123 myapp_web.1 worker1 Running 5 minutes ago
# => def456 myapp_web.2 worker2 Running 5 minutes ago
# => ghi789 myapp_app.1 worker1 Running 5 minutes ago
 
# Remove stack
docker stack rm myapp
# => Removing service myapp_web
# => Removing service myapp_app
# => Removing service myapp_db
# => Removing network myapp_frontend
# => Removing network myapp_backend
# => Stack removed successfully
 
# Remove secret
docker secret rm db_password
# => Secret removed: db_password

# Label nodes for specialized workloads
docker node update --label-add environment=production worker1
# => Label worker1 as production environment
docker node update --label-add gpu=true worker2
# => Label worker2 as having GPU support
docker node update --label-add storage=ssd worker3
# => Label worker3 as having SSD storage
docker node update --label-add datacenter=us-west worker4
# => Label worker4 in us-west datacenter
docker node update --label-add datacenter=us-east worker5
# => Label worker5 in us-east datacenter
# => Labels enable constraint-based placement without hardcoding node names
 
# Create service with role constraint
docker service create \
# => Create Swarm service with role constraint
 --name manager-only \
# => Service name
 --constraint 'node.role == manager' \
# => Only schedule on manager nodes
 nginx:alpine
# => Tasks scheduled only on manager nodes
 
# Create service with label constraint
docker service create \
# => Create Swarm service with label constraint
 --name production-app \
# => Service name
 --constraint 'node.labels.environment == production' \
# => Require production-labeled node
 --replicas 3 \
# => 3 replicas (all on production nodes)
 myapp:latest
# => All 3 replicas scheduled on worker1 (only production-labeled node)
 
# Create GPU service with resource reservation
docker service create \
# => Create GPU-enabled service
 --name ml-training \
# => Service name
 --constraint 'node.labels.gpu == true' \
# => Require GPU node
 --reserve-memory 4G \
# => Reserve 4GB RAM
 --reserve-cpu 4.0 \
# => Reserve 4 CPU cores
 tensorflow/tensorflow:latest-gpu
# => Scheduled on worker2 (GPU node); reserves 4GB RAM and 4 CPUs
 
# Create database service with SSD constraint
docker service create \
# => Create database service with SSD storage requirement
 --name postgres-db \
# => Service name
 --constraint 'node.labels.storage == ssd' \
# => Require SSD-labeled node for performance
 --mount type=volume,source=db-data,target=/var/lib/postgresql/data \
# => Persistent volume mount
 postgres:15-alpine
# => Scheduled on worker3 (SSD node) for better I/O performance
 
# Multiple constraints (AND logic — all must match)
docker service create \
# => Create service with multiple constraints
 --name secure-api \
# => Service name
 --constraint 'node.role == worker' \
# => Must be worker node
 --constraint 'node.labels.environment == production' \
# => Must be production-labeled
 --constraint 'node.labels.datacenter == us-west' \
# => Must be in us-west
 api:latest
# => Must be worker + production + us-west — all constraints required
 
# Constraint with node ID (pins to exact node)
NODE_ID=$(docker node ls -q -f name=worker1)
# => Get node ID for worker1
docker service create \
# => Create service pinned to specific node
 --name pinned-service \
# => Service name
 --constraint "node.id == $NODE_ID" \
# => Pin to exact node ID
 myapp:latest
# => Task pinned to specific worker1 node
 
# OS and Architecture constraints
docker service create --name linux-service \
# => Create Linux-only service
 --constraint 'node.platform.os == linux' alpine:latest
# => Runs only on Linux nodes
 
docker service create --name arm-service \
# => Create ARM64-only service
 --constraint 'node.platform.arch == aarch64' arm64v8/alpine:latest
# => Runs only on ARM64 nodes (useful for mixed-arch clusters)
 
# Spread preference (soft constraint — best-effort distribution)
docker service create \
# => Create service with datacenter spread preference
 --name distributed-app \
# => Service name
 --replicas 6 \
# => 6 replicas to distribute
 --placement-pref 'spread=node.labels.datacenter' \
# => Spread evenly across datacenters
 myapp:latest
# => 3 replicas on us-west nodes, 3 on us-east nodes
# => Unlike hard constraints, spread is best-effort (won't block if imbalanced)
 
# Combine constraints (hard) and preferences (soft)
docker service create \
# => Create HA service with SSD constraint and spread preference
 --name ha-database \
# => Service name
 --replicas 3 \
# => 3 replicas
 --constraint 'node.labels.storage == ssd' \
# => Hard constraint: must be SSD
 --placement-pref 'spread=node.labels.datacenter' \
# => Soft preference: spread across datacenters
 postgres:15-alpine
# => Must be SSD node (hard) + spread across datacenters (soft)
 
# Inspect service placement
docker service ps distributed-app
# => distributed-app.1 worker4 Running | distributed-app.2 worker5 Running
# => distributed-app.3 worker4 Running | distributed-app.4 worker5 Running
 
# Update and remove constraints live
docker service update --constraint-add 'node.labels.environment == staging' production-app
# => Adds constraint — existing tasks re-scheduled if they don't match
 
docker service update --constraint-rm 'node.labels.environment == staging' production-app
# => Removes constraint
 
# View and remove node labels
docker node inspect worker1 --format '{{.Spec.Labels}}'
# => map[datacenter:us-west environment:production]
 
docker node update --label-rm environment worker1
# => Label environment removed from worker1

# Create service with health check and update/rollback config
docker service create \
# => Create Swarm service with health check and update config
 --name web-app \
# => Service name
 --replicas 5 \
# => Run 5 replica tasks across swarm
 --health-cmd "curl -f http://localhost/health || exit 1" \
# => Health check command (exit 1 = unhealthy)
 --health-interval 10s \
# => Run health check every 10 seconds
 --health-timeout 5s \
# => Health check times out after 5 seconds
 --health-retries 3 \
# => Mark unhealthy after 3 consecutive failures
 --update-parallelism 1 \
# => Update 1 replica at a time
 --update-delay 10s \
# => Wait 10s between updating each batch
 --update-failure-action rollback \
# => Auto-rollback on update failure
 --rollback-parallelism 2 \
# => Rollback 2 replicas at a time (faster recovery)
 --rollback-delay 5s \
# => Wait 5s between rollback batches
 myapp:v1
# => Health check: curl /health every 10s, fails after 3 consecutive misses
# => Update: 1 task at a time, 10s delay, auto-rollback on failure
# => Rollback: 2 tasks at a time (2x faster recovery than update)
 
# Verify service is running
docker service ps web-app
# => web-app.1 myapp:v1 worker1 Running (healthy)
# => web-app.2 myapp:v1 worker2 Running (healthy)
# => All 5 replicas healthy before update
 
# Perform rolling update to v2
docker service update --image myapp:v2 web-app
# => Stops web-app.1, starts it with myapp:v2, waits for health check pass
# => Waits 10s delay, then proceeds to web-app.2, and so on
 
# Monitor update progress
docker service ps web-app
# => web-app.1  myapp:v2 worker1 Running (healthy)    ← new version
# => \_ web-app.1 myapp:v1 worker1 Shutdown 2m ago  ← previous task
 
# Simulate failed update (v3 has failing health check)
docker service update --image myapp:v3-broken web-app
# => Health check fails 3 consecutive times on web-app.1
# => Automatic rollback triggered — reverts to myapp:v2
# => Rollback runs 2 tasks at a time (faster than original update)
 
# Check service after failed update
docker service ps web-app --filter "desired-state=running"
# => All 5 replicas back on myapp:v2 (v3-broken in shutdown state)
 
# Manual rollback to previous version
docker service rollback web-app
# => Reverts to previous spec (myapp:v1)
 
# Update with custom batch settings
docker service update \
 --image myapp:v4 \
 --update-parallelism 2 \
 --update-delay 30s \
 --update-max-failure-ratio 0.2 \
 --update-monitor 60s \
 web-app
# => 2 tasks at a time, 30s delay, rollback if >20% fail, monitor 60s each
 
# Pause update mid-rollout
docker service update --update-parallelism 0 web-app
# => Pauses update — existing tasks keep running, no new tasks start
 
# Resume update
docker service update --image myapp:v4 --update-parallelism 1 web-app
# => Resumes at parallelism 1
 
# Force update (recreate all tasks even with same image)
docker service update --force web-app
# => Useful for picking up config/secret changes without image change
 
# start-first order: new task starts before old task stops
docker service update --image myapp:v5 --update-order start-first web-app
# => Maintains full capacity during update (stateless services only)
# => Default --update-order stop-first is safer for stateful services
 
# Inspect update config
docker service inspect web-app --format '{{.Spec.UpdateConfig}}'
# => {1 10s 0s 0.2 pause 60s start-first}
# => Parallelism:1, Delay:10s, MaxFailureRatio:0.2, Monitor:60s
 
# Configure global swarm update defaults
docker swarm update --task-history-limit 10 --dispatcher-heartbeat 10s
# => Retains 10 previous task versions for rollback history

# Create a service with initial replica count
docker service create   --name web-app   --replicas 3   --publish 80:3000   nginx:alpine
# => Service web-app created with 3 replicas
# => Scheduler distributes tasks across available worker nodes
 
# Verify initial deployment
docker service ps web-app
# => web-app.1  nginx:alpine  worker1  Running
# => web-app.2  nginx:alpine  worker2  Running
# => web-app.3  nginx:alpine  worker3  Running
 
# Scale up to handle increased load
docker service scale web-app=10
# => web-app scaled to 10
# => Scheduler places 7 additional tasks on available nodes
 
# Verify scaled service
docker service ps web-app
# => 10 tasks distributed across all worker nodes
# => Ingress routing mesh automatically load-balances incoming requests
 
# Scale multiple services simultaneously
docker service scale web-app=6 api-service=4 cache=2
# => web-app scaled to 6
# => api-service scaled to 4
# => cache scaled to 2
 
# Check service status after scaling
docker service ls
# => web-app    replicated   6/6   nginx:alpine   *:80->3000/tcp
# => api-service replicated  4/4   myapi:latest
# => cache      replicated   2/2   redis:alpine
 
# Scale down (graceful — tasks stop after current requests complete)
docker service scale web-app=3
# => web-app scaled to 3
# => Scheduler removes excess tasks, stopping 3 containers
 
# Inspect service for resource and replica details
docker service inspect web-app --pretty
# => Replicas: 3
# => Update Config: Parallelism=1, Delay=10s
# => Endpoint Mode: vip
 
# Monitor real-time scaling events
docker service ps web-app --filter "desired-state=running"
# => Lists only currently running tasks (excludes shutdown history)

# Create service with explicit update and rollback configuration
docker service create   --name critical-api   --replicas 6   --update-parallelism 1 # => Update 1 replica at a time (safest for critical services)
  --update-delay 20s # => Wait 20 seconds between each updated task
  --update-failure-action rollback # => Automatically rollback entire service on failure
  --update-monitor 30s # => Monitor each task for 30s after start before proceeding
  --update-max-failure-ratio 0.1 # => Rollback if more than 10% of tasks fail health checks
  --rollback-parallelism 3 # => Rollback 3 replicas at a time (3x faster than update)
  --rollback-delay 5s # => 5s between rollback batches (faster recovery)
  --rollback-failure-action continue # => Continue rollback even if some tasks fail to stop
  myapi:v1
# => Service created with conservative update strategy for critical API
 
# Deploy new version — rolling update proceeds task by task
docker service update --image myapi:v2 critical-api
# => Updating task 1/6: stop old, start new, wait health, wait 20s
# => Updating task 2/6: same process
# => If task fails health check within 30s monitor window → trigger rollback
 
# Accelerate update for non-critical services
docker service update   --image worker:v2   --update-parallelism 3   --update-delay 5s   --update-order start-first   batch-worker
# => Updates 3 tasks simultaneously (3x faster than sequential)
# => start-first: new task starts before old stops (maintains capacity)
# => Suitable for stateless workers where brief overcapacity is acceptable
 
# Check update status during rollout
docker service ps critical-api
# => critical-api.1  myapi:v2  worker1  Running   3 minutes ago
# => critical-api.2  myapi:v2  worker2  Running   1 minute ago
# => critical-api.3  myapi:v1  worker3  Running   10 minutes ago ← still updating
# => \_ critical-api.3 myapi:v1 worker3  Shutdown  2 minutes ago
 
# Force redeployment without image change (picks up config or secret changes)
docker service update --force critical-api
# => Recreates all tasks even with identical image
# => Necessary when secrets or configs are updated externally
 
# Inspect current update configuration
docker service inspect critical-api --format '{{json .Spec.UpdateConfig}}' | jq
# => {"Parallelism":1,"Delay":20000000000,"FailureAction":"rollback","Monitor":30000000000,"MaxFailureRatio":0.1,"Order":"stop-first"}

# Create secrets from files (preferred — avoids shell history exposure)
echo "supersecretpassword" | docker secret create db_password -
# => Secret db_password created
# => Encrypted and stored in Raft consensus store
 
# Create secret from file
docker secret create ssl_cert ./certs/server.crt
# => Secret ssl_cert created from file
 
# Create secret from environment variable (CI/CD pipeline pattern)
echo "$DB_PASSWORD" | docker secret create db_password -
# => Reads from environment, never touches disk
 
# List available secrets (values never displayed)
docker secret ls
# => ID                  NAME          CREATED       UPDATED
# => abc123def456        db_password   2 minutes ago  2 minutes ago
# => xyz789uvw012        ssl_cert      1 minute ago   1 minute ago
 
# Create service with secrets mounted at /run/secrets/<name>
docker service create   --name postgres   --secret db_password   --secret ssl_cert   -e POSTGRES_PASSWORD_FILE=/run/secrets/db_password # => Reads password from secret file, not environment variable
  postgres:15-alpine
# => Container accesses /run/secrets/db_password at runtime
# => File visible only inside container, not in image or env
 
# Verify secret is accessible inside container
docker exec $(docker ps -q -f name=postgres) cat /run/secrets/db_password
# => supersecretpassword
# => File owned by root, mode 0400 (read-only)
 
# Rotate a secret (zero-downtime rotation)
echo "newpassword123" | docker secret create db_password_v2 -
# => New secret version created
 
docker service update   --secret-rm db_password   --secret-add db_password_v2   postgres
# => Removes old secret, adds new secret
# => Rolling update replaces tasks with updated secret access
 
# Delete old secret after rotation
docker secret rm db_password
# => Removed from Raft store permanently
 
# Inspect secret metadata (value is never retrievable)
docker secret inspect db_password_v2
# => {"ID":"xyz","Spec":{"Name":"db_password_v2"},"CreatedAt":"..."}
# => Secret value is never exposed through API or CLI

# Create encrypted overlay network for production services
docker network create   --driver overlay # => Overlay driver creates multi-host virtual network
  --subnet 10.0.9.0/24 # => Custom CIDR block for this network segment
  --opt encrypted # => Enables IPsec encryption of container-to-container traffic
  --attachable # => Allows standalone containers (non-Swarm) to attach for debugging
  production-net
# => Network spans all Swarm nodes automatically
 
# Create internal backend network (no external routing)
docker network create   --driver overlay   --internal # => No external network access — backend services only
  --subnet 10.0.10.0/24   backend-net
# => Database and cache tier with no internet access
 
# Deploy frontend connected to production and backend networks
docker service create   --name frontend   --replicas 3   --network production-net # => External traffic reaches frontend through ingress
  --publish 443:8443   myapp-frontend:latest
# => Frontend accessible externally via port 443
 
# Deploy API connected to both networks
docker service create   --name api   --replicas 4   --network production-net # => Receives requests from frontend
  --network backend-net # => Accesses database through isolated backend network
  myapp-api:latest
# => API bridges external and internal network segments
 
# Deploy database on internal network only
docker service create   --name postgres   --replicas 1   --network backend-net # => Only reachable from backend-net (not from internet)
  postgres:15-alpine
# => Database completely isolated from external networks
 
# Inspect network to see connected services and endpoints
docker network inspect production-net
# => "Containers": {"frontend", "api"} with assigned IPs
# => "Peers": [worker1:..., worker2:..., worker3:...] (all nodes in overlay)
 
# List all overlay networks
docker network ls --filter driver=overlay
# => NETWORK ID   NAME            DRIVER  SCOPE
# => abc123       production-net  overlay swarm
# => def456       backend-net     overlay swarm
# => ingress      ingress         overlay swarm (built-in)
 
# Remove unused networks after service removal
docker network rm backend-net
# => Error: network backend-net has active endpoints
# => Must remove dependent services first: docker service rm postgres api

# Create service with comprehensive health check configuration
docker service create   --name web-api   --replicas 4   --health-cmd "curl -f http://localhost:8080/health || exit 1" # => Health check command: HTTP GET /health, exit 1 if fails
  --health-interval 15s # => Run health check every 15 seconds
  --health-timeout 5s # => Health check must complete within 5 seconds
  --health-retries 3 # => Mark unhealthy after 3 consecutive failures (45s total)
  --health-start-period 30s # => Grace period after container start before health checks count
# => Allows slow-starting apps to initialize without being killed
  --restart-condition any # => Restart on any exit (including success — keep running)
  --restart-delay 5s # => Wait 5s before restarting (backoff prevents restart storms)
  --restart-max-attempts 3 # => Stop trying after 3 failed restart attempts
  --restart-window 120s # => Reset failure counter if task runs healthy for 120s
  myapi:latest
# => Task marked unhealthy after 3 consecutive health check failures
# => Swarm replaces unhealthy task automatically on healthy node
 
# Verify health status of running tasks
docker service ps web-api
# => web-api.1  myapi:latest  worker1  Running (healthy)   5 min ago
# => web-api.2  myapi:latest  worker2  Running (healthy)   5 min ago
# => web-api.3  myapi:latest  worker3  Running (starting)  30 sec ago (in start period)
# => web-api.4  myapi:latest  worker1  Running (healthy)   5 min ago
 
# Simulate unhealthy container
docker exec $(docker ps -q -f name=web-api.2) kill -STOP 1
# => Container process paused — health check fails
# => After 3 failures (45s): task marked unhealthy
# => Swarm scheduler immediately starts replacement task on available node
# => Old unhealthy task moved to Shutdown state
 
# Check replacement
docker service ps web-api
# => web-api.2   myapi:latest  worker3  Running (starting) 30 sec ago  ← replacement
# => \_ web-api.2  myapi:latest  worker2  Shutdown           2 min ago  ← replaced
 
# Update health check on running service
docker service update   --health-interval 10s   --health-retries 2   --health-start-period 60s   web-api
# => Updated health check configuration
# => Rolling restart applies new health settings to all tasks
 
# Configure restart policy for batch workers (run-once tasks)
docker service create   --name data-processor   --replicas 2   --restart-condition on-failure # => Only restart on non-zero exit code (not on success)
  --restart-max-attempts 5 # => Give batch jobs 5 attempts before marking as failed
  myworker:latest
# => Worker restarts on crash but stops after completing successfully
 
# Inspect health check configuration
docker service inspect web-api --format '{{json .Spec.TaskTemplate.ContainerSpec.Healthcheck}}' | jq
# => {"Test":["CMD-SHELL","curl -f http://localhost:8080/health || exit 1"],"Interval":15000000000,"Timeout":5000000000,"Retries":3,"StartPeriod":30000000000}

# File: docker-compose.yml
 
version: "3.8"
# => Distributed tracing stack Compose file
# => Four-service application with OpenTelemetry + Jaeger
 
services:
# => Service definitions: one observability + three app services
# => Jaeger all-in-one (dev/testing)
 jaeger:
 # => All-in-one Jaeger for development/testing
 # => Combines collector, agent, query, UI in one container
 image: jaegertracing/all-in-one:latest
 # => Single container with collector, agent, query, UI
 # => Not recommended for production (use separate services)
 environment:
 # => Jaeger environment variables
 COLLECTOR_ZIPKIN_HOST_PORT: :9411
 # => Enables Zipkin compatibility for legacy apps
 # => B3 headers and Zipkin spans both accepted
 ports:
 # => All Jaeger ports for different protocols
 - "5775:5775/udp" # Compact thrift (deprecated)
 # => Legacy compact thrift protocol (deprecated)
 # => Use 6831 for new applications
 - "6831:6831/udp" # Jaeger thrift (binary)
 # => Primary port for instrumented services to send spans
 # => UDP: fire-and-forget (low overhead)
 - "6832:6832/udp" # Jaeger thrift (compact)
 # => Jaeger thrift compact format
 - "5778:5778" # Serve configs
 # => Config server for agent sampling strategies
 # => Adaptive sampling rates served here
 - "16686:16686" # Jaeger UI
 # => Open http://localhost:16686 to view traces
 # => Search, filter, and compare traces here
 - "14250:14250" # Jaeger gRPC
 # => gRPC collector endpoint for modern clients
 # => Used by OpenTelemetry SDK (preferred)
 - "14268:14268" # Jaeger HTTP
 # => HTTP collector endpoint
 # => Alternative to gRPC for firewalls blocking gRPC
 - "9411:9411" # Zipkin compatible endpoint
 # => Accept Zipkin B3 format spans
 # => Drop-in replacement for Zipkin collectors
 
 # Application with tracing
 web:
 # => Frontend web service with tracing
 build: ./web
 # => Build from ./web directory
 # => Expects Dockerfile in ./web/
 environment:
 # => Tracing configuration environment variables
 JAEGER_AGENT_HOST: jaeger
 # => Docker DNS resolves "jaeger" to Jaeger container IP
 # => Service name "jaeger" auto-resolves in same network
 JAEGER_AGENT_PORT: 6831
 # => Standard Jaeger agent port
 # => UDP port for span batches
 depends_on:
 # => Service start order
 - jaeger
 # => Jaeger must start before applications send traces
 # => Without Jaeger, spans would be dropped
 ports:
 # => Web service port binding
 - "3000:3000"
 # => Web service HTTP port
 # => Access via http://localhost:3000
 
 auth:
 # => Authentication service with tracing
 build: ./auth
 # => Build from ./auth directory
 environment:
 # => Auth service tracing config
 JAEGER_AGENT_HOST: jaeger
 # => All services point to same Jaeger instance
 # => Traces from auth linked to web traces via context propagation
 JAEGER_AGENT_PORT: 6831
 # => Same port for all services
 depends_on:
 # => Auth startup dependency
 - jaeger
 # => Jaeger must be available for auth service
 
 user-service:
 # => User data service with tracing
 build: ./user-service
 # => Build from ./user-service directory
 environment:
 # => User service tracing config
 JAEGER_AGENT_HOST: jaeger
 # => Same Jaeger agent for all services
 # => Context propagation links user-service spans to web spans
 JAEGER_AGENT_PORT: 6831
 # => Standard Jaeger agent UDP port
 depends_on:
 # => User service startup dependency
 - jaeger
 # => All services send traces to same Jaeger instance

// File: web/tracing.js (Node.js/OpenTelemetry)
const { NodeTracerProvider } = require("@opentelemetry/sdk-trace-node");
// => OpenTelemetry Node.js SDK tracer provider
const { JaegerExporter } = require("@opentelemetry/exporter-jaeger");
// => Jaeger-specific span exporter
const { Resource } = require("@opentelemetry/resources");
// => Resource defines service metadata
const { SemanticResourceAttributes } = require("@opentelemetry/semantic-conventions");
// => Standard attribute names (SERVICE_NAME, etc.)
const { registerInstrumentations } = require("@opentelemetry/instrumentation");
// => Registers auto-instrumentation plugins
const { HttpInstrumentation } = require("@opentelemetry/instrumentation-http");
// => Auto-instruments HTTP module
const { ExpressInstrumentation } = require("@opentelemetry/instrumentation-express");
// => Auto-instruments Express framework
 
// Create tracer provider
const provider = new NodeTracerProvider({
  // => Configure global tracer with resource metadata
  resource: new Resource({
    // => Resource attributes identify this service
    [SemanticResourceAttributes.SERVICE_NAME]: "web-service",
    // => Service name shown in Jaeger UI trace search
    [SemanticResourceAttributes.SERVICE_VERSION]: "1.0.0",
    // => Service version for correlating traces with deployments
  }),
});
// => Provider created with service identification
 
// Configure Jaeger exporter
const jaegerExporter = new JaegerExporter({
  // => Configure span export to Jaeger
  endpoint: `http://${process.env.JAEGER_AGENT_HOST}:14268/api/traces`,
  // => Sends spans to Jaeger collector HTTP endpoint
});
// => Exporter configured with Jaeger endpoint
 
provider.addSpanProcessor(new SimpleSpanProcessor(jaegerExporter));
// => Sends each span immediately (use BatchSpanProcessor in production)
provider.register();
// => Registers provider as global tracer
 
// Auto-instrument HTTP and Express
registerInstrumentations({
  // => Register auto-instrumentation plugins
  instrumentations: [new HttpInstrumentation(), new ExpressInstrumentation()],
  // => Automatically creates spans for all HTTP requests/responses
});
// => All HTTP and Express calls now auto-traced
 
// Manual span creation
const tracer = provider.getTracer("web-service");
// => Get named tracer for manual span creation
 
app.get("/api/users/:id", async (req, res) => {
  // => Express route handler with distributed tracing
  const span = tracer.startSpan("get-user");
  // => Creates span; appears in Jaeger as child of HTTP span
  span.setAttribute("user.id", req.params.id);
  // => Adds queryable attribute to span
 
  try {
    // => Try block ensures span.end() is always called
    // Call auth service (auto-traced)
    const authResult = await fetch("http://auth/verify", {
      // => HTTP call to auth service
      headers: {
        // => Pass request headers for trace propagation
        authorization: req.headers.authorization,
        // => Forward authorization header
      },
    });
    // => HTTP instrumentation auto-propagates trace context headers
 
    // Call user service
    const userResult = await fetch(`http://user-service/users/${req.params.id}`);
    // => Creates child span in user-service trace
 
    span.setStatus({ code: SpanStatusCode.OK });
    // => Mark span as successful
    res.json(await userResult.json());
    // => Return user data
  } catch (error) {
    // => Error handling with span recording
    span.setStatus({
      // => Set span status to error
      code: SpanStatusCode.ERROR,
      // => Error code for Jaeger error detection
      message: error.message,
      // => Error status shows red in Jaeger timeline
    });
    span.recordException(error);
    // => Attaches stack trace to span for debugging
    res.status(500).json({ error: error.message });
    // => Return error response
  } finally {
    // => Always executes, even on error
    span.end();
    // => Must end span to send to Jaeger (memory leak if forgotten)
  }
});

# Start services
docker compose up -d
# => Starts jaeger, web, auth, user-service containers
# => Wait ~10s for Jaeger to initialize before sending traces
# => All 4 containers start in order: jaeger first, then apps
# => docker compose logs -f to watch startup
 
# Access Jaeger UI
# => http://localhost:16686
# => Jaeger web interface for trace visualization
# => Shows services, operations, traces, and dependencies
# => First-time: select "web-service" from "Service" dropdown
# => Click "Find Traces" to see recent requests
# => Dependencies tab shows service topology graph
 
# Generate trace data
curl http://localhost:3000/api/users/123
# => Sends request that creates spans across all three services
# => Trace propagated via HTTP headers (traceparent, x-b3-traceid)
# => Each service creates child spans automatically
# => Trace ID logged by each service for correlation
# => Expected response: {"id": "123", "name": "Alice", ...}
 
# View trace in Jaeger UI:
# => Service: web-service
# => Operation: GET /api/users/:id
# => Trace timeline showing:
# => - web-service: GET /api/users/:id (50ms total)
# => - auth-service: /verify (10ms)
# => - user-service: /users/123 (35ms)
# => - database: SELECT (30ms) ← Bottleneck identified!
# => Click on span to see tags: user.id, http.status_code, etc.
# => Red spans indicate errors (span.status = ERROR)
# => Use timeline to identify slowest spans
# => Span attributes available: http.method, http.url, db.statement
# => baggage allows passing metadata across service boundaries
# => Traces correlate all requests for a single user action
# => Jaeger shows service dependency graph automatically
# => Use "Compare" to spot performance regressions between versions
 
# Query traces programmatically
curl 'http://localhost:16686/api/traces?service=web-service&limit=10'
# => Returns JSON with recent traces
# => Useful for automated performance regression testing
# => Filter by: service, operation, tags, duration, start time
# => Example filter: ?tags={"error":"true"} finds error traces
# => minDuration/maxDuration filters by trace duration
# => Use Jaeger API to build custom dashboards and alerts
# => Integrate with Prometheus: jaeger_span_exported_total metric
 
# Production deployment (Elasticsearch backend)
cat > docker-compose.prod.yml << 'EOF'
# => Creates production Jaeger with Elasticsearch backend
# => Separates collector, query, and storage for scalability
version: '3.8'
# => Compose format version
# => Use with: docker stack deploy for Swarm
 
services:
# => Three services: elasticsearch, jaeger-collector, jaeger-query
# => Unlike all-in-one, each component scales independently
 elasticsearch:
 # => Elasticsearch for long-term span storage
 # => Stores millions of spans efficiently
 image: docker.elastic.co/elasticsearch/elasticsearch:7.17.0
 # => Stores spans long-term (days/weeks of history)
 # => Index pattern: jaeger-span-YYYY-MM-DD
 environment:
 # => Elasticsearch startup config
 - discovery.type=single-node
 # => Single node for simplicity (use cluster in production)
 # => For production: 3+ nodes for HA
 volumes:
 # => Persistent storage for trace data
 - es-data:/usr/share/elasticsearch/data
 # => Persists all trace data across restarts
 # => Index retention: configure ILM policies separately
 
 jaeger-collector:
 # => Dedicated collector for production scale
 # => Multiple replicas can handle high span throughput
 image: jaegertracing/jaeger-collector:latest
 # => Receives spans from agents and stores in Elasticsearch
 # => Can scale horizontally for high volume
 environment:
 # => Collector storage configuration
 SPAN_STORAGE_TYPE: elasticsearch
 # => Use ES instead of in-memory storage
 # => In-memory (all-in-one) loses data on restart
 ES_SERVER_URLS: http://elasticsearch:9200
 # => Elasticsearch REST API endpoint
 # => Use comma-separated list for ES cluster
 ports:
 # => Collector ingestion ports
 - "14250:14250"
 # => gRPC port for span ingestion
 # => Preferred by OpenTelemetry SDK
 - "14268:14268"
 # => HTTP port for span ingestion
 # => Fallback for environments blocking gRPC
 depends_on:
 # => Collector needs ES before receiving spans
 - elasticsearch
 # => ES must be ready before collector starts
 # => Collector will retry ES connection
 
 jaeger-query:
 # => Query service for Jaeger UI
 # => Reads from ES, serves UI and API
 image: jaegertracing/jaeger-query:latest
 # => Serves Jaeger UI and query API
 # => Stateless: multiple replicas possible
 environment:
 # => Query service storage configuration
 SPAN_STORAGE_TYPE: elasticsearch
 # => Read spans from Elasticsearch
 # => Same storage backend as collector
 ES_SERVER_URLS: http://elasticsearch:9200
 # => Same ES cluster as collector
 # => Query reads same indices as collector writes
 ports:
 # => UI port binding
 - "16686:16686"
 # => Jaeger UI accessible at http://localhost:16686
 # => Also serves /api/* for programmatic access
 depends_on:
 # => Query needs ES before serving data
 - elasticsearch
 # => ES must have data before queries work
 
volumes:
# => Named volume for persistence
 es-data:
 # => Persistent Elasticsearch storage
 # => Data survives container restarts
EOF
# => Production Jaeger Compose file created
# => Deploy: docker compose -f docker-compose.prod.yml up -d
# => Scale collector: docker compose scale jaeger-collector=3
# => Scale query: docker compose scale jaeger-query=2
# => Use Kubernetes for production orchestration
# => Monitor ES indices: curl http://es:9200/_cat/indices
# => Default index TTL: configure with ILM policy
# => Typical storage: ~1KB per span, millions per day
# => Memory requirement: ES needs 8GB+ RAM in production
# => CPU: collector 0.5 cores, query 0.2 cores per instance
# => Network: collector → ES writes, query → ES reads
# => Backup: snapshot ES indices regularly
# => Upgrade: rolling upgrades supported for ES + Jaeger
# => Alerting: alert on jaeger_span_exported_total drop
# => SLA: Jaeger typically adds <1ms latency to requests
# => Context propagation: W3C TraceContext (default) or B3
# => Sampling: start with 10% head-based, tune later
# => Feature flags: SAMPLING_STRATEGIES_FILE for custom rates
# => Agent vs SDK: prefer SDK direct export over agent in k8s
# => OpenTelemetry Collector: alternative to Jaeger agent

# Check AppArmor status
sudo aa-status | grep docker
# => docker-default (enforce)
# => Shows active Docker AppArmor profile
 
# View default Docker AppArmor profile
cat /etc/apparmor.d/docker
# => # Default Docker profile
# => #include <tunables/global>
# => profile docker-default flags=(attach_disconnected,mediate_deleted) {
# => #include <abstractions/base>
# => deny @{PROC}/* w, # deny write to /proc
# => deny /sys/[^f]** wklx,
# => ..
# => }
 
# Create custom AppArmor profile
sudo tee /etc/apparmor.d/docker-nginx << 'EOF'
#include <tunables/global>
 
profile docker-nginx flags=(attach_disconnected,mediate_deleted) {
# => Define docker-nginx AppArmor profile
 #include <abstractions/base>
 
 # Allow network access
 network inet tcp,
# => Allow TCP connections (HTTP)
 network inet udp,
# => Allow UDP (for DNS, etc.)
 
 # Allow reading nginx files
 /etc/nginx/** r,
# => Read all nginx configuration files
 /var/www/** r,
# => Read web content directory
 /usr/share/nginx/** r,
# => Read nginx static files
 
 # Allow writing logs
 /var/log/nginx/** w,
# => Write access log and error log
 
 # Allow executing nginx
 /usr/sbin/nginx ix,
# => Execute nginx binary (ix = inherit execute)
 
 # Deny everything else
 deny /proc/** w,
# => Prevent writing to /proc (kernel info)
 deny /sys/** w,
# => Prevent writing to /sys (hardware)
 deny /root/** rwx,
# => No access to root home directory
 deny /home/** rwx,
# => No access to any user home directories
}
# => AppArmor profile complete
EOF
# => AppArmor profile written to file
 
# Load AppArmor profile
sudo apparmor_parser -r -W /etc/apparmor.d/docker-nginx
# => -r: reload profile, -W: wait for load
# => Profile loaded
 
# Verify profile loaded
sudo aa-status | grep docker-nginx
# => docker-nginx (enforce)
 
# Run container with custom AppArmor profile
docker run -d \
# => Start nginx container with AppArmor profile
 --name secure-nginx \
# => Container name
 --security-opt apparmor=docker-nginx \
# => Apply our custom docker-nginx AppArmor profile
 -v $(pwd)/html:/var/www:ro \
# => Mount web content read-only
 nginx:alpine
# => Container runs with docker-nginx AppArmor profile
 
# Test restrictions
docker exec secure-nginx sh -c 'echo test > /root/test.txt'
# => sh: can't create /root/test.txt: Permission denied
# => AppArmor denies write to /root
 
docker exec secure-nginx sh -c 'cat /etc/nginx/nginx.conf'
# => (file contents displayed)
# => AppArmor allows reading nginx configs
 
# Monitor AppArmor denials
sudo dmesg | grep DENIED | tail -5
# => [12345.678] audit: type=1400 audit(1234567890.123:456): apparmor="DENIED" operation="open" profile="docker-nginx" name="/root/test.txt" requested_mask="wc"
# => Shows blocked operations
 
# Disable AppArmor for container (not recommended)
docker run -d \
# => Start container without AppArmor
 --security-opt apparmor=unconfined \
# => Disable AppArmor enforcement
 nginx:alpine
# => Runs without AppArmor protection (insecure)
 
# Docker Compose with AppArmor
cat > docker-compose.yml << 'EOF'
# => Create Docker Compose with AppArmor configuration
version: '3.8'
# => Compose format version
 
services:
# => Service definitions
 web:
# => Nginx web service with AppArmor
 image: nginx:alpine
# => Nginx Alpine image
 security_opt:
# => Security options
 - apparmor:docker-nginx
# => Apply custom docker-nginx profile
 volumes:
# => Volume mounts
 - ./html:/var/www:ro
# => Web content read-only
EOF
# => End of docker-compose.yml heredoc
 
# Advanced: Generate AppArmor profile from container behavior
# Install aa-genprof
sudo apt-get install apparmor-utils
# => Install AppArmor profile management tools
 
# Run container in complain mode (log only, don't enforce)
docker run -d --name nginx-learn \
# => Start container for learning mode
 --security-opt apparmor=docker-nginx \
# => Apply profile (can also use apparmor=complain for log-only mode)
 nginx:alpine
# => Container runs, all denials logged but allowed
 
# Generate profile from logs
sudo aa-logprof
# => Analyzes denials and suggests profile updates
# => Interactive tool to refine AppArmor policies

{
  "defaultAction": "SCMP_ACT_ERRNO",
  "architectures": ["SCMP_ARCH_X86_64", "SCMP_ARCH_X86", "SCMP_ARCH_ARM", "SCMP_ARCH_AARCH64"],
  "syscalls": [
    {
      "names": [
        "accept",
        "accept4",
        "access",
        "arch_prctl",
        "bind",
        "brk",
        "chdir",
        "clone",
        "close",
        "connect",
        "dup",
        "dup2",
        "epoll_create",
        "epoll_create1",
        "epoll_ctl",
        "epoll_wait",
        "execve",
        "exit",
        "exit_group",
        "fcntl",
        "fstat",
        "futex",
        "getcwd",
        "getdents",
        "getpid",
        "getppid",
        "getuid",
        "ioctl",
        "listen",
        "lseek",
        "mmap",
        "mprotect",
        "munmap",
        "open",
        "openat",
        "pipe",
        "poll",
        "read",
        "readlink",
        "recvfrom",
        "recvmsg",
        "rt_sigaction",
        "rt_sigprocmask",
        "rt_sigreturn",
        "select",
        "sendmsg",
        "sendto",
        "set_robust_list",
        "setsockopt",
        "socket",
        "stat",
        "write"
      ],
      "action": "SCMP_ACT_ALLOW",
      "comment": "Minimal syscall allowlist for web server container"
    },
    {
      "names": ["reboot"],
      "action": "SCMP_ACT_ERRNO",
      "comment": "Block reboot syscall - prevents host reboot from container"
    }
  ]
}