跳到正文
cccskills
免费在 GitHub 公开

docker-compose

Use this skill when authoring or editing Docker Compose files (compose.yaml / docker-compose.yml), running multi-container stacks, or containerizing a Drupal/PHP application — e.g. "set up a local Drupal stack with nginx and MariaDB", "add Redis to my compose file", "why won't my containers start", "split dev and prod compose configuration". Also trigger for compose commands (up, down, logs, exec, watch) and healthcheck/dependency issues between services.

中文简介正在准备中。当前显示原文说明。

集成工具DockerRedis
查看安装方法

包含的文件(1)

  • SKILL.md5.6 KB

SKILL.md(原文)

安装前可以查看交给 AI 代理的指令内容。

Docker Compose Skill

Docker Compose defines and runs multi-container applications from a single compose.yaml file. This skill covers authoring the file, operating the stack, and structuring configuration for development vs production, with a typical Drupal stack (php-fpm, nginx, MariaDB, Redis) as the working example.


compose.yaml essentials

  • The canonical filename is compose.yaml (docker-compose.yml still works).
  • Do not add a top-level version: key — it is obsolete and ignored by Compose v2; linters flag it.
  • Services, networks, and volumes are declared at the top level.

Drupal stack example

services:
  php:
    build:
      context: .
      dockerfile: docker/php/Dockerfile
    volumes:
      - ./:/var/www/html
      - drupal-files:/var/www/html/web/sites/default/files
    environment:
      DRUPAL_DB_HOST: db
      DRUPAL_DB_NAME: drupal
      DRUPAL_DB_USER: drupal
    env_file:
      - .env
    depends_on:
      db:
        condition: service_healthy
      redis:
        condition: service_started

  web:
    image: nginx:1.27-alpine
    ports:
      - "8080:80"
    volumes:
      - ./:/var/www/html:ro
      - ./docker/nginx/default.conf:/etc/nginx/conf.d/default.conf:ro
    depends_on:
      - php

  db:
    image: mariadb:11.4
    environment:
      MARIADB_DATABASE: drupal
      MARIADB_USER: drupal
      MARIADB_PASSWORD: ${DB_PASSWORD:?set DB_PASSWORD in .env}
      MARIADB_ROOT_PASSWORD: ${DB_ROOT_PASSWORD:?set DB_ROOT_PASSWORD in .env}
    volumes:
      - db-data:/var/lib/mysql
    healthcheck:
      test: ["CMD", "healthcheck.sh", "--connect", "--innodb_initialized"]
      interval: 10s
      timeout: 5s
      retries: 5

  redis:
    image: redis:7-alpine

volumes:
  db-data:
  drupal-files:

Key points illustrated:

  • depends_on with condition: service_healthy — Drupal installs and drush commands fail if the database container is running but not yet accepting connections. A healthcheck plus condition fixes the race.
  • Secrets via ${VAR:?error} — fail fast when required variables are missing instead of starting with empty passwords.
  • Named volume for sites/default/files — keeps user uploads out of the bind-mounted codebase.

Common commands

docker compose up -d              # start stack in background
docker compose up -d --build      # rebuild images first
docker compose down               # stop and remove containers (volumes kept)
docker compose down -v            # ALSO delete named volumes (destroys DB!)
docker compose ps                 # container status + health
docker compose logs -f php        # follow logs of one service
docker compose exec php bash      # shell into running container
docker compose exec php vendor/bin/drush cr   # run drush inside the stack
docker compose run --rm php composer install  # one-off command container
docker compose config             # render the final merged config (debug)
docker compose watch              # sync+rebuild on file changes (dev loop)

Dev vs prod configuration

Compose merges multiple files; later files override earlier ones. compose.override.yaml is loaded automatically for local development:

compose.yaml            # base — shared definition
compose.override.yaml   # dev only — bind mounts, xdebug, exposed ports
compose.prod.yaml       # prod — restart policies, no source bind mount
docker compose up -d                                   # base + override (dev)
docker compose -f compose.yaml -f compose.prod.yaml up -d   # prod set

Use profiles for optional services (e.g. Solr or Mailpit only when needed):

services:
  solr:
    image: solr:9
    profiles: ["search"]
docker compose --profile search up -d

Best practices

  • Pin image tags (mariadb:11.4, not latest) so the stack is reproducible.
  • One process per container; php-fpm and nginx are separate services.
  • Put everything secret in .env (gitignored) and reference with ${VAR}.
  • Add a healthcheck to every service another service depends on.
  • For Drupal, mount the project root once and let nginx mount it read-only.
  • Run docker compose config after edits — it validates and shows the merge result before anything starts.

Troubleshooting

SymptomFix
Drupal install fails with "connection refused" to DBAdd DB healthcheck + depends_on.condition: service_healthy
Changes to compose.yaml have no effectdocker compose up -d again (recreates changed services); check docker compose config
Port already allocatedAnother stack uses the host port — change ports: mapping or docker compose down the other project
Permission errors on sites/default/filesAlign container user UID with host (user: key) or fix volume ownership in entrypoint
Stale vendor/ after switching branchesdocker compose run --rm php composer install
version is obsolete warningDelete the top-level version: key
Database empty after restartYou ran down -v — named volumes were deleted; restore from backup

评价

还没有评价。欢迎分享你的使用感受。

评论

无需登录即可发表。欢迎分享使用感受、提问,或说明在哪些环境下无法运行。

还没有评论。来写第一条吧。

提交后会立即公开。请勿填写邮箱、电话等个人信息。URL 最多 2 个。

0 / 1000 字

此表单受 reCAPTCHA 保护,适用 Google 的隐私权政策和服务条款。

同一仓库的技能

Safe deployment workflow for Drupal 10/11 sites: pre-flight checks, backup, the correct update sequence (composer install, database updates, config import, cache rebuild), verification, and rollback plan. Use when deploying to any environment, releasing to production, or when the user asks to "push changes live", "update the server", or run a release. Also use for multisite releases where each site needs its own database update pass.

中文简介正在准备中。当前显示原文说明。

siva01c/claude-plugins162026年9月26日 更新

Use this skill when running local AI models with Docker Model Runner — the `docker model` CLI — e.g. "run an LLM locally with Docker", "pull a model from the ai/ namespace", "connect my app to a local model", "use a local model as backend for the Drupal AI module", or when wiring the `models:` top-level element into a compose.yaml. Covers pulling/running models, OpenAI-compatible endpoints, and Compose integration.

中文简介正在准备中。当前显示原文说明。

siva01c/claude-plugins162026年9月26日 更新

Use for operational Drupal 11 workflows in DDEV environments, including safe updates, backup-first procedures, and troubleshooting commands.

中文简介正在准备中。当前显示原文说明。

siva01c/claude-plugins162026年9月26日 更新

Use when creating or extending Drupal 11 custom modules, including scaffolding, service architecture, and dependency injection best practices.

中文简介正在准备中。当前显示原文说明。

siva01c/claude-plugins162026年9月26日 更新

Use when auditing Drupal 11 custom modules/themes for security issues such as unsafe input handling, XSS risks, SQL injection, and access control gaps.

中文简介正在准备中。当前显示原文说明。

siva01c/claude-plugins162026年9月26日 更新

dry

免费

DRY (Don't Repeat Yourself) review rules for code reviews: find the same knowledge — a rule, a constant, a parser, a validation, a protocol detail — implemented in several places that must change together, and tell it apart from code that merely looks alike. Use when reviewing a diff, a pull request or recent changes for duplication, on "DRY review", "is this duplicated", "copy-paste check", or when a review checklist asks for DRY. Pair it with the solid skill for design and with owasp-asvs for security.

中文简介正在准备中。当前显示原文说明。

siva01c/claude-plugins162026年9月26日 更新

查看 siva01c 的全部技能

报告此技能的问题