需要帮助确定docker compose在构建依赖关系之前尝试启动依赖容器的原因

Question

我希望有人能帮助我理解我在使用WSL2使用Docker Desktop for Windows构建多容器环境时遇到的错误(不要认为这些细节很重要，但你永远不会知道(

我有一个docker-compose.yml脚本，它构建了许多链接在一起的容器。我可以通过注释和取消注释特定容器来让它以一种非常刺耳的方式工作，但根据我的理解，这似乎与docker compose的工作方式相反。

在任何人对使用docker-compose-wait或docker-wait之类的解决方案发表评论之前，这些解决方案的问题是它们在构建过程中运行，我遇到的错误是在构建过程有机会处理之前发生的。

这是我的docker-compose.yml文件：

version: "3.4"
services:
# Redis Service
redis:
build:
context: .
dockerfile: docker/redis/Dockerfile
image: star/redis
container_name: star_redis
restart: unless-stopped
tty: true
ports:
- "16379:6379"
volumes:
- redis_data:/data
db:
build:
context: .
dockerfile: docker/mysql/Dockerfile
image: star/mysql
container_name: star_db
restart: unless-stopped
tty: true
environment:    
RUN_INIT_FILES: ${DOCKER_RUN_MYSQL_INIT}
SERVICE_TAGS: dev
SERVICE_NAME: MySQL
ports:
- "3306:3306"
volumes:
- ${WEB_APP_PATH}${WEB_APP_PROJECT_PATH}/docker/mysql/init:/docker-entrypoint- initdb.d
- star_mysql_db:/var/lib/mysql
app:
build:
context: .
dockerfile: docker/php/Dockerfile
image: star/php
container_name: star_app
restart: unless-stopped
tty: true
environment:
RUNNING_IN_DOCKER: 'true'
SERVICE_NAME: app
SERVICE_TAGS: dev
volumes:
- star_laravel_data:${WEB_DESTINATION_PATH}
depends_on:
- redis
- db

nginx:
build:
context: .
dockerfile: docker/nginx/Dockerfile
image: star/nginx
container_name: star_webserver
restart: unless-stopped
tty: true
environment:
RUNNING_IN_DOCKER: 'true'
ports:
- '80:80'
- '443:443'
- '8888:80'
volumes:
- star_laravel_data:${WEB_DESTINATION_PATH}
depends_on:
- db
- app

phpmyadmin:
image: phpmyadmin/phpmyadmin
container_name: star_phpmyadmin
environment:
PMA_PORT: 3306
PMA_HOST: db
PMA_USER: ####
PMA_PASSWORD: ######
links:
- db:MySQL
ports:
- "8090:80"
restart: unless-stopped
depends_on:
- db
- app
- nginx
package-installer:
image: star/php:latest
container_name: star_installer
restart: on-failure
depends_on:
- db
- app
- nginx
volumes:
- star_laravel_data:${WEB_DESTINATION_PATH}
environment:
APP_ENV: local
CONTAINER_ROLE: installer
CACHE_DRIVER: redis
SESSION_DRIVER: redis
QUEUE_DRIVER: redis
REDIS_HOST: redis
# Scheduler Service
scheduler:
image: star/php:latest
container_name: star_scheduler
restart: on-failure
depends_on:
- db
- app
- nginx
- package-installer
volumes:
- star_laravel_data:${WEB_DESTINATION_PATH}
environment:
APP_ENV: local
CONTAINER_ROLE: scheduler
CACHE_DRIVER: redis
SESSION_DRIVER: redis
QUEUE_DRIVER: redis
REDIS_HOST: redis
# Queue Service
queue:
image: star/php:latest
container_name: star_queue
restart: on-failure
logging:
driver: local
depends_on:
- db
- app
- nginx
- package-installer
volumes:
- star_laravel_data:${WEB_DESTINATION_PATH}
environment:
APP_ENV: local
CONTAINER_ROLE: queue
CACHE_DRIVER: redis
SESSION_DRIVER: redis
QUEUE_DRIVER: redis
REDIS_HOST: redis
volumes:
star_laravel_data:
driver: local
driver_opts:
type: none
o: bind
device: ${WEB_APP_PATH}${WEB_APP_PROJECT_PATH}
star_mysql_db:
portainer_data:
redis_data:
driver: local

所以问题的关键是，如果我运行这个，作为一个新安装，我会从docker compose:得到这个响应

[+] Running 0/3                                                                                                                                                         
- package-installer Error                                                                                                                                              
- scheduler Error                                                                                                                                                      
- queue Error                                                                                                                                                          
Error response from daemon: pull access denied for star/php, repository does not exist or may require 'docker login': denied: requested access to the resource is denied

这些容器都有一个depends_on字段来告诉它们至少需要首先启动其他容器，它们是docker compose尝试构建的第一个容器。对我来说，这毫无意义。它们有depends_on是有原因的，它们使用app容器创建的自定义映像来构建自己的容器。那么，如果他们被告知他们依赖于其他容器，并且他们在脚本的底部，为什么他们是docker compose尝试构建的第一个容器呢？

到目前为止，我唯一有效的解决方案是：

1. 注释掉docker-compose.yml文件中的package-installer、scheduler和queue容器
2. 构建环境
3. 关闭环境
4. 取消对package-installer容器的注释
5. 重新构建环境(因为现在存在自定义star/php映像(
6. 关闭环境
7. 取消对scheduler和queue容器的注释
8. 重建环境。。。再次(因为现在已经添加了通过运行package-installerDockerfile添加的文件(
9. 现在我可以使用环境了

如果这只是我自己的环境，这不会是一个问题，但这个docker堆栈是为我们的开发团队设计的，以便能够使用它。有了这个安装策略，我必须向每个人解释如何对各种包进行注释和取消注释，以使其正常工作。那将是一场噩梦。

根据docker文档，depends_on字段应该按照容器的依赖顺序构建容器，这意味着容器应该按照以下顺序构建：

1. redis
2. 数据库
3. 应用程序
4. nginx
5. phpmyadmin
6. 程序包安装程序
7. 队列/调度程序

同样，我不担心它所依赖的容器是否正在运行，只需要构建它，但它似乎没有这么做，似乎(至少对于三个受影响的容器(直接跳到运行阶段，而不构建依赖关系。

任何有用的见解或提示都将受到欢迎。

Answer 1

dependens_on不会等到其他容器"准备就绪"后才启动，直到它们启动为止。如果需要等待服务就绪，请参阅https://docs.docker.com/compose/startup-order/