Generate Dockerfiles, Docker Compose configurations, and Kubernetes manifests for containerizing applications. Use when: (1) Creating Dockerfiles for Node.js, Python, Java, Go, or other applications, (2) Setting up multi-service environments with Docker Compose, (3) Generating Kubernetes deployments, services, and ingress configurations, (4) Optimizing container images for production, (5) Implementing containerization best practices. Provides both ready-to-use templates and custom-generated configurations based on project requirements.
npx skills add https://github.com/ArabelaTso/Skills-4-SE --skill containerization-assistant
Generate production-ready Docker and Kubernetes configurations for your applications.
For existing templates:
# Node.js application
cp assets/Dockerfile.nodejs ./Dockerfile
# Python application
cp assets/Dockerfile.python ./Dockerfile
# Java application (Spring Boot)
cp assets/Dockerfile.java ./Dockerfile
# Go application
cp assets/Dockerfile.go ./Dockerfile
For custom generation: Describe your application stack and requirements, and a custom Dockerfile will be generated.
# Multi-service application template
cp assets/docker-compose.yml ./
cp assets/.env.example ./.env
# Edit .env with your configuration
Kubernetes configurations are generated based on your deployment requirements. See kubernetes_patterns.md for complete examples.
Node.js (assets/Dockerfile.nodejs):
Python (assets/Dockerfile.python):
Java (assets/Dockerfile.java):
Go (assets/Dockerfile.go):
Multi-service stack (assets/docker-compose.yml):
Environment template (assets/.env.example):
Identify:
Template-based:
Custom generation:
Dockerfile customization:
# Update base image version
FROM node:18-alpine # Change version as needed
# Add build arguments
ARG NODE_ENV=production
# Modify exposed port
EXPOSE 3000 # Change to your port
# Update startup command
CMD ["node", "server.js"] # Change to your entry point
Docker Compose customization:
services:
web:
build:
context: .
dockerfile: Dockerfile
ports:
- "3000:3000" # Change port mapping
environment:
- DATABASE_URL=${DATABASE_URL} # Add environment variables
# Build Docker image
docker build -t myapp:1.0.0 .
# Test locally
docker run -p 3000:3000 myapp:1.0.0
# Test with Docker Compose
docker-compose up -d
# View logs
docker-compose logs -f
# Stop services
docker-compose down
See dockerfile_best_practices.md for:
Requirements: Node.js 18, PostgreSQL database, Redis cache
Steps:
Dockerfile.nodejs templatedocker-compose.yml for local developmentGenerated files:
Dockerfile - Multi-stage Node.js builddocker-compose.yml - Web, PostgreSQL, Redis services.env - Configuration variables.dockerignore - Exclude unnecessary filesRequirements: Python 3.11, PostgreSQL, Celery workers
Steps:
Dockerfile.python templateGenerated files:
Dockerfile - Multi-stage Python builddocker-compose.yml - Web, PostgreSQL, Redis, Celerycelery-worker.Dockerfile - Celery worker image.env - Database and Celery configurationRequirements: Deploy containerized app to Kubernetes with scaling
Steps:
See kubernetes_patterns.md for complete examples.
Requirements: Multiple services (API, Auth, Workers) with shared database
Steps:
Generated structure:
services/
api/
Dockerfile
auth/
Dockerfile
worker/
Dockerfile
docker-compose.yml
.env
Reduce image size by separating build and runtime:
# Build stage
FROM node:18-alpine AS builder
WORKDIR /app
COPY package*.json ./
RUN npm ci
COPY . .
RUN npm run build
# Production stage
FROM node:18-alpine
WORKDIR /app
COPY --from=builder /app/dist ./dist
COPY --from=builder /app/node_modules ./node_modules
CMD ["node", "dist/index.js"]
# Use non-root user
RUN addgroup -g 1001 -S nodejs && \
adduser -S nodejs -u 1001 -G nodejs
USER nodejs
# Use specific versions
FROM node:18.17.0-alpine # Not 'latest'
# Scan for vulnerabilities
# docker scan myapp:latest
# Order layers from least to most frequently changing
COPY package*.json ./ # Changes less often
RUN npm ci
COPY . . # Changes more often
# Use .dockerignore
# node_modules
# .git
# *.md
For comprehensive best practices, see dockerfile_best_practices.md.
apiVersion: apps/v1
kind: Deployment
metadata:
name: myapp
spec:
replicas: 3
selector:
matchLabels:
app: myapp
template:
spec:
containers:
- name: myapp
image: myapp:1.0.0
resources:
requests:
memory: "256Mi"
cpu: "250m"
limits:
memory: "512Mi"
cpu: "500m"
apiVersion: v1
kind: Service
metadata:
name: myapp-service
spec:
type: ClusterIP
selector:
app: myapp
ports:
- port: 80
targetPort: 8080
---
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: myapp-ingress
annotations:
cert-manager.io/cluster-issuer: "letsencrypt-prod"
spec:
tls:
- hosts:
- myapp.example.com
secretName: myapp-tls
rules:
- host: myapp.example.com
http:
paths:
- path: /
pathType: Prefix
backend:
service:
name: myapp-service
port:
number: 80
For complete Kubernetes patterns including ConfigMaps, Secrets, StatefulSets, Jobs, and more, see kubernetes_patterns.md.
Development (.env):
NODE_ENV=development
DATABASE_URL=postgresql://localhost/myapp_dev
DEBUG=true
Production (Kubernetes Secret):
apiVersion: v1
kind: Secret
metadata:
name: myapp-secrets
type: Opaque
stringData:
database_url: "postgresql://prod-db/myapp"
api_key: "secret-key"
apiVersion: v1
kind: ConfigMap
metadata:
name: myapp-config
data:
log_level: "info"
feature_flags: |
{
"new_ui": true,
"beta_features": false
}
Problem: Build fails with permission errors
Solution:
RUN chown -R appuser:appuser /app
USER appuser
Problem: Image too large
Solution:
Problem: Container exits immediately
Solution:
docker logs <container>Problem: Cannot connect to container
Solution:
-p 3000:30000.0.0.0, not localhostProblem: Pod stuck in Pending state
Solution:
kubectl describe pod <pod-name>
# Check events for resource constraints or image pull issues
Problem: Pod crashes with OOMKilled
Solution:
resources:
limits:
memory: "512Mi" # Increase memory limit
See dockerfile_best_practices.md for:
See kubernetes_patterns.md for:
GitHub Actions:
name: Build and Push Docker Image
on:
push:
branches: [main]
jobs:
build:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v3
- name: Build Docker image
run: docker build -t myapp:${{ github.sha }} .
- name: Push to registry
run: |
echo ${{ secrets.DOCKER_PASSWORD }} | docker login -u ${{ secrets.DOCKER_USERNAME }} --password-stdin
docker push myapp:${{ github.sha }}
Push to Docker Hub:
docker tag myapp:1.0.0 username/myapp:1.0.0
docker push username/myapp:1.0.0
Push to AWS ECR:
aws ecr get-login-password --region us-east-1 | docker login --username AWS --password-stdin 123456789.dkr.ecr.us-east-1.amazonaws.com
docker tag myapp:1.0.0 123456789.dkr.ecr.us-east-1.amazonaws.com/myapp:1.0.0
docker push 123456789.dkr.ecr.us-east-1.amazonaws.com/myapp:1.0.0
For complex Kubernetes deployments, consider using Helm charts for templated manifests and version management.
Assess Kubernetes workloads and cluster configuration for AKS Automatic compatibility. Identifies incompatibilities, generates fixes, and guides migration from AKS Standard to AKS Automatic. WHEN: migrate to AKS Automatic, check AKS Automatic readiness, validate manifests for Automatic, assess cluster for Automatic compatibility, fix deployment for Automatic compatibility, identify AKS Automatic migration blockers, is my cluster ready for AKS Automatic.
Discovers available Azure OpenAI model capacity across regions and projects. Analyzes quota limits, compares availability, and recommends optimal deployment locations based on capacity requirements. USE FOR: find capacity, check quota, where can I deploy, capacity discovery, best region for capacity, multi-project capacity search, quota analysis, model availability, region comparison, check TPM availability. DO NOT USE FOR: actual deployment (hand off to preset or customize after discovery), quota increase requests (direct user to Azure Portal), listing existing deployments.
Interactive guided deployment flow for Azure OpenAI models with full customization control. Step-by-step selection of model version, SKU (GlobalStandard/Standard/ProvisionedManaged), capacity, RAI policy (content filter), and advanced options (dynamic quota, priority processing, spillover). USE FOR: custom deployment, customize model deployment, choose version, select SKU, set capacity, configure content filter, RAI policy, deployment options, detailed deployment, advanced deployment, PTU deployment, provisioned throughput. DO NOT USE FOR: quick deployment to optimal region (use preset).
Unified Azure OpenAI model deployment skill with intelligent intent-based routing. Handles quick preset deployments, fully customized deployments (version/SKU/capacity/RAI policy), and capacity discovery across regions and projects. USE FOR: deploy model, deploy gpt, create deployment, model deployment, deploy openai model, set up model, provision model, find capacity, check model availability, where can I deploy, best region for model, capacity analysis. DO NOT USE FOR: listing existing deployments (use foundry_models_deployments_list MCP tool), deleting deployments, agent creation (use agent/create), project creation (use project/create).
Intelligently deploys Azure OpenAI models to optimal regions by analyzing capacity across all available regions. Automatically checks current region first and shows alternatives if needed. USE FOR: quick deployment, optimal region, best region, automatic region selection, fast setup, multi-region capacity check, high availability deployment, deploy to best location. DO NOT USE FOR: custom SKU selection (use customize), specific version selection (use customize), custom capacity configuration (use customize), PTU deployments (use customize).
This skill should be used when working with LaminDB, an open-source data framework for biology that makes data queryable, traceable, reproducible, and FAIR. Use when managing biological datasets (scRNA-seq, spatial, flow cytometry, etc.), tracking computational workflows, curating and validating data with biological ontologies, building data lakehouses, or ensuring data lineage and reproducibility in biological research. Covers data management, annotation, ontologies (genes, cell types, diseases, tissues), schema validation, integrations with workflow managers (Nextflow, Snakemake) and MLOps platforms (W&B, MLflow), and deployment strategies.
Latch platform for bioinformatics workflows. Build pipelines with Latch SDK, @workflow/@task decorators, deploy serverless workflows, LatchFile/LatchDir, Nextflow/Snakemake integration.
Run Python code in the cloud with serverless containers, GPUs, and autoscaling. Use when deploying ML models, running batch processing jobs, scheduling compute-intensive tasks, or serving APIs that require GPU acceleration or dynamic scaling.
Take arabelatso/containerization-assistant from the repository into ~/.claude/skills for personal
use, or into .claude/skills inside a project.
The agent identifies a skill by the name field in its header. Two skills with the
same name cannot sit side by side — one of them will be ignored.
The instructions reference pip, docker.
Without those the skill loads but fails at the first command.