zhongwei/gh-jeremylongshore-claude-code-plugins-plus-plugins-devops-docker-compose-generator
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Initial commit

Browse Source
This commit is contained in:
Zhongwei Li
2025-11-30 08:19:20 +08:00
commit ff4ea19b57
10 changed files with 595 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files

15
.claude-plugin/plugin.json Normal file
View File

@@ -0,0 +1,15 @@
{
"name": "docker-compose-generator",
"description": "Generate Docker Compose configurations for multi-container applications with best practices",
"version": "1.0.0",
"author": {
"name": "Claude Code Plugins",
"email": "[email protected]"
},
"skills": [
"./skills"
],
"commands": [
"./commands"
]
}

3
README.md Normal file
View File

@@ -0,0 +1,3 @@
# docker-compose-generator
Generate Docker Compose configurations for multi-container applications with best practices

137
commands/docker-compose.md Normal file
View File

@@ -0,0 +1,137 @@
---
description: Generate Docker Compose configurations
---
# Docker Compose Generator
Generate production-ready Docker Compose files with best practices.
## Configuration Patterns
1. **Multi-Service Architecture**: Define all services with dependencies
2. **Environment Variables**: Use .env files for configuration
3. **Volume Management**: Persistent data and named volumes
4. **Network Configuration**: Custom networks for service isolation
5. **Health Checks**: Service health monitoring
6. **Resource Limits**: CPU and memory constraints
## Example Docker Compose (Full Stack)
```yaml
version: '3.8'
services:
frontend:
build:
context: ./frontend
dockerfile: Dockerfile
ports:
- "3000:3000"
environment:
- NODE_ENV=production
- REACT_APP_API_URL=http://api:4000
depends_on:
- api
healthcheck:
test: ["CMD", "curl", "-f", "http://localhost:3000"]
interval: 30s
timeout: 10s
retries: 3
networks:
- app-network
api:
build:
context: ./api
dockerfile: Dockerfile
ports:
- "4000:4000"
environment:
- NODE_ENV=production
- DATABASE_URL=postgresql://user:pass@postgres:5432/db
- REDIS_URL=redis://redis:6379
depends_on:
postgres:
condition: service_healthy
redis:
condition: service_started
volumes:
- ./api/logs:/app/logs
deploy:
resources:
limits:
cpus: '1'
memory: 512M
networks:
- app-network
- db-network
postgres:
image: postgres:15-alpine
environment:
- POSTGRES_DB=myapp
- POSTGRES_USER=user
- POSTGRES_PASSWORD=pass
volumes:
- postgres-data:/var/lib/postgresql/data
- ./init.sql:/docker-entrypoint-initdb.d/init.sql
healthcheck:
test: ["CMD-SHELL", "pg_isready -U user"]
interval: 10s
timeout: 5s
retries: 5
networks:
- db-network
redis:
image: redis:7-alpine
command: redis-server --appendonly yes
volumes:
- redis-data:/data
healthcheck:
test: ["CMD", "redis-cli", "ping"]
interval: 10s
timeout: 5s
retries: 3
networks:
- app-network
nginx:
image: nginx:alpine
ports:
- "80:80"
- "443:443"
volumes:
- ./nginx.conf:/etc/nginx/nginx.conf:ro
- ./ssl:/etc/nginx/ssl:ro
depends_on:
- frontend
- api
networks:
- app-network
volumes:
postgres-data:
redis-data:
networks:
app-network:
driver: bridge
db-network:
driver: bridge
```
## Best Practices Included
- Service dependencies with health checks
- Named volumes for data persistence
- Custom networks for isolation
- Resource limits for stability
- Environment variable management
- Multi-stage builds support
- Health check configurations
- Logging and monitoring ready
## When Invoked
Generate complete Docker Compose configurations based on application architecture requirements.

69
plugin.lock.json Normal file
View File

@@ -0,0 +1,69 @@
{
"$schema": "internal://schemas/plugin.lock.v1.json",
"pluginId": "gh:jeremylongshore/claude-code-plugins-plus:plugins/devops/docker-compose-generator",
"normalized": {
"repo": null,
"ref": "refs/tags/v20251128.0",
"commit": "ee77701271e23a218b210b277934b64610684267",
"treeHash": "79094260012b1861dac6ea390dc07cb00357562214f515bc24bfade4c8dbb810",
"generatedAt": "2025-11-28T10:18:25.054100Z",
"toolVersion": "publish_plugins.py@0.2.0"
},
"origin": {
"remote": "git@github.com:zhongweili/42plugin-data.git",
"branch": "master",
"commit": "aa1497ed0949fd50e99e70d6324a29c5b34f9390",
"repoRoot": "/Users/zhongweili/projects/openmind/42plugin-data"
},
"manifest": {
"name": "docker-compose-generator",
"description": "Generate Docker Compose configurations for multi-container applications with best practices",
"version": "1.0.0"
},
"content": {
"files": [
{
"path": "README.md",
"sha256": "8c32a7ee6ebeabacd30279d27397c0fbd3360f5d2b173c2ed8548f10e1a78867"
},
{
"path": ".claude-plugin/plugin.json",
"sha256": "050ba3d2a32d65fe504ab7fb9dce187415ac82ffa5c295612d56e5610ef49aa3"
},
{
"path": "commands/docker-compose.md",
"sha256": "f6b85b9e98ac265cc528918ad51ee4e77b531c8455ddcb51c36547de3eab4247"
},
{
"path": "skills/docker-compose-generator/SKILL.md",
"sha256": "13002cd9f5815b51b11119a242277c643de021fb9b41a246df200887cad1b934"
},
{
"path": "skills/docker-compose-generator/references/README.md",
"sha256": "2794f61462e94ba2e71dc2608fc0e1df58a64bc1f6edd6bd3718948dd0871562"
},
{
"path": "skills/docker-compose-generator/scripts/README.md",
"sha256": "bbfb1c448b294ff8eaaec1fc00eccd8a0c202e4804e9498feaeae8bd377c83dd"
},
{
"path": "skills/docker-compose-generator/assets/compose_template.yml",
"sha256": "9a044d6916136fcd6443fb205bac188cfc86474a0949f85ba227b9cab1e169a8"
},
{
"path": "skills/docker-compose-generator/assets/README.md",
"sha256": "320151d345161d352d7836ae0a1835f1c866f9eec32c415aa35c0dd2b364e640"
},
{
"path": "skills/docker-compose-generator/assets/example_app_architectures.md",
"sha256": "b0977cdb3c71253d00b7cc2688e0865b894c9d8cb5319dc355a763ac6fca3a5a"
}
],
"dirSha256": "79094260012b1861dac6ea390dc07cb00357562214f515bc24bfade4c8dbb810"
},
"security": {
"scannedAt": null,
"scannerVersion": null,
"flags": []
}
}

53
skills/docker-compose-generator/SKILL.md Normal file
View File

@@ -0,0 +1,53 @@
---
name: generating-docker-compose-files
description: |
This skill enables Claude to generate Docker Compose configurations for multi-container applications. It leverages best practices for production-ready deployments, including defining services, networks, volumes, health checks, and resource limits. Claude should use this skill when the user requests a Docker Compose file, specifies application architecture involving multiple containers, or mentions needs for container orchestration, environment variables, or persistent data management in a Docker environment. Trigger terms include "docker-compose", "docker compose file", "multi-container", "container orchestration", "docker environment", "service definition", "volume management", "network configuration", "health checks", "resource limits", and ".env files".
allowed-tools: Read, Write, Edit, Grep, Glob, Bash
version: 1.0.0
---
## Overview
This skill empowers Claude to create fully functional Docker Compose files, streamlining the deployment of complex applications. It automatically incorporates recommended configurations for service dependencies, data persistence, and resource optimization.
## How It Works
1. **Receiving User Input**: Claude interprets the user's request, identifying the application's architecture and dependencies.
2. **Generating Compose Configuration**: Based on the interpreted request, Claude generates a `docker-compose.yml` file defining services, networks, volumes, and other configurations.
3. **Presenting the Configuration**: Claude provides the generated `docker-compose.yml` file to the user.
## When to Use This Skill
This skill activates when you need to:
- Generate a Docker Compose file for a multi-container application.
- Define service dependencies and network configurations for a Docker environment.
- Manage persistent data using Docker volumes.
- Configure health checks and resource limits for Docker containers.
## Examples
### Example 1: Deploying a Full-Stack Application
User request: "Generate a docker-compose file for a full-stack application with a Node.js frontend, a Python backend, and a PostgreSQL database."
The skill will:
1. Generate a `docker-compose.yml` file defining three services: `frontend`, `backend`, and `database`.
2. Configure network connections between the services and define volumes for persistent database storage.
### Example 2: Adding Health Checks
User request: "Create a docker-compose file for a Redis server with a health check."
The skill will:
1. Generate a `docker-compose.yml` file defining a Redis service.
2. Add a health check configuration to the Redis service, ensuring the container restarts if it becomes unhealthy.
## Best Practices
- **Service Dependencies**: Explicitly define dependencies between services using the `depends_on` directive.
- **Environment Variables**: Utilize `.env` files to manage environment variables and sensitive information.
- **Volume Naming**: Use named volumes for data persistence and avoid relying on host paths.
## Integration
This skill integrates with other development tools by providing a standardized Docker Compose configuration that can be used with Docker CLI, Docker Desktop, and other container management platforms.

6
skills/docker-compose-generator/assets/README.md Normal file
View File

@@ -0,0 +1,6 @@
# Assets
Bundled resources for docker-compose-generator skill
- [ ] compose_template.yml: A basic Docker Compose template with placeholders for common configurations.
- [ ] example_app_architectures.md: Examples of common application architectures and their corresponding Docker Compose configurations.

91
skills/docker-compose-generator/assets/compose_template.yml Normal file
View File

@@ -0,0 +1,91 @@
version: "3.9"
# Define services for your application
services:
# Example web application service
web:
image: nginx:latest # Replace with your web application image
container_name: web_app
ports:
- "80:80" # Expose port 80 for HTTP traffic
- "443:443" # Expose port 443 for HTTPS traffic (configure SSL certificates)
volumes:
- ./html:/usr/share/nginx/html # Mount your web application files
- ./nginx/conf.d:/etc/nginx/conf.d # Mount Nginx configuration files
depends_on:
- app # Ensure the app service is running before starting the web service
restart: always # Restart the service if it fails
healthcheck:
test: ["CMD-SHELL", "curl -f http://localhost || exit 1"] # Check if the web server is responding
interval: 30s # Check every 30 seconds
timeout: 10s # Timeout after 10 seconds
retries: 3 # Retry up to 3 times
networks:
- app_network # Connect to the application network
deploy:
resources:
limits:
cpus: "0.5" # Limit CPU usage to 0.5 cores
memory: 512M # Limit memory usage to 512MB
environment:
- REPLACE_ME=YOUR_VALUE_HERE # Example environment variable
# Example application service
app:
build:
context: ./app # Path to the application Dockerfile
container_name: app_service
environment:
- DATABASE_URL=postgres://user:password@db:5432/database # Database connection string
- SECRET_KEY=YOUR_SECRET_KEY # Secret key for your application
depends_on:
- db # Ensure the database service is running before starting the app service
restart: always # Restart the service if it fails
healthcheck:
test: ["CMD-SHELL", "curl -f http://localhost:8000/health || exit 1"] # Check if the application is responding
interval: 30s # Check every 30 seconds
timeout: 10s # Timeout after 10 seconds
retries: 3 # Retry up to 3 times
networks:
- app_network # Connect to the application network
deploy:
resources:
limits:
cpus: "1" # Limit CPU usage to 1 core
memory: 1G # Limit memory usage to 1GB
volumes:
- ./app:/app # Mount the application code
# Example database service
db:
image: postgres:14 # Use Postgres version 14
container_name: database
volumes:
- db_data:/var/lib/postgresql/data # Persist database data
environment:
- POSTGRES_USER=user # Database user
- POSTGRES_PASSWORD=password # Database password
- POSTGRES_DB=database # Database name
restart: always # Restart the service if it fails
healthcheck:
test: ["CMD-SHELL", "pg_isready -U user -d database"] # Check if the database is ready
interval: 30s # Check every 30 seconds
timeout: 10s # Timeout after 10 seconds
retries: 3 # Retry up to 3 times
networks:
- app_network # Connect to the application network
deploy:
resources:
limits:
cpus: "0.5" # Limit CPU usage to 0.5 cores
memory: 512M # Limit memory usage to 512MB
# Define networks for communication between services
networks:
app_network:
driver: bridge # Use a bridge network for internal communication
# Define volumes for persistent data storage
volumes:
db_data: # Volume for database data

207
skills/docker-compose-generator/assets/example_app_architectures.md Normal file
View File

@@ -0,0 +1,207 @@
# Example Application Architectures with Docker Compose
This document provides examples of common application architectures and their corresponding Docker Compose configurations. Use these examples as a starting point for building your own multi-container applications. Remember to replace the placeholders with your specific application details.
## Table of Contents
1. [Simple Web Application (Frontend + Backend + Database)](#simple-web-application)
2. [Message Queue Application (Producer + Message Broker + Consumer)](#message-queue-application)
3. [Microservices Architecture (API Gateway + Multiple Microservices)](#microservices-architecture)
## 1. Simple Web Application (Frontend + Backend + Database)
This example demonstrates a basic web application consisting of a frontend, a backend API, and a database.
**Architecture Diagram:**
```mermaid
graph LR
A[User] --> B(Frontend);
B --> C(Backend API);
C --> D(Database);
```
**Docker Compose Configuration (docker-compose.yml):**
```yaml
version: "3.8"
services:
frontend:
image: <YOUR_FRONTEND_IMAGE> # e.g., your-dockerhub-username/frontend:latest
ports:
- "80:80" # Map port 80 on the host to port 80 in the container
depends_on:
- backend
restart: always
networks:
- app-network
backend:
image: <YOUR_BACKEND_IMAGE> # e.g., your-dockerhub-username/backend:latest
environment:
DATABASE_URL: postgres://<DB_USER>:<DB_PASSWORD>@db:5432/<DB_NAME>
depends_on:
- db
restart: always
networks:
- app-network
db:
image: postgres:14 # Or your preferred database image
environment:
POSTGRES_USER: <DB_USER>
POSTGRES_PASSWORD: <DB_PASSWORD>
POSTGRES_DB: <DB_NAME>
volumes:
- db_data:/var/lib/postgresql/data
restart: always
networks:
- app-network
healthcheck:
test: ["CMD-SHELL", "pg_isready -U <DB_USER> -d <DB_NAME>"]
interval: 10s
timeout: 5s
retries: 3
volumes:
db_data:
networks:
app-network:
driver: bridge
```
**Instructions:**
1. Replace `<YOUR_FRONTEND_IMAGE>`, `<YOUR_BACKEND_IMAGE>`, `<DB_USER>`, `<DB_PASSWORD>`, and `<DB_NAME>` with your actual values.
2. Ensure your frontend and backend applications are properly configured to connect to the database using the environment variable `DATABASE_URL`.
3. The `depends_on` directive ensures that services start in the correct order.
4. The `healthcheck` ensures the database is ready before the backend attempts to connect. Adjust the parameters (interval, timeout, retries) as needed.
5. The `restart: always` directive ensures that services are automatically restarted if they fail.
6. Consider using environment variables for sensitive information like passwords. For production, use Docker secrets.
## 2. Message Queue Application (Producer + Message Broker + Consumer)
This example demonstrates a message queue application using RabbitMQ as the message broker.
**Architecture Diagram:**
```mermaid
graph LR
A[Producer] --> B(RabbitMQ);
B --> C[Consumer];
```
**Docker Compose Configuration (docker-compose.yml):**
```yaml
version: "3.8"
services:
rabbitmq:
image: rabbitmq:3.9-management # Or your preferred RabbitMQ image
ports:
- "5672:5672" # AMQP Port
- "15672:15672" # Management UI Port
environment:
RABBITMQ_DEFAULT_USER: <RABBITMQ_USER>
RABBITMQ_DEFAULT_PASS: <RABBITMQ_PASSWORD>
restart: always
networks:
- app-network
producer:
image: <YOUR_PRODUCER_IMAGE> # e.g., your-dockerhub-username/producer:latest
depends_on:
- rabbitmq
environment:
RABBITMQ_HOST: rabbitmq
RABBITMQ_USER: <RABBITMQ_USER>
RABBITMQ_PASSWORD: <RABBITMQ_PASSWORD>
restart: always
networks:
- app-network
consumer:
image: <YOUR_CONSUMER_IMAGE> # e.g., your-dockerhub-username/consumer:latest
depends_on:
- rabbitmq
environment:
RABBITMQ_HOST: rabbitmq
RABBITMQ_USER: <RABBITMQ_USER>
RABBITMQ_PASSWORD: <RABBITMQ_PASSWORD>
restart: always
networks:
- app-network
networks:
app-network:
driver: bridge
```
**Instructions:**
1. Replace `<YOUR_PRODUCER_IMAGE>`, `<YOUR_CONSUMER_IMAGE>`, `<RABBITMQ_USER>`, and `<RABBITMQ_PASSWORD>` with your actual values.
2. Configure your producer and consumer applications to connect to RabbitMQ using the specified environment variables.
3. The RabbitMQ management UI is accessible at `http://localhost:15672` (or the appropriate host and port).
4. Consider using persistent volumes for RabbitMQ data to avoid data loss on container restarts.
## 3. Microservices Architecture (API Gateway + Multiple Microservices)
This example demonstrates a simplified microservices architecture with an API gateway and two microservices.
**Architecture Diagram:**
```mermaid
graph LR
A[User] --> B(API Gateway);
B --> C(Microservice 1);
B --> D(Microservice 2);
```
**Docker Compose Configuration (docker-compose.yml):**
```yaml
version: "3.8"
services:
api-gateway:
image: <YOUR_API_GATEWAY_IMAGE> # e.g., your-dockerhub-username/api-gateway:latest
ports:
- "8080:8080" # Map port 8080 on the host to port 8080 in the container
depends_on:
- microservice1
- microservice2
restart: always
networks:
- app-network
microservice1:
image: <YOUR_MICROSERVICE1_IMAGE> # e.g., your-dockerhub-username/microservice1:latest
restart: always
networks:
- app-network
environment:
PORT: 3001
microservice2:
image: <YOUR_MICROSERVICE2_IMAGE> # e.g., your-dockerhub-username/microservice2:latest
restart: always
networks:
- app-network
environment:
PORT: 3002
networks:
app-network:
driver: bridge
```
**Instructions:**
1. Replace `<YOUR_API_GATEWAY_IMAGE>`, `<YOUR_MICROSERVICE1_IMAGE>`, and `<YOUR_MICROSERVICE2_IMAGE>` with your actual values.
2. Configure your API gateway to route requests to the appropriate microservices. The example provides a PORT environment variable that the microservices can use.
3. Consider using a service discovery mechanism (e.g., Consul, etcd) for more dynamic microservice discovery.
4. Implement proper authentication and authorization in the API gateway.
5. Implement monitoring and logging for all services.
6. Consider using health checks for each microservice and exposing them via an endpoint like `/health`. The API Gateway can then use these endpoints to determine if a microservice is healthy before routing traffic.
This is a basic example. For a production environment, you would likely include additional services for monitoring, logging, and service discovery. You would also likely use a more sophisticated API gateway solution.

7
skills/docker-compose-generator/references/README.md Normal file
View File

@@ -0,0 +1,7 @@
# References
Bundled resources for docker-compose-generator skill
- [ ] docker_compose_best_practices.md: A document outlining best practices for writing production-ready Docker Compose files, including security, networking, and resource management.
- [ ] common_service_configurations.md: A collection of pre-defined configurations for common services like databases, web servers, and message queues.
- [ ] healthcheck_examples.md: Examples of how to configure health checks for different types of services.

7
skills/docker-compose-generator/scripts/README.md Normal file
View File

@@ -0,0 +1,7 @@
# Scripts
Bundled resources for docker-compose-generator skill
- [ ] validate_compose.sh: Validates the generated Docker Compose file using docker-compose config.
- [ ] generate_env_file.py: Generates a .env file based on the Docker Compose file, pre-filled with default values.
- [ ] deploy.sh: A script to deploy the Docker Compose file to a Docker Swarm or Kubernetes cluster.