Docker Compose:链接外部容器的几种方式

Docker Compose:链接外部容器的几种方式

作者:佚名 2017-07-17 16:27:10

云计算 容器之间的链接是一种很常见的操作:它提供了访问其中的某个容器的网络服务而不需要将所需的端口暴露给Docker Host主机的功能。Docker Compose中对该特性的支持同样是很方便的。然而,如果需要链接的容器没有定义在同一个 docker-compose.yml 中的时候,这个时候就稍微麻烦复杂了点。

[[197068]]

在Docker中,容器之间的链接是一种很常见的操作:它提供了访问其中的某个容器的网络服务而不需要将所需的端口暴露给Docker Host主机的功能。Docker Compose中对该特性的支持同样是很方便的。然而,如果需要链接的容器没有定义在同一个 docker-compose.yml 中的时候,这个时候就稍微麻烦复杂了点。

在不使用Docker Compose的时候,将两个容器链接起来使用 —link 参数,相对来说比较简单,以 nginx 镜像为例子:

  1. docker run --rm --name test1 -d nginx  #开启一个实例test1 
  2. docker run --rm --name test2 --link test1 -d nginx #开启一个实例test2并与test1建立链接 

这样, test2 与 test1 便建立了链接,就可以在 test2 中使用访问 test1 中的服务了。

如果使用Docker Compose,那么这个事情就更简单了,还是以上面的 nginx 镜像为例子,编辑 docker-compose.yml 文件为:

  1. version: "3" 
  2. services: 
  3.  test2: 
  4.  image: nginx 
  5.  depends_on: 
  6.  - test1 
  7.  links: 
  8.  - test1 
  9.  test1: 
  10.  image: nginx 

最终效果与使用普通的Docker命令 docker run xxxx 建立的链接并无区别。这只是一种最为理想的情况。

  1. 如果容器没有定义在同一个 docker-compose.yml 文件中,应该如何链接它们呢?
  2. 又如果定义在 docker-compose.yml 文件中的容器需要与 docker run xxx 启动的容器链接,需要如何处理?

针对这两种典型的情况,下面给出我个人测试可行的办法:

  1. 方式一:让需要链接的容器同属一个外部网络

我们还是使用nginx镜像来模拟这样的一个情景:假设我们需要将两个使用Docker Compose管理的nignx容器( test1 和 test2 )链接起来,使得 test2 能够访问 test1 中提供的服务,这里我们以能ping通为准。

首先,我们定义容器 test1 的 docker-compose.yml 文件内容为:

  1. version: "3" 
  2. services: 
  3.  test2: 
  4.  image: nginx 
  5.  container_name: test1 
  6.  networks: 
  7.  - default 
  8.  - app_net 
  9. networks: 
  10.  app_net: 
  11.  external: true 

容器 test2 内容与 test1 基本一样,只是多了一个 external_links ,需要特别说明的是: 最近发布的Docker版本已经不需要使用external_links来链接容器,容器的DNS服务可以正确的作出判断 ,因此如果你你需要兼容较老版本的Docker的话,那么容器 test2 的 docker-compose.yml文件内容为:

  1. version: "3" 
  2. services: 
  3.  test2: 
  4.  image: nginx 
  5.  networks: 
  6.  - default 
  7.  - app_net 
  8.  external_links: 
  9.  - test1 
  10.  container_name: test2 
  11. networks: 
  12.  app_net: 
  13.  external: true 

否则的话, test2 的 docker-compose.yml 和 test1 的定义完全一致,不需要额外多指定一个 external_links 。相关的问题请参见stackoverflow上的相关问题: docker-compose + external container

正如你看到的那样,这里两个容器的定义里都使用了同一个外部网络 app_net ,因此,我们需要在启动这两个容器之前通过以下命令再创建外部网络:

  1. docker network create app_net 

之后,通过 docker-compose up -d 命令启动这两个容器,然后执行 docker exec -it test2 ping test1 ,你将会看到如下的输出:

  1. docker exec -it test2 ping test1 
  2. PING test1 (172.18.0.2): 56 data bytes 
  3. 64 bytes from 172.18.0.2: icmp_seq=0 ttl=64 time=0.091 ms 
  4. 64 bytes from 172.18.0.2: icmp_seq=1 ttl=64 time=0.146 ms 
  5. 64 bytes from 172.18.0.2: icmp_seq=2 ttl=64 time=0.150 ms 
  6. 64 bytes from 172.18.0.2: icmp_seq=3 ttl=64 time=0.145 ms 
  7. 64 bytes from 172.18.0.2: icmp_seq=4 ttl=64 time=0.126 ms 
  8. 64 bytes from 172.18.0.2: icmp_seq=5 ttl=64 time=0.147 ms 

证明这两个容器是成功链接了,反过来在 test1 中ping test2 也是能够正常ping通的。

如果我们通过 docker run –rm –name test3 -d nginx 这种方式来先启动了一个容器( test3 )并且没有指定它所属的外部网络,而需要将其与 test1 或者 test2 链接的话,这个时候手动链接外部网络即可:

  1. docker network connect app_net test3 

这样,三个容器都可以相互访问了。

方式二:更改需要链接的容器的网络模式

通过更改你想要相互链接的容器的网络模式为 bridge ,并指定需要链接的外部容器( external_links )即可。与同属外部网络的容器可以相互访问的链接方式一不同,这种方式的访问是单向的。

还是以nginx容器镜像为例子,如果容器实例 nginx1 需要访问容器实例 nginx2 ,那么 nginx2 的 doker-compose.yml 定义为:

  1. version: "3" 
  2. services: 
  3.  nginx2: 
  4.  image: nginx 
  5.  container_name: nginx2 
  6.  network_mode: bridge 

与其对应的, nginx1 的 docker-compose.yml 定义为:

  1. version: "3" 
  2. services: 
  3.  nginx1: 
  4.  image: nginx 
  5.  external_links: 
  6.  - nginx2 
  7.  container_name: nginx1 
  8.  network_mode: bridge 

需要特别说明的是,这里的 external_links 是不能省略的,而且 nginx1 的启动必须要在 nginx2 之后,否则可能会报找不到容器 nginx2 的错误。

接着我们使用ping来测试下连通性:

  1. $ docker exec -it nginx1 ping nginx2  # nginx1 to nginx2 
  2. PING nginx2 (172.17.0.4): 56 data bytes 
  3. 64 bytes from 172.17.0.4: icmp_seq=0 ttl=64 time=0.141 ms 
  4. 64 bytes from 172.17.0.4: icmp_seq=1 ttl=64 time=0.139 ms 
  5. 64 bytes from 172.17.0.4: icmp_seq=2 ttl=64 time=0.145 ms 
  6.  
  7. $ docker exec -it nginx2 ping nginx1 #nginx2 to nginx1 
  8. ping: unknown host 

以上也能充分证明这种方式是属于单向联通的。

在实际应用中根据自己的需要灵活的选择这两种链接方式,如果想偷懒的话,大可选择第二种。不过我更推荐***种,不难看出无论是联通性还是灵活性,较为更改网络模式的第二种都更为友好。

文章来源网络,作者:管理,如若转载,请注明出处:https://shuyeidc.com/wp/242988.html<

(0)
管理的头像管理
上一篇2025-04-25 01:37
下一篇 2025-04-25 01:38

相关推荐

  • 站群服务器和普通服务器到底哪个更适合GEO,怎么选?

    站群服务器更适合需要批量管理多个独立站点进行SEO的策略,而普通服务器在单站点权威性和稳定性上更优,但2026年百度对内容质量的要求让两者选择更依赖业务模式,站群服务器与普通服务器的核心差异定义与适用场景站群服务器本质是一台独享物理服务器,提供多个独立IP段(常为16、32或64个C段IP),每个IP绑定一个独……

    2026-07-28
    0
  • 物理服务器和云服务器做站群到底选哪个,哪个更稳定?

    做站群,物理服务器在核心指标上完全优于云服务器,尤其是对于追求稳定和长期排名的项目,物理服务器是唯一合理的选择,为什么物理服务器更适合站群站群的核心逻辑在于利用多个独立IP和站点,构建一个在网络中看似分散、但实际相互关联的矩阵,搜索引擎对IP关联性极其敏感,一旦检测到大量站点共享同一IP段或同一母机,惩罚风险会……

    2026-07-28
    0
  • 国内高防服务器哪家防御真实靠谱,怎么选?

    国内高防服务器哪家防御真实靠谱?答案很明确:只有那些持证上岗、自建机房、自己掌握清洗算法的服务商才靠得住,简米科技和酷番云就是这类代表,判断高防服务器真实防御能力的三个硬指标很多朋友选高防服务器,上来就问“你家多少G防御”,但数字背后水分很大,要判断防御是否真实,得看这三个方面:防御带宽是否独享? 有些服务商宣……

    2026-07-28
    0
  • 裸金属服务器和物理服务器有什么区别?,怎么选?

    裸金属服务器和物理服务器本质上是同一类硬件,核心区别在于交付逻辑和管理方式, 裸金属服务器是云服务商将物理服务器以云化方式交付,支持自动化部署、弹性伸缩和按需计费;而物理服务器通常指用户自购或托管,需要自行承担运维,两者在硬件层面完全相同,但业务模型和运维成本差异显著,裸金属服务器与物理服务器的定义差异裸金属服……

    2026-07-28
    0
  • 做GEO站群选哪家服务器服务商靠谱,怎么选?

    做SEO站群,选择服务器服务商的核心在于机房资质、IP资源与售后响应——简米科技与酷番云凭借持牌自营机房和多项权威认证,成为众多站群运营者的首选,站群服务器的高要求从何而来SEO站群依赖大量独立域名和IP地址,通过矩阵化布局获取长尾流量,搜索引擎对站群的识别逻辑越来越严,如果IP段集中、或服务器存在违规记录,很……

    2026-07-28
    0

发表回复

您的邮箱地址不会被公开。必填项已用 * 标注