ln-783-container-launcher
Builds and launches Docker containers with health verification. Use when validating that containerized services start correctly.
What this skill does
> **Paths:** File paths (`references/`, `../ln-*`) are relative to this skill directory. # ln-783-container-launcher **Type:** L3 Worker **Category:** 7XX Project Bootstrap --- ## Purpose Builds Docker images, launches containers, and performs comprehensive health verification using Docker native health checks and retry strategies. **Scope:** - Detect and validate docker-compose.yml configuration - Build Docker images - Launch containers with proper startup order - Verify container health using native health checks - Provide access URLs and cleanup instructions **Out of Scope:** - Building application code (handled by ln-781) - Running tests (handled by ln-782) - Container orchestration beyond single host (Kubernetes, Swarm) --- ## When to Use | Scenario | Use This Skill | |----------|---------------| | Standalone-capable | Yes | | Standalone container launch | Yes | | Development environment setup | Yes | | Production deployment | No, use proper CI/CD | --- ## Workflow ### Step 1: Pre-flight Checks Verify Docker environment readiness. | Check | Failure Action | |-------|---------------| | Docker daemon running | Report error with installation instructions | | Docker Compose available | Report error, suggest installation | | Compose file exists | Report error, list expected locations | | Required ports free | Report conflict, suggest alternatives | | Sufficient disk space | Warn if low space (<2GB free) | ### Step 2: Parse Compose Configuration Extract service information from docker-compose.yml. | Information | Purpose | |-------------|---------| | Service names | Track which containers to monitor | | Exposed ports | Know which ports to check | | Health check definitions | Use native health checks if defined | | Dependencies (depends_on) | Understand startup order | | Volume mounts | Verify paths exist | ### Step 3: Build Images Build all images defined in compose file. | Aspect | Strategy | |--------|----------| | Build context | Use paths from compose file | | Build args | Pass through from compose configuration | | Cache | Use Docker layer cache for speed | | Failure | Report build errors with full log | ### Step 4: Launch Containers Start containers with proper orchestration. | Aspect | Strategy | |--------|----------| | Startup order | Respect depends_on and healthcheck conditions | | Detached mode | Run in background | | Network | Use compose-defined networks | | Volumes | Mount all defined volumes | ### Step 5: Health Verification Verify all containers are healthy using appropriate strategy. **Strategy Selection:** | Condition | Strategy | |-----------|----------| | Service has `healthcheck:` in compose | Use native Docker health status | | Service has `depends_on: condition: service_healthy` | Wait for Docker health status | | No healthcheck defined | Use external HTTP probe with retry | **Retry Configuration:** | Parameter | Value | Rationale | |-----------|-------|-----------| | Max attempts | 10 | Allow slow-starting services | | Initial delay | 5s | Give containers time to start | | Backoff | Exponential (5, 10, 20, 40s) | Avoid overwhelming services | | Max total wait | 120s | Reasonable upper limit | **Health Check Methods:** | Method | When to Use | |--------|------------| | Docker health status | When container has healthcheck defined | | HTTP GET to exposed port | For web services without healthcheck | | Container exec | For services without exposed ports | | TCP port check | For databases and message queues | ### Step 6: Report Results Return structured results to orchestrator. **Result Structure:** | Field | Description | |-------|-------------| | containers | Array of container status objects | | healthChecks | Array of health check results | | accessUrls | Map of service name to access URL | | overallStatus | healthy / unhealthy / partial | | startupDuration | Time from launch to all healthy | **Container Status Object:** | Field | Description | |-------|-------------| | name | Container name | | service | Service name from compose | | status | running / exited / restarting | | health | healthy / unhealthy / starting / none | | port | Exposed port (if any) | | startedAt | Container start timestamp | **Health Check Result:** | Field | Description | |-------|-------------| | url | Checked URL or endpoint | | status | HTTP status code or check result | | responseTime | Time to respond in ms | | healthy | Boolean health status | --- ## Error Handling | Error Type | Action | |------------|--------| | Docker daemon not running | Report with start instructions | | Port already in use | Report conflict, suggest docker compose down first | | Image build failed | Report with build logs | | Container exited | Report with container logs | | Health check timeout | Report with last known status and logs | | Network unreachable | Check Docker network configuration | --- ## Options | Option | Default | Description | |--------|---------|-------------| | keepRunning | true | Leave containers running after verification | | stopAfter | false | Stop containers after successful verification | | healthTimeout | 120 | Max seconds to wait for healthy status | | showLogs | true | Show container logs on failure | | buildFirst | true | Build images before starting | | pullLatest | false | Pull base images before build | --- ## Cleanup Instructions Provide user with cleanup commands in report. | Action | Description | |--------|-------------| | Stop containers | Stop running containers, preserve data | | Remove containers and networks | Clean up containers but keep volumes | | Remove everything | Full cleanup including volumes and images | --- ## Critical Rules 1. **Use native health checks when available** - more reliable than external probes 2. **Implement retry with backoff** - services need time to initialize 3. **Always collect logs on failure** - essential for debugging 4. **Parse compose file for ports** - do not hardcode port numbers 5. **Respect depends_on order** - critical for database-dependent services ### Monitor Integration (Claude Code 2.1.98+) **MANDATORY READ:** Load `references/monitor_integration_pattern.md` For container health verification, use `Monitor` to stream container logs: | Pattern | Command | timeout_ms | |---------|---------|------------| | Readiness signal | `docker compose logs -f 2>&1 \| grep --line-buffered -iE 'ready\|listening\|healthy\|started'` | `healthTimeout * 1000` | | Error watch | `docker compose logs -f 2>&1 \| grep --line-buffered -iE 'error\|fatal\|panic\|exit'` | `healthTimeout * 1000` | Use `persistent: true` if `keepRunning` is true and ongoing log monitoring is needed. Fallback: if Monitor is unavailable, use retry loop with `sleep` + `curl` health check. --- ## Definition of Done - [ ] Docker environment verified - [ ] All images built successfully - [ ] All containers running - [ ] All health checks passing - [ ] Access URLs provided - [ ] Results returned to orchestrator --- ## Reference Files - Parent: `../ln-780-bootstrap-verifier/SKILL.md` --- **Version:** 2.0.0 **Last Updated:** 2026-01-10
Related 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.