在 Compose 中控制启动和关闭顺序
目录
您可以使用
depends_on 属性来控制服务的启动和关闭顺序。Compose 始终按照依赖顺序启动和停止容器,其中依赖关系由
depends_on、links、volumes_from 和 network_mode: "service:..." 确定。
一个很好的使用场景是需要访问数据库的应用程序。如果两个服务都以 docker compose up 启动,则可能会失败,因为应用程序服务可能在数据库服务之前启动,从而找不到能够处理其 SQL 语句的数据库。
控制启动
启动时,Compose 不会等待容器“就绪”,只会等待其运行。这可能会导致问题,例如,如果您有一个关系型数据库系统,它需要先启动自己的服务才能处理传入的连接。
检测服务就绪状态的解决方案是使用 condition 属性,并搭配以下选项之一:
service_startedservice_healthy. 这表示在启动依赖服务之前,预期某个依赖项处于“健康”状态,该状态由healthcheck定义。service_completed_successfully. 这表示依赖项预期在启动依赖服务之前成功运行完成。
示例
services:
web:
build: .
depends_on:
db:
condition: service_healthy
restart: true
redis:
condition: service_started
redis:
image: redis
db:
image: postgres
healthcheck:
test: ["CMD-SHELL", "pg_isready -U ${POSTGRES_USER} -d ${POSTGRES_DB}"]
interval: 10s
retries: 5
start_period: 30s
timeout: 10sCompose 按依赖顺序创建服务。db 和 redis 在 web 之前创建。
Compose 会等待标记为 service_healthy 的依赖项通过健康检查。db 在创建 web 之前,预期状态为“健康”(由 healthcheck 指示)。
restart: true 确保如果 db 因显式的 Compose 操作(例如 docker compose restart)而被更新或重启,则 web 服务也会自动重启,从而确保其正确重新建立连接或依赖关系。
db 服务的健康检查使用 pg_isready -U ${POSTGRES_USER} -d ${POSTGRES_DB}' 命令来检测 PostgreSQL 数据库是否已就绪。该服务每 10 秒重试一次,最多重试 5 次。
Compose 还会按依赖顺序移除服务。web 在 db 和 redis 之前被移除。