前往小程序,Get更优阅读体验!
立即前往
首页
学习
活动
专区
工具
TVP
发布
社区首页 >专栏 >[头脑风暴] 解读Docker Bridge网络模型

[头脑风暴] 解读Docker Bridge网络模型

作者头像
有态度的马甲
发布2020-04-16 15:05:27
7700
发布2020-04-16 15:05:27
举报
文章被收录于专栏:精益码农

背景

这几天在研究Kubernetes, 遇到一个有意思的nodejs镜像:luksa/kubia

代码语言:javascript
复制
# 不带端口映射启动容器
docker  run  -it -d   luksa/kubia
# 连接到默认的Bridge网桥,容器IP是 172.17.0.2

之后,在宿主机使用容器IP和8080 端口可访问该容器nodejs服务

对此我有几个疑问,这几个疑问在我看来有点与我之前对docker 网络的认知相冲突。 Q1. 不是说如果容器没有端口映射,容器内外隔离吗,怎么在宿主机使用容器IP还可以访问? Q2. 使用容器IP:8080可以访问nodejs服务,这个8080从哪里来?

头脑风暴

首先排除一些同事说法:这个容器是以host网络模型连到宿主机,所以可以在宿主机通过容器IP访问。这个新建容器肯定还是连接到默认的bridge网桥上。

  • All containers without a --network specified, are attached to the default bridge network.
  • In terms of Docker, a bridge network uses a software bridge which allows containers connected to the same bridge network to communicate, while providing isolation from containers which are not connected to that bridge network.

对于Q1,我有个误区:没有端口映射,容器内外网络隔离,宿主机是无法访问容器的。 A: 实际上,对于加入同一bridge网桥上的容器,网桥内外网络确实是隔离的,网桥上的容器都可以相互连接。 而我们的宿主机也在这个默认的bridge网桥设备上,其IP地址是网桥设备的网关(172.17.0.1)。

Q3.那端口映射到底起什么作用呢? A:网桥模型确保了网桥内容器可相互访问,但除此网桥之外的网络均不能访问容器, 这也正是bridge网络隔离的效果。 端口映射-p表示容器绑定宿主机的网卡端口来实现转发访问,绑定的网卡决定了你对外暴露的程度。

  1. 绑定宿主机的回环地址127.0.0.1
代码语言:javascript
复制
 docker run -it  -d  -p 127.0.0.1:8080:8080 luksa/kubia

那么在宿主机内只能使用127.0.0.1:8080访问容器

  1. 绑定宿主机的物理地址 10.201.80.126
代码语言:javascript
复制
docker run -it  -d  -p 10.201.80.126:8080:8080 luksa/kubia

那么可使用宿主机物理IP10.201.80.126:8080访问容器,这样局域网机器就能访问到容器了

3. 不写IP,这样会绑定到0.0.0.0,也就是宿主机所有的网卡。

代码语言:javascript
复制
docker run -it  -d  -p 8080:8080 luksa/kubia

很显然,宿主机内回环地址和物理地址均可以访问该容器了。

再回到上面的Q2问题,通过容器IP:8080访问容器,8080是哪里来的?

8080是容器内nodejs进程的监听端口,我们在构建镜像时本就无所谓使用expose指令

The EXPOSE instruction does not actually publish the port. It functions as a type of documentation between the person who builds the image and the person who runs the container, about which ports are intended to be published.

所以在docekr ps时候,并不会在PORTS列显示任何内容,但是通过容器IP可直接连通容器内进程监听端口。

为啥访问容器IP:8080 就可以访问容器内nodejs提供的服务?

这是因为容器镜像在构建的时候,一般在0.0.0.0地址上监听请求,这意味着程序在所有地址的8080端口上监听请求。

这样就延伸出一个有趣的现象,让我们进入容器内部:

代码语言:javascript
复制
 docker exec -it 3cc9f428fc25 bash
 curl 127.0.0.1:8080
 curl 127.0.0.2:8080
 curl 127.0.1:8080
 curl 172.17.0.2:8080
 curl 172.17.2:8080

几个看起来错误的IP竟然也可以访问nodejs服务, 这正是nodejs在http://0.0.0.0:8080地址监听请求的结果。

代码语言:javascript
复制
# 截取自该镜像构建源码:https://github.com/luksa/kubia-qps/blob/master/kubia-qps/app.js
var www = http.createServer(handler);
www.listen(8080);

# nodejs: server.listen([port[, host[, backlog]]][, callback]) api
If host is omitted, the server will accept connections on the unspecified IPv6 address (::) when IPv6 is available, or the unspecified IPv4 address (0.0.0.0) otherwise.

猜想+ 验证+ 源码支持,回应了一开始的几个疑问,对容器Bridge的网络认知进一步加深。

总结输出

  1. bridge网桥内容器通过容器IP相互访问,外部网络隔离
  2. docker run -p 参数通过端口映射,让bridge网桥外网络可以访问容器
  3. 一般情况下,对外提供web服务的docker镜像会在0.0.0.0 地址上监听请求
  • https://en.wikipedia.org/wiki/0.0.0.0
  • https://github.com/luksa/kubia-qps/blob/master/kubia-qps/app.js
  • https://linuxize.com/post/check-listening-ports-linux/
本文参与 腾讯云自媒体同步曝光计划,分享自微信公众号。
原始发表:2020-03-16,如有侵权请联系 cloudcommunity@tencent.com 删除

本文分享自 精益码农 微信公众号,前往查看

如有侵权,请联系 cloudcommunity@tencent.com 删除。

本文参与 腾讯云自媒体同步曝光计划  ,欢迎热爱写作的你一起参与!

评论
登录后参与评论
0 条评论
热度
最新
推荐阅读
目录
  • 背景
  • 头脑风暴
    • 首先排除一些同事说法:这个容器是以host网络模型连到宿主机,所以可以在宿主机通过容器IP访问。这个新建容器肯定还是连接到默认的bridge网桥上。
      • 再回到上面的Q2问题,通过容器IP:8080访问容器,8080是哪里来的?
        • 为啥访问容器IP:8080 就可以访问容器内nodejs提供的服务?
        • 总结输出
        相关产品与服务
        容器服务
        腾讯云容器服务(Tencent Kubernetes Engine, TKE)基于原生 kubernetes 提供以容器为核心的、高度可扩展的高性能容器管理服务,覆盖 Serverless、边缘计算、分布式云等多种业务部署场景,业内首创单个集群兼容多种计算节点的容器资源管理模式。同时产品作为云原生 Finops 领先布道者,主导开源项目Crane,全面助力客户实现资源优化、成本控制。
        领券
        问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档