Specialist in Docker, container runtimes, image management, and containerization technologies. Expert in building optimized, secure container images and managing container infrastructure at scale.
Expert in building optimized, secure container images and managing container infrastructure. Specializes in Dockerfile optimization, multi-stage builds, image scanning with Trivy/Grype, and registry operations. Helps with vulnerability management, multi-architecture builds, and production-ready containerization across Docker, containerd, and CRI-O runtimes.
/plugin marketplace add pluginagentmarketplace/custom-plugin-kubernetes/plugin install kubernetes-assistant@pluginagentmarketplace-kubernetessonnetProfessional containerization and image management covering the complete lifecycle from Dockerfile design through production deployment. This agent provides deep expertise in building efficient, secure, and maintainable container images while managing container infrastructure at enterprise scale.
Dockerfile Structure Evolution
Layer Optimization Strategy
# ❌ ANTI-PATTERN: Many layers, large intermediate
FROM ubuntu:20.04
RUN apt-get update && apt-get install -y nodejs npm git curl wget
RUN useradd appuser
RUN npm install -g yarn
COPY . /app
WORKDIR /app
RUN npm install
RUN npm build
# ✅ PATTERN: Minimal layers, efficient
FROM node:18-alpine as builder
WORKDIR /build
COPY package*.json ./
RUN npm ci --only=production
FROM gcr.io/distroless/nodejs18-debian11:nonroot
COPY --from=builder /build/node_modules /app/node_modules
COPY --chown=nonroot:nonroot . /app
WORKDIR /app
EXPOSE 3000
CMD ["server.js"]
Key Optimization Principles
Size Reduction Examples
Runtime Options Comparison
| Runtime | Size | Speed | Security | Kubernetes | Use Case |
|---|---|---|---|---|---|
| Docker | 100MB+ | Standard | Good | Via Docker | Dev, testing |
| containerd | 20MB | Fast | Excellent | Native | Production |
| CRI-O | 15MB | Fast | Excellent | Native | Production, CNCF |
| Kata | 50MB | Slower | Superior | Plugin | Multi-tenant |
| gVisor | 30MB | Slower | Superior | Plugin | Untrusted |
containerd Configuration
# /etc/containerd/config.toml
[plugins."io.containerd.grpc.v1.cri".registry.mirrors."docker.io"]
endpoint = ["https://mirror.gcr.io"]
[plugins."io.containerd.grpc.v1.cri".registry.auths."private-registry.com"]
auth = "base64-encoded-credentials"
[plugins."io.containerd.grpc.v1.cri".containerd.runtimes.runc]
runtime_engine = "runc"
runtime_root = ""
CRI-O Configuration
# /etc/crio/crio.conf
[crio.runtime]
manage_network_ns_lifecycle = true
pause_image = "k8s.gcr.io/pause:3.6"
[crio.image]
registries = ["docker.io", "gcr.io", "quay.io"]
Runtime Selection Decision Tree
Image Naming Convention
registry.example.com/namespace/repository:tag
├── registry: Where image stored (docker.io, gcr.io, ecr.aws, acr.azurecr.io)
├── namespace: Organization (mycompany, team-name, public)
├── repository: App name (api-server, auth-service, web-ui)
└── tag: Version identifier (v1.2.3, sha256:abc123..., latest)
Image Tagging Strategy - Production
# Semantic Versioning (recommended)
registry.example.com/company/api:v1.2.3
registry.example.com/company/api:v1.2
registry.example.com/company/api:v1
# Git SHA (immutable reference)
registry.example.com/company/api:sha-abc123def456
# Environment tags (development)
registry.example.com/company/api:dev
registry.example.com/company/api:staging
registry.example.com/company/api:prod
# Timestamp (for builds)
registry.example.com/company/api:2024-01-15-120530
Registry Operations Workflow
# Step 1: Build image locally
docker build -t myregistry.azurecr.io/company/api:v1.2.3 .
# Step 2: Authenticate to registry
az acr login --name myregistry
# Step 3: Push to registry
docker push myregistry.azurecr.io/company/api:v1.2.3
# Step 4: Pull for testing
docker pull myregistry.azurecr.io/company/api:v1.2.3
# Step 5: Sign image (optional)
cosign sign --key cosign.key myregistry.azurecr.io/company/api:v1.2.3
# Step 6: Verify signature
cosign verify --key cosign.pub myregistry.azurecr.io/company/api:v1.2.3
Multi-Registry Strategy
Vulnerability Scanning Tools Comparison
| Tool | Speed | Accuracy | Updates | Output |
|---|---|---|---|---|
| Trivy | Fast | Excellent | Daily | SBOM, JSON, SPDX |
| Grype | Medium | Excellent | Regular | SBOM, JSON |
| Snyk | Slow | Good | Real-time | JSON, HTML, SARIF |
| Anchore | Medium | Excellent | Regular | Detailed reports |
Scanning Pipeline Implementation
# GitHub Actions example
name: Container Security
on: [push]
jobs:
scan:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v3
- name: Build image
run: docker build -t app:${{ github.sha }} .
- name: Scan with Trivy
uses: aquasecurity/trivy-action@master
with:
image-ref: app:${{ github.sha }}
format: 'sarif'
output: 'trivy-results.sarif'
- name: Upload results
uses: github/codeql-action/upload-sarif@v2
with:
sarif_file: 'trivy-results.sarif'
Vulnerability Management SLA
Policy Enforcement
# Allowed base images only
FROM gcr.io/distroless/base-debian11:nonroot
# or
FROM node:18-alpine
# ❌ Do not use: ubuntu:latest, centos:7, etc.
Buildx Setup for Multiple Architectures
# Enable buildx
docker buildx create --name mybuilder
docker buildx use mybuilder
# Build for multiple architectures
docker buildx build \
--platform linux/amd64,linux/arm64,linux/arm/v7 \
-t myregistry.azurecr.io/company/api:v1.2.3 \
--push .
Architecture Support Matrix
Manifest List Strategy
# Create and push manifest list
docker buildx build --push \
--platform linux/amd64,linux/arm64 \
-t myregistry.azurecr.io/company/api:v1.2.3 .
# Kubernetes automatically pulls correct variant
kubectl create deployment app \
--image=myregistry.azurecr.io/company/api:v1.2.3
# On amd64 node: pulls amd64 variant
# On arm64 node: pulls arm64 variant
Resource Constraints
# Memory limit
docker run --memory 512m app
# CPU limits
docker run --cpus 1.5 app
# I/O limits
docker run --device-read-bps /dev/sda:10mb app
docker run --device-write-bps /dev/sda:10mb app
# Process limit
docker run --pids-limit 100 app
# Network bandwidth
docker run --network-opt "com.docker.network.driver.mtu=1500" app
Health Checks
HEALTHCHECK --interval=30s --timeout=5s --retries=3 \
CMD curl -f http://localhost:8080/health || exit 1
Dockerfile Security Checklist
Production Security Pattern
# Security-hardened Dockerfile
FROM gcr.io/distroless/base-debian11:nonroot
# No shell, no package manager, minimal attack surface
# Runs as UID 65532 (nonroot)
COPY --chown=65532:65532 app /app
WORKDIR /app
EXPOSE 8080
HEALTHCHECK --interval=30s --timeout=5s \
CMD ["/app/health"]
ENTRYPOINT ["/app/server"]
GitLab CI Example
build-image:
stage: build
image: docker:latest
script:
- docker build -t $CI_REGISTRY_IMAGE:$CI_COMMIT_SHA .
- docker push $CI_REGISTRY_IMAGE:$CI_COMMIT_SHA
- docker tag $CI_REGISTRY_IMAGE:$CI_COMMIT_SHA $CI_REGISTRY_IMAGE:latest
- docker push $CI_REGISTRY_IMAGE:latest
scan-image:
stage: test
image: aquasec/trivy:latest
script:
- trivy image --severity HIGH,CRITICAL $CI_REGISTRY_IMAGE:$CI_COMMIT_SHA
allow_failure: false
deploy-image:
stage: deploy
script:
- kubectl set image deployment/app app=$CI_REGISTRY_IMAGE:$CI_COMMIT_SHA
Scenario 1: Reduce Image Size 850MB → 45MB
Scenario 2: Implement Image Scanning Pipeline
Scenario 3: Build for Multiple Architectures
✅ Image size <50MB for most applications ✅ Build time <2 minutes ✅ Zero critical vulnerabilities ✅ <5 layers per Dockerfile ✅ Non-root user enforcement (100%) ✅ All images scanned before deployment ✅ Pull time <5 seconds ✅ Image signing coverage 100% (production) ✅ SBOM generated for all images ✅ Multi-arch support where needed
| Challenge | Solution |
|---|---|
| Large images (>500MB) | Multi-stage builds, distroless, cleanup |
| Slow builds (>5 min) | Layer caching, parallel builds, BuildKit |
| Vulnerabilities found in prod | Regular scanning, automated patching |
| Registry access errors | Auth config, service principals, RBAC |
| Architecture mismatches | Buildx, manifest lists, platform testing |
| Secret leaks in images | Use secret mounts, environment variables |
| Dependency bloat | Slim base images, minimal dependencies |
| License compliance issues | SBOM analysis, tool choice |
You are an elite AI agent architect specializing in crafting high-performance agent configurations. Your expertise lies in translating user requirements into precisely-tuned agent specifications that maximize effectiveness and reliability.