docker_compose.yml 中的 links 和 depends_on 的区别

Question

根据 Docker Compose 的compose-file documentation：

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

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

如果有例子会容易得多，但我找不到任何例子。

我注意到，当我将容器 B 与容器 A 链接时，容器 B 将在容器 A 的外壳内“可ping”。

我在容器A的bash里面跑ping B得到了这样的结果（仅供参考，图片来自网络）

Answer 1

此答案适用于 docker-compose version 2，它也适用于 version 3

您仍然可以在使用 depends_on 时访问数据。

如果您查看 docker docs Docker Compose and 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

取决于：

我发现 Giorgio Ferraris Docker-compose.yml: from V1 to V2 的一个不错的博客

当 docker-compose 执行 V2 文件时，它会自动在文件中定义的所有容器之间建立一个网络，每个容器都可以立即使用 docker-compose 中定义的名称来引用其他容器。 yml 文件。

和

所以我们不再需要链接了；链接用于启动我们的数据库容器和我们的网络服务器容器之间的网络通信，但这已经由 docker-compose 完成

更新

depends_on

表达服务之间的依赖关系，有两个作用：

• 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 “准备好” - 仅在它们启动之前。如果您需要等待服务准备好，请参阅控制启动顺序以了解有关此问题的更多信息以及解决此问题的策略。

Answer 2

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的一个很好的副作用。

Answer 3

[2016 年 9 月更新]：此答案适用于 docker compose file v1（如下面的示例 compose 文件所示）。对于 v2，请参阅 @Windsooon 的另一个答案。

[原答案]：

在文档中很清楚。 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，这是不可能的，但是容器的启动顺序是正确的。

Answer 4

我认为这个问题的答案需要根据 v1.27.0 中首次引入的新 Docker compose 规范进行更新，该规范现在允许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

我建议阅读文档中的示例以了解更多详细信息，请参阅上面的链接！

举个简单的例子，这是我在 compose 文件中用于集成测试的内容：

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