container-architect

Container Architect

Strategic container design and Docker optimization decisions.

Decision Framework

Containerization Strategy

Single Container - When to use:

• Simple applications
• Microservices (one service per container)
• Stateless applications
• Development environments

Multi-Container - When to use:

• Application with dependencies (app + database)
• Microservices architecture
• Need for service isolation
• Complex applications

Docker Compose - When to use:

• Local development
• Multiple related services
• Simple orchestration needs
• Testing environments

Kubernetes - When to use:

• Production deployments
• Auto-scaling needed
• High availability required
• Complex orchestration

Base Image Selection

Alpine Linux - Best for:

• Minimal image size (5MB base)
• Security-conscious deployments
• Simple applications
• Production environments

Debian/Ubuntu - Best for:

• Compatibility requirements
• Complex dependencies
• Development environments
• Familiar tooling

Distroless - Best for:

• Maximum security
• Production deployments
• No shell access needed
• Minimal attack surface

Scratch - Best for:

• Static binaries (Go, Rust)
• Absolute minimal size
• No OS dependencies
• Maximum security

Image Optimization Approach

Multi-Stage Builds - When to use:

• Compiled languages (Go, Java, C++)
• Build tools not needed in runtime
• Want minimal final image
• Separate build and runtime dependencies

Layer Optimization - When to use:

• Frequent rebuilds
• Large dependencies
• Want faster builds
• Optimize caching

Security Hardening - When to use:

• Production deployments
• Sensitive data handling
• Compliance requirements
• Public-facing services

Skill Delegation

For image optimization: Delegate to dockerfile-optimizer skill

• Analyzes Dockerfile structure
• Recommends optimization strategies
• Implements multi-stage builds
• Reduces image size

For security scanning: Delegate to image-security-scanner skill

• Scans for vulnerabilities
• Checks base image security
• Identifies outdated packages
• Recommends security fixes

Approach Selection

New Application Containerization

Simple Web App:

1. Choose appropriate base image (node:alpine, python:slim)
2. Use multi-stage build if applicable
3. Optimize layer caching
4. Add health checks
5. Run as non-root user

Microservice:

1. Minimal base image (alpine, distroless)
2. Multi-stage build for compiled languages
3. Single responsibility per container
4. Implement health/readiness probes
5. Use Docker Compose for local dev

Legacy Application:

1. Start with compatible base image
2. Document dependencies
3. Gradual optimization
4. Test thoroughly
5. Consider breaking into microservices

Image Size Optimization

Priority: Minimal Size:

1. Use alpine or distroless base
2. Multi-stage builds
3. Remove build dependencies
4. Combine RUN commands
5. Use .dockerignore

Priority: Build Speed:

1. Optimize layer caching
2. Order commands by change frequency
3. Use build cache mounts
4. Parallel builds where possible
5. Cache package managers

Priority: Security:

1. Minimal base image
2. No unnecessary packages
3. Run as non-root
4. Scan for vulnerabilities
5. Keep images updated

Production Deployment

Single Server:

• Docker Compose
• Volume management
• Backup strategy
• Monitoring setup

Cloud Platform:

• Container registry (ECR, GCR, ACR)
• Orchestration (ECS, Cloud Run, App Engine)
• Auto-scaling configuration
• Load balancing

Kubernetes:

• Deployment manifests
• Service definitions
• ConfigMaps and Secrets
• Ingress configuration

Common Scenarios

Scenario: Node.js Application

Recommendation:

# Multi-stage build
FROM node:18-alpine AS builder
WORKDIR /app
COPY package*.json ./
RUN npm ci --only=production

FROM node:18-alpine
WORKDIR /app
COPY --from=builder /app/node_modules ./node_modules
COPY . .
USER node
EXPOSE 3000
CMD ["node", "server.js"]

Rationale:

• Alpine for minimal size
• Multi-stage to separate dependencies
• Run as non-root user
• Production dependencies only

Scenario: Python Application

Recommendation:

FROM python:3.11-slim
WORKDIR /app
COPY requirements.txt .
RUN pip install --no-cache-dir -r requirements.txt
COPY . .
USER nobody
EXPOSE 8000
CMD ["python", "app.py"]

Rationale:

• Slim variant for balance of size/compatibility
• No pip cache to reduce size
• Run as nobody user
• Simple single-stage for Python

Scenario: Go Application

Recommendation:

FROM golang:1.21-alpine AS builder
WORKDIR /app
COPY go.* ./
RUN go mod download
COPY . .
RUN CGO_ENABLED=0 go build -o app

FROM scratch
COPY --from=builder /app/app /app
EXPOSE 8080
CMD ["/app"]

Rationale:

• Multi-stage build
• Scratch for minimal size (static binary)
• No OS dependencies needed
• Maximum security

Scenario: Java Application

Recommendation:

FROM maven:3.9-eclipse-temurin-17 AS builder
WORKDIR /app
COPY pom.xml .
RUN mvn dependency:go-offline
COPY src ./src
RUN mvn package -DskipTests

FROM eclipse-temurin:17-jre-alpine
WORKDIR /app
COPY --from=builder /app/target/*.jar app.jar
USER nobody
EXPOSE 8080
CMD ["java", "-jar", "app.jar"]

Rationale:

• Multi-stage separates build from runtime
• JRE only in final image (smaller)
• Alpine for minimal size
• Run as nobody user

Decision Criteria

When to use multi-stage builds:

Use when:

• Compiled languages (Go, Java, C++, Rust)
• Build tools differ from runtime needs
• Want minimal production image
• Separate build and runtime dependencies

Skip when:

• Interpreted languages with simple deps
• Development environments
• Build time is critical
• Image size not a concern

When to optimize for size:

Optimize when:

• Deploying to cloud (cost savings)
• Slow network connections
• Many instances running
• Frequent deployments

Don't optimize when:

• Development environments
• Build speed more important
• Compatibility issues with minimal images
• Team unfamiliar with optimization

When to use Docker Compose:

Use when:

• Local development
• Multiple related services
• Simple orchestration
• Testing environments

Use Kubernetes when:

• Production at scale
• Auto-scaling needed
• High availability required
• Complex networking

Best Practices

Dockerfile Structure

Order by change frequency:

1. Base image
2. System dependencies
3. Application dependencies
4. Application code
5. Configuration
6. Entry point

Example:

FROM node:18-alpine
RUN apk add --no-cache curl
COPY package*.json ./
RUN npm ci
COPY . .
EXPOSE 3000
CMD ["node", "server.js"]

Security Practices

• Run as non-root user
• Use specific image tags (not latest)
• Scan for vulnerabilities
• Minimize installed packages
• Keep base images updated
• Use secrets management
• Don't embed credentials

Performance Practices

• Optimize layer caching
• Use .dockerignore
• Combine RUN commands
• Use build cache mounts
• Minimize layers
• Use appropriate base images

Development Workflow

• Use Docker Compose for local dev
• Volume mount source code
• Hot reload for development
• Separate dev and prod Dockerfiles
• Use build targets for environments

Image Registry Strategy

Docker Hub - When to use:

• Public images
• Open source projects
• Simple needs
• Free tier sufficient

Private Registry - When to use:

• Proprietary code
• Security requirements
• Compliance needs
• Full control needed

Cloud Registry - When to use:

• Cloud deployments (ECR, GCR, ACR)
• Integration with cloud services
• Managed solution preferred
• Scalability needed

Monitoring and Logging

Container Metrics:

• CPU usage
• Memory usage
• Network I/O
• Disk I/O

Logging Strategy:

• Log to stdout/stderr
• Use logging drivers
• Centralized logging (ELK, CloudWatch)
• Structured logging (JSON)

Health Checks:

HEALTHCHECK --interval=30s --timeout=3s \
  CMD curl -f http://localhost:8080/health || exit 1