Container Registry Management Suite

Complete container registry management toolkit covering Docker Hub, ECR, GCR, GitHub Container Registry operations, image lifecycle management, vulnerability scanning, and multi-architecture builds.

When to Use This Skill

Choose Container Registry Management when:

• Setting up and managing container image registries
• Implementing image lifecycle policies (retention, cleanup)
• Configuring CI/CD pipelines for image building and pushing
• Scanning container images for security vulnerabilities
• Managing multi-architecture (ARM/AMD64) image builds

Consider alternatives when:

• Need container orchestration — use Kubernetes or ECS
• Need local development — use Docker Compose
• Need serverless containers — use Cloud Run or Fargate

Quick Start

Copy
# Activate registry management
claude skill activate advanced-container-registry-management-suite

# Set up registry
claude "Set up ECR with lifecycle policies and vulnerability scanning"

# Optimize images
claude "Optimize our Docker images for size and build speed"

Example: Multi-Stage Dockerfile with Best Practices

Copy
# Stage 1: Dependencies
FROM node:20-alpine AS deps
WORKDIR /app
COPY package.json package-lock.json ./
RUN npm ci --only=production && \
    cp -R node_modules /prod_modules && \
    npm ci

# Stage 2: Build
FROM node:20-alpine AS builder
WORKDIR /app
COPY --from=deps /app/node_modules ./node_modules
COPY . .
RUN npm run build

# Stage 3: Production
FROM node:20-alpine AS runner
WORKDIR /app

# Security: non-root user
RUN addgroup --system app && adduser --system --ingroup app app

# Copy only production dependencies and build output
COPY --from=deps /prod_modules ./node_modules
COPY --from=builder /app/dist ./dist
COPY --from=builder /app/package.json ./

USER app
EXPOSE 3000

HEALTHCHECK --interval=30s --timeout=3s --start-period=5s \
  CMD wget --no-verbose --tries=1 --spider http://localhost:3000/health || exit 1

CMD ["node", "dist/index.js"]

Core Concepts

Registry Platforms

Registry	Provider	Features
Docker Hub	Docker	Public repos, automated builds, rate limits
Amazon ECR	AWS	IAM auth, lifecycle policies, scanning
Google Artifact Registry	GCP	Multi-format, IAM, vulnerability scanning
GitHub Container Registry	GitHub	GitHub Actions integration, GHCR packages
Azure Container Registry	Azure	Geo-replication, tasks, Helm charts

Image Optimization

Technique	Size Reduction	Implementation
Multi-stage builds	50-80%	Separate build and runtime stages
Alpine base images	60-70%	Use node:20-alpine instead of node:20
Distroless images	70-90%	gcr.io/distroless/nodejs20-debian12
Layer caching	Build speed	Order COPY statements by change frequency
.dockerignore	Variable	Exclude node_modules, .git, docs

Copy
# Registry operations
# Login to ECR
aws ecr get-login-password --region us-east-1 | docker login --username AWS --password-stdin 123456.dkr.ecr.us-east-1.amazonaws.com

# Build and push multi-arch image
docker buildx create --name multiarch --use
docker buildx build --platform linux/amd64,linux/arm64 \
  -t 123456.dkr.ecr.us-east-1.amazonaws.com/app:latest \
  --push .

# Scan image for vulnerabilities
docker scout quickview 123456.dkr.ecr.us-east-1.amazonaws.com/app:latest
trivy image 123456.dkr.ecr.us-east-1.amazonaws.com/app:latest

# List and clean up images
aws ecr describe-images --repository-name app \
  --query 'imageDetails[?imagePushedAt<`2024-01-01`]' \
  --output table

Configuration

Parameter	Description	Default
registry	Registry platform	ecr
scan_on_push	Scan images when pushed	true
immutable_tags	Prevent tag overwriting	true
lifecycle_rules	Image retention policies	Keep last 10 tagged
encryption	Image encryption	AES-256
replication	Cross-region replication	false

Best Practices

1. Use multi-stage builds to separate build and runtime dependencies — Build stage includes compilers, dev dependencies, and build tools. Production stage contains only the application binary, production dependencies, and runtime. This reduces image size by 50-80%.

2. Scan images in CI before pushing to registry — Run Trivy, Snyk, or Docker Scout as a CI step. Block pushes with critical or high vulnerabilities. Scan both application code and base image layers.

3. Use immutable tags for production deployments — Never overwrite the latest tag in production. Use semantic version tags (v1.2.3) or commit SHA tags (abc123) that are immutable. This ensures rollbacks deploy the exact previous image.

4. Order Dockerfile instructions by change frequency — Put rarely-changing instructions (base image, system packages) first, then dependencies (package.json copy + install), then application code (COPY . .) last. This maximizes Docker layer cache hits during builds.

5. Implement lifecycle policies to prevent storage cost growth — Set retention policies to keep only the last N tagged images and delete untagged images after 1-7 days. Without lifecycle policies, registries grow indefinitely and storage costs accumulate silently.

Common Issues

Docker builds are slow in CI due to cache misses. Use registry-backed BuildKit cache: docker buildx build --cache-from type=registry,ref=app:cache --cache-to type=registry,ref=app:cache. This stores build layer cache in the registry, shared across CI runners.

Images are too large (>1GB) and slow to deploy. Switch to Alpine or distroless base images. Remove build tools from the final stage. Use .dockerignore to exclude node_modules, .git, tests, and documentation. Check for unnecessary files with docker history and dive tool.

Vulnerability scan reports false positives on OS-level packages. Distinguish between application vulnerabilities (in your code/deps) and OS vulnerabilities (in base image packages). Update the base image to the latest patch version for OS-level fixes. Suppress verified false positives in your scan configuration with documented justification.