depends_on Ready Condition
- -
depends_on: alone only waits for container start—service likely not ready yet - Add healthcheck + condition for actual readiness:
depends_on:
db:
condition: service_healthy
- - Without healthcheck defined on target service,
service_healthy fails
Healthcheck start_period
CODEBLOCK1
- -
start_period: initial grace period—health failures don't count during this time - Slow-starting services (databases, Java apps) need adequate start_period
- Without it, container marked unhealthy before it finishes initializing
Volume Destruction
- -
docker compose down preserves volumes - INLINECODE4 DELETES ALL VOLUMES—data loss
- INLINECODE5 often added by habit from tutorials—catastrophic in production
- Named volumes survive
down; anonymous volumes deleted on INLINECODE7
Resource Limits in Development
CODEBLOCK2
- - Set limits during development—catches memory issues early
- Unlimited container can consume all host memory—kills other processes
- Copy limits to production config—don't discover limits in prod
.dockerignore
- - Without it:
node_modules, .git, secrets copied into image - Mirrors
.gitignore syntax—create at same level as Dockerfile - Large build context = slow builds, large images, potential security issues
- At minimum:
.git, node_modules, .env, *.log, build artifacts
Override File Pattern
- -
docker-compose.yml: base config that works everywhere - INLINECODE16 : auto-loaded, development-specific (mounts, ports)
- Production: INLINECODE17
- Keep secrets and environment-specific config in override files, not base
Profiles for Optional Services
CODEBLOCK3
- - Services with profiles don't start by default—cleaner INLINECODE18
- Enable with INLINECODE19
- Use for: test databases, debug tools, mock services, admin interfaces
Environment Variable Precedence
- 1. Shell environment (highest)
- INLINECODE20 file in compose directory
- INLINECODE21 directive
- INLINECODE22 in compose file (lowest for that var)
- -
.env must be exactly .env—.env.local not auto-loaded - Debug with
docker compose config—shows resolved values
depends_on 就绪条件
- - 仅使用 depends_on: 只会等待容器启动——服务很可能尚未就绪
- 添加健康检查 + 条件以实现真正就绪：
yaml
depends_on:
db:
condition: service_healthy
- - 如果目标服务未定义健康检查，service_healthy 会失败
健康检查启动周期
yaml
healthcheck:
test: [CMD, pg_isready]
start_period: 30s
- - start_period：初始宽限期——此期间的健康检查失败不计入
- 启动缓慢的服务（数据库、Java应用）需要足够的启动周期
- 没有它，容器在完成初始化前就会被标记为不健康
卷的销毁
- - docker compose down 会保留卷
- docker compose down -v 会删除所有卷——数据丢失
- -v 常因教程习惯被添加——在生产环境中是灾难性的
- 命名卷在 down 后存活；匿名卷在 down 时被删除
开发中的资源限制
yaml
deploy:
resources:
limits:
memory: 512M
- - 在开发期间设置限制——及早发现内存问题
- 无限制的容器可能消耗所有主机内存——导致其他进程被杀死
- 将限制复制到生产配置——不要在生产环境中才发现限制
.dockerignore
- - 没有它：nodemodules、.git、密钥会被复制到镜像中
- 语法与 .gitignore 类似——在与 Dockerfile 同级目录下创建
- 构建上下文过大 = 构建缓慢、镜像臃肿、潜在安全问题
- 至少忽略：.git、nodemodules、.env、*.log、构建产物
覆盖文件模式
- - docker-compose.yml：适用于所有环境的基础配置
- docker-compose.override.yml：自动加载，开发环境专用（挂载、端口）
- 生产环境：docker compose -f docker-compose.yml -f docker-compose.prod.yml up
- 将密钥和环境特定配置保存在覆盖文件中，而非基础配置
可选服务的配置文件
yaml
services:
mailhog:
profiles: [dev]
- - 带有配置文件的服务默认不会启动——docker compose up 更简洁
- 使用 --profile dev 启用
- 适用于：测试数据库、调试工具、模拟服务、管理界面
环境变量优先级
- 1. Shell 环境（最高）
- Compose 目录中的 .env 文件
- env_file: 指令
- Compose 文件中的 environment:（对该变量而言优先级最低）
- - .env 必须严格命名为 .env——.env.local 不会自动加载
- 使用 docker compose config 调试——显示解析后的值
