0

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

docker-根据我的理解，我们拥有的世界：

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

因此，在 2 个容器的配置中给出这些事实docker-expose

如果：

app | Host Port | Container Port | App Port

app1    8300         8200            8200
app2    9300         9200            9200

如果需要通过直接app2与通信进行通信，我为什么要使用链接，因为我仍然必须在（容器的和容器的容器名称）的环境中以某种方式进行硬编码？（在 我们的示例中：和）app1docker-hostapp2hostnameportapp1app1portapp1port=8200host=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:
4

2 回答 2

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
于 2018-12-13T20:47:36.060 回答
1

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

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

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

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

于 2018-12-13T20:45:46.937 回答