当我仍然需要对地址进行硬编码时，为什么要使用 docker 链接？

Question

您好，我还没有理解以下内容：

-在 docker 世界中，据我了解：

application 公开的端口
容器为应用程序公开的端口
主机映射容器端口的端口

因此在 docker-expose

内的 2 个容器配置中给出这些事实

如果：

app | Host Port | Container Port | App Port

app1    8300         8200            8200
app2    9300         9200            9200

如果 app2 需要直接通过 docker-host 与 app1 通信，我为什么要使用链接，因为我仍然需要在 app2 的环境中进行硬编码app1 的 hostname 和 port（app1 的 container_name 和 app1 的容器的 port）？（在我们的示例中: port=8200 和 host=app1Inst)

 app1:
    image: app1img
    container_name: app1Inst
    ports:
      - 8300:8200    //application code exposes port 8200 - e.g sends to socket on 8200
    networks:
      - ret-net


 app2:
    image: app2img
    container_name: app2Inst
    ports:
      - 9300:9200  
    depends_on:
      - app1
    networks:
      - ret-net
    links:
      - app1

    ///i still need to say here 
    /   environment : -
    /     - host=app1Inst 
   /      - port=8200  --what do i gain using links?

 networks:
ret-net:

Answer 1

简短的回答，不，你不需要链接，它现在在 docker 中被弃用并且不推荐。 https://docs.docker.com/network/links/

话虽如此，由于您的两个容器都在同一网络 ret-net 上，即使没有 ports 设置，它们也能够在所有端口上相互发现和自由通信。

ports 设置对容器的外部访问起作用，例如来自主机。

environment 设置只是在容器内设置环境变量，因此应用程序知道如何找到 app1Inst 和正确的端口 8200。

Answer 2

您不需要在现代 Docker 上使用链接。但是您绝对不应该在任何地方对主机名或端口进行硬编码。（例如，请参阅每个 SO 问题，这些问题指出当运行直接在开发人员系统上时，您可以作为 localhost 与服务交互，但当运行在 Docker 中时，您需要一些其他主机名.). docker-compose.yml 文件是部署时配置，是设置从一项服务指向另一项服务的环境变量的好地方。

正如您在提议的 docker-compose.yml 文件中所指出的，Docker 网络和相关的 DNS 服务基本上完全取代了链接。链接最初存在，但不再有用。

另请注意，Docker Compose 将为您创建一个默认网络，并且 docker-compose.yml 文件中的服务块名称作为主机名是有效的。您可以将该文件缩减为：

version: '3'
services:
  app1:
    image: app1img
    ports:
      - '8300:8200'
  app2:
    image: app2img
    ports:
      - '9300:9200'
    env:
      APP1_URL: 'http://app1:8200'
    depends_on:
      - app1

当我仍然需要对地址进行硬编码时，为什么要使用 docker 链接？

Why would i use docker links when i still need to hardcode the address?

docker

docker-compose

docker-link