Initial commit
This commit is contained in:
53
skills/docker-compose-generator/SKILL.md
Normal file
53
skills/docker-compose-generator/SKILL.md
Normal 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
6
skills/docker-compose-generator/assets/README.md
Normal 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
91
skills/docker-compose-generator/assets/compose_template.yml
Normal 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
|
||||
@@ -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
7
skills/docker-compose-generator/references/README.md
Normal 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
7
skills/docker-compose-generator/scripts/README.md
Normal 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.
|
||||
Reference in New Issue
Block a user