在链接选项被弃用后，帖子需要更新。

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

对于docker运行，——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表示开始顺序(以及隐式图像拉取顺序)，这是链接的一个很好的副作用。

在链接选项被弃用后，帖子需要更新。

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

对于docker运行，——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表示开始顺序(以及隐式图像拉取顺序)，这是链接的一个很好的副作用。

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

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

如果你看看docker docs docker Compose和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:

我从Giorgio Ferraris Docker-compose找到了一个不错的博客。yml:从V1到V2

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

And

所以我们不再需要链接了;链接用于在db容器和web-server容器之间启动网络通信，但这已经通过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“就绪”，只会等到它们已经启动。如果您需要等待服务准备就绪，请参阅控制启动顺序以获得有关此问题的更多信息和解决该问题的策略。

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

(原来的答案):

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

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

例如，假设下面的docker-compose。yml文件:

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

db:
  image: postgres:latest

cache:
  image: redis:latest

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

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

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

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

Docker compose知道一个服务是健康的，如果你在该服务上生成health_check:

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