docker-playwright-config
Configure Playwright MCP to use Docker container IP addresses instead of localhost for testing containerized applications
What this skill does
# Docker Playwright Configuration Skill
Use this skill to properly configure Playwright testing with Docker containers by using container IP addresses instead of localhost.
## When to Use
- Before running Playwright tests against Docker containers
- When localhost connections fail
- For testing in Docker Compose environments
- During QA validation of containerized apps
- In CI/CD pipelines with Docker
## Why This Is Important
### The Problem with localhost
When Playwright MCP runs and tries to connect to `localhost:3003`, it may:
- ❌ Connect to the host machine, not the container
- ❌ Fail due to port mapping issues
- ❌ Have network isolation problems
- ❌ Experience inconsistent behavior
### The Solution: Docker IPs
Using container IP addresses directly:
- ✅ Connects directly to the container
- ✅ Works reliably in Docker networks
- ✅ Avoids port mapping confusion
- ✅ Consistent behavior in all environments
## What This Skill Does
### 1. Find Docker Container IPs
Retrieves IP addresses for all running containers:
```bash
docker ps --format "{{.Names}}" | while read container; do
ip=$(docker inspect -f '{{range .NetworkSettings.Networks}}{{.IPAddress}}{{end}}' "$container")
echo "$container: $ip"
done
```
### 2. Create URL Mapping
Maps service names to container IPs:
```
auth_ui: http://172.18.0.2:80
appointments_ui: http://172.18.0.3:80
scheduling_ui: http://172.18.0.4:80
auth_api: http://172.18.0.5:80
```
### 3. Generate Test Configuration
Creates configuration for Playwright tests with correct URLs.
### 4. Validate Connectivity
Tests that containers are accessible on their IPs:
```bash
curl -f http://172.18.0.4:80/remoteEntry.js
```
## Available Tools
### Bash Commands
- `docker ps` - List running containers
- `docker inspect` - Get container details including IP
- `docker-compose ps` - List compose services
- `curl` - Test container connectivity
- `docker network inspect` - Examine Docker network
## Configuration Workflow
### Step 1: List Running Containers
```bash
docker ps --format "table {{.Names}}\t{{.Status}}\t{{.Ports}}"
```
**Expected Output:**
```
NAMES STATUS PORTS
scheduling_ui Up 10 minutes 0.0.0.0:3003->80/tcp
scheduling_api Up 10 minutes 0.0.0.0:8003->80/tcp
auth_ui Up 15 minutes 0.0.0.0:3001->80/tcp
auth_api Up 15 minutes 0.0.0.0:8001->80/tcp
```
### Step 2: Get Container IP Addresses
```bash
#!/bin/bash
echo "=== Docker Container IP Addresses ==="
echo ""
# Get all running container names
containers=$(docker ps --format "{{.Names}}")
for container in $containers; do
# Get IP address from Docker network
ip=$(docker inspect -f '{{range .NetworkSettings.Networks}}{{.IPAddress}}{{end}}' "$container")
# Get exposed port
port=$(docker inspect -f '{{range $p, $conf := .NetworkSettings.Ports}}{{$p}}{{end}}' "$container" | cut -d'/' -f1)
# Default to port 80 if not found
if [ -z "$port" ]; then
port=80
fi
echo "$container"
echo " IP: $ip"
echo " URL: http://$ip:80"
echo ""
done
```
**Expected Output:**
```
=== Docker Container IP Addresses ===
scheduling_ui
IP: 172.18.0.4
URL: http://172.18.0.4:80
scheduling_api
IP: 172.18.0.5
URL: http://172.18.0.5:80
auth_ui
IP: 172.18.0.2
URL: http://172.18.0.2:80
auth_api
IP: 172.18.0.3
URL: http://172.18.0.3:80
```
### Step 3: Test Container Connectivity
```bash
#!/bin/bash
echo "=== Testing Container Connectivity ==="
echo ""
# Function to test URL
test_url() {
local name=$1
local url=$2
echo -n "Testing $name ($url)... "
if curl -f -s -o /dev/null -m 5 "$url"; then
echo "✅ OK"
return 0
else
echo "❌ FAIL"
return 1
fi
}
# Get container IPs and test
containers=$(docker ps --format "{{.Names}}")
for container in $containers; do
ip=$(docker inspect -f '{{range .NetworkSettings.Networks}}{{.IPAddress}}{{end}}' "$container")
# Test UI containers (remoteEntry.js)
if [[ $container == *"_ui" ]]; then
test_url "$container" "http://$ip:80/remoteEntry.js"
fi
# Test API containers (/health)
if [[ $container == *"_api" ]]; then
test_url "$container" "http://$ip:80/health"
fi
done
```
### Step 4: Create Playwright Test Configuration
```bash
#!/bin/bash
echo "=== Playwright Test Configuration ==="
echo ""
echo "Use these URLs in your Playwright tests:"
echo ""
containers=$(docker ps --format "{{.Names}}")
for container in $containers; do
ip=$(docker inspect -f '{{range .NetworkSettings.Networks}}{{.IPAddress}}{{end}}' "$container")
if [[ $container == *"_ui" ]]; then
service_name=$(echo "$container" | sed 's/_ui//')
echo "# $service_name UI"
echo "const ${service_name}URL = 'http://$ip:80'"
echo ""
fi
done
echo ""
echo "Example usage:"
echo "mcp__playwright__browser_navigate(schedulingURL)"
```
**Expected Output:**
```
=== Playwright Test Configuration ===
Use these URLs in your Playwright tests:
# scheduling UI
const schedulingURL = 'http://172.18.0.4:80'
# auth UI
const authURL = 'http://172.18.0.2:80'
Example usage:
mcp__playwright__browser_navigate(schedulingURL)
```
### Step 5: Verify Network Configuration
```bash
# Check which Docker network containers are on
docker network inspect stylemate_net --format '{{range .Containers}}{{.Name}}: {{.IPv4Address}}{{"\n"}}{{end}}'
```
## Container IP Quick Reference Script
Create a helper script to quickly get container URLs:
```bash
#!/bin/bash
# File: get-container-urls.sh
get_container_url() {
local container_name=$1
local ip=$(docker inspect -f '{{range .NetworkSettings.Networks}}{{.IPAddress}}{{end}}' "$container_name" 2>/dev/null)
if [ -z "$ip" ]; then
echo "Error: Container '$container_name' not found or not running"
return 1
fi
echo "http://$ip:80"
}
# Usage examples:
# get_container_url "scheduling_ui"
# get_container_url "scheduling_api"
# If called with argument, return that container's URL
if [ $# -eq 1 ]; then
get_container_url "$1"
else
# Otherwise, show all containers
echo "=== All Container URLs ==="
for container in $(docker ps --format "{{.Names}}"); do
url=$(get_container_url "$container")
echo "$container: $url"
done
fi
```
**Usage:**
```bash
# Get all URLs
./get-container-urls.sh
# Get specific container URL
SCHEDULING_URL=$(./get-container-urls.sh scheduling_ui)
mcp__playwright__browser_navigate("$SCHEDULING_URL")
```
## Integration with Playwright Tests
### Before Starting Tests:
1. Get container IP address
2. Construct URL
3. Test connectivity
4. Use in Playwright navigate
### Example Test Setup:
```bash
# Get container IP
CONTAINER_NAME="scheduling_ui"
CONTAINER_IP=$(docker inspect -f '{{range .NetworkSettings.Networks}}{{.IPAddress}}{{end}}' "$CONTAINER_NAME")
if [ -z "$CONTAINER_IP" ]; then
echo "❌ Error: Container $CONTAINER_NAME not running"
exit 1
fi
TEST_URL="http://$CONTAINER_IP:80"
echo "Testing URL: $TEST_URL"
# Verify container is reachable
if ! curl -f -s -o /dev/null -m 5 "$TEST_URL/remoteEntry.js"; then
echo "❌ Error: Cannot reach $TEST_URL"
exit 1
fi
echo "✅ Container is reachable"
# Now use in Playwright
echo "Use this URL in Playwright: $TEST_URL"
```
## Common Docker Networks
### StyleMate Network
```bash
# Network name
stylemate_net
# Inspect network
docker network inspect stylemate_net
# List containers on network
docker network inspect stylemate_net --format '{{range .Containers}}{{.Name}} {{end}}'
```
### Getting Network Subnet
```bash
docker network inspect stylemate_net --format '{{range .IPAM.Config}}{{.Subnet}}{{end}}'
# Example output: 172.18.0.0/16
```
## Troubleshooting
### Issue: Container has no IP
**Symptom:** `docker inspect` returns empty IP
**Causes:**
- Container not running
- Container not connected to network
- Container just started (wait a moment)
**Fix:**
```bash
# Check container status
docker ps -a | grep container_name
# Check container networks
docker inspect container_name | grep -A 10 Networks
# Restart contRelated in Cloud & DevOps
appbuilder-action-scaffolder
IncludedCreate, implement, deploy, and debug Adobe Runtime actions with consistent layout, validation, and error handling. Use this skill whenever the user needs to add actions to an App Builder project, understand action structure (params, response format, web/raw actions), configure actions in the manifest, use App Builder SDKs (State, Files, Events, database), deploy and invoke actions via CLI, debug action issues, or implement patterns such as webhook receivers, custom event providers, journaling consumers, large payload redirects, action sequence pipelines, and Asset Compute workers. Also trigger when users mention serverless functions in Adobe context, action logging, IMS authentication for actions, or cron-style scheduled actions.
orchestrating-datacloud
IncludedSalesforce Data Cloud product orchestrator for connect→prepare→harmonize→segment→act workflows. Use this skill when the user needs a multi-step Data Cloud pipeline, cross-phase troubleshooting, or data space and data kit management. TRIGGER when: user needs a multi-step Data Cloud pipeline, asks to set up or troubleshoot Data Cloud across phases, manages data spaces or data kits, or wants a cross-phase sf data360 workflow. DO NOT TRIGGER when: work is isolated to a single phase (use the matching phase-specific skill), the task is STDM/session tracing/parquet telemetry (use observing-agentforce), standard CRM SOQL (use querying-soql), or Apex implementation (use generating-apex).
github-project-automation
IncludedAutomate GitHub repository setup with CI/CD workflows, issue templates, Dependabot, and CodeQL security scanning. Includes 12 production-tested workflows and prevents 18 errors: YAML syntax, action pinning, and configuration. Use when: setting up GitHub Actions CI/CD, creating issue/PR templates, enabling Dependabot or CodeQL scanning, deploying to Cloudflare Workers, implementing matrix testing, or troubleshooting YAML indentation, action version pinning, secrets syntax, runner versions, or CodeQL configuration. Keywords: github actions, github workflow, ci/cd, issue templates, pull request templates, dependabot, codeql, security scanning, yaml syntax, github automation, repository setup, workflow templates, github actions matrix, secrets management, branch protection, codeowners, github projects, continuous integration, continuous deployment, workflow syntax error, action version pinning, runner version, github context, yaml indentation error
sf-datacloud
IncludedSalesforce Data Cloud product orchestrator for connect→prepare→harmonize→segment→act workflows. TRIGGER when: user needs a multi-step Data Cloud pipeline, asks to set up or troubleshoot Data Cloud across phases, manages data spaces or data kits, or wants a cross-phase `sf data360` workflow. DO NOT TRIGGER when: work is isolated to a single phase (use the matching sf-datacloud-* skill), the task is STDM/session tracing/parquet telemetry (use sf-ai-agentforce-observability), standard CRM SOQL (use sf-soql), or Apex implementation (use sf-apex).
fabric-cli
IncludedUse this skill for Fabric.so CLI workflows with the `fabric` terminal command: diagnose/install/login, search or browse a Fabric library, save notes/links/files, create folders, ask the Fabric AI assistant, manage tasks/workspaces, generate shell completion, check subscription usage, produce JSON output, and use Fabric as persistent agent memory. Do not use for Microsoft Fabric/Azure/Power BI `fab`, Daniel Miessler's Fabric framework, Python Fabric SSH, Fabric.js, or textile/fashion fabric.
lark
IncludedLark/Feishu CLI skills: lark-cli operations for docs, markdown, sheets, base, calendar, im, mail, task, okr, drive, wiki, slides, whiteboard, apps, approval, attendance, contact, vc, minutes, event. Use when the user needs to operate Lark/Feishu resources via lark-cli, send messages, manage documents, spreadsheets, calendars, tasks, OKRs, deploy web pages, or any Feishu/Lark workspace operations.