docker_compose.yml中links和depends_on的区别

根据Docker Compose的compose-file文档:

  • depends_on表示服务之间的依赖关系。
  • links -链接到另一个服务和表达服务之间的依赖关系中的容器，方法与depends_on相同。

我不明白链接到其他容器的目的，所以两个选项之间的差异对我来说似乎仍然相当困难。

如果有一个例子就容易多了，但我找不到。

我注意到，当我将容器B与容器A连接起来时，容器B将在容器A的外壳中“ping”。

我在容器A的bash中运行ping B，得到如下结果(仅供参考，图片来自互联网)

enter image description here

312633 次浏览
小开

[2016年9月更新]:此答案用于docker合成文件v1(如下例合成文件所示)。对于v2，请参阅@ windsoon的另一个答案。

(原来的答案):

这在文档中很清楚。depends_on决定了容器的依赖关系和创建顺序，而links不仅决定了这些，而且还决定了容器的创建顺序

链接服务的容器将通过与别名相同的主机名(如果没有指定别名，则通过与服务名相同的主机名)可访问。

例如，假设有以下docker-compose.yml文件:

web:
image: example/my_web_app:latest
links:
- db
- cache


db:
image: postgres:latest


cache:
image: redis:latest

使用links， web中的代码将能够使用db:5432访问数据库，假设端口5432暴露在db映像中。如果使用depends_on，这是不可能的，但容器的启动顺序将是正确的。

小开

这个答案适用于docker-compose 版本2，它也适用于版本3

当使用depends_on时，仍然可以访问数据。

如果你查看docker docs Docker编写和Django，你仍然可以像这样访问数据库:

version: '2'
services:
db:
image: postgres
web:
build: .
command: python manage.py runserver 0.0.0.0:8000
volumes:
- .:/code
ports:
- "8000:8000"
depends_on:
- db

links和depends_on之间的区别是什么?

链接:

当你为数据库创建一个容器时，例如:

docker run -d --name=test-mysql --env="MYSQL_ROOT_PASSWORD=mypassword" -P mysql


docker inspect d54cf8a0fb98 |grep HostPort

你可能会发现

"HostPort": "32777"

这意味着您可以从本地主机端口32777(容器中的3306)连接数据库，但每次重新启动或删除容器时，该端口都会改变。因此，您可以使用链接来确保始终连接到数据库，而不必知道它是哪个端口。

web:
links:
- db

depends_on:

我发现一个很好的博客从乔治法拉利Docker-compose。yml:从V1到V2

当docker-compose执行V2文件时，它将自动在文件中定义的所有容器之间构建一个网络，并且每个容器将立即能够引用其他容器，只是使用docker-compose中定义的名称。yml文件。

和

所以我们不再需要链接了;链接用于在db容器和web-server容器之间启动网络通信，但这已经通过docker-compose完成了

更新

依赖于

表达服务之间的依赖关系，这有两个效果:

  • docker-compose up将按依赖顺序启动服务。在下面的例子中，db和redis会在web之前启动。
  • docker-compose up SERVICE将自动包含SERVICE的依赖项。在下面的例子中，docker-compose up web也将创建并启动db和redis。

简单的例子:

version: '2'
services:
web:
build: .
depends_on:
- db
- redis
redis:
image: redis
db:
image: postgres

注意:depends_on在启动web之前不会等待db和redis“就绪”，只会等到它们已经启动。如果您需要等待服务准备就绪，请参阅控制启动顺序以获得有关此问题的更多信息和解决该问题的策略。

小开
最佳答案

在links选项被弃用后，该帖子需要更新。

基本上，links不再需要了，因为它的主要目的是通过添加环境变量使容器可以被另一个容器访问，这隐式地包含在network中。当容器被放置在同一个网络中时，它们可以使用容器名和其他别名作为主机相互访问。

对于docker run， --link也已弃用，应该由自定义网络替换。

docker network create mynet
docker run -d --net mynet --name container1 my_image
docker run -it --net mynet --name container1 another_image

depends_on表示开始顺序(和隐式图像拉取顺序)，这是links的一个很好的副作用。

小开

我认为这个问题的答案需要根据在v1.27.0中首次引入的新的Docker组合规范进行更新，该规范现在允许长形式的depends_on:

https://github.com/compose-spec/compose-spec/blob/master/spec.md#long-syntax-1

在此长表单中，您可以指定希望等待服务启动、正常运行或成功完成。

如果在服务上生成health_check, Docker compose就知道该服务是健康的:

https://github.com/compose-spec/compose-spec/blob/master/spec.md#healthcheck

我建议阅读文档中的示例以获得更多细节，请参阅上面的链接!

举个简单的例子，这是我在集成测试的合成文件中使用的:

services:
cloud-broker:
image: my.docker.registry/activemq-artemis:latest
healthcheck:
test: ["CMD-SHELL", "wget http://localhost:8161/ --delete-after --tries=3 2> /dev/null"]
interval: 10s
timeout: 5s
retries: 5


postgresql:
image: postgres
healthcheck:
test: ["CMD-SHELL", "pg_isready -U postgres"]
interval: 10s
timeout: 5s
retries: 5
environment:
POSTGRES_PASSWORD: "<my-secret>"
POSTGRES_USER: "postgres"
POSTGRES_DB: "postgres"
  

# This service calls a script to create an empty database and the service-user
postgresql-setup:
image: postgres
depends_on:
postgresql:
condition: service_healthy
restart: "no"
volumes:
- "./scripts:/scripts"
environment:
PGPASSWORD: "<my-secret>"
entrypoint: "psql -U postgres -d postgres -h postgresql -f /scripts/create-db.sql"


my-business-service:
image: my.docker.registry/my-business-service:latest
depends_on:
cloud-broker:
condition: service_healthy
postgresql-setup:
condition: service_completed_successfully

提交答案