- 场景
- 任务
- 想法
- 分析
- 概念与选型
- 小试身手
- 环境说明
- 注意事项
- 动手做
- 测试
- 引文
公司微服务快上线了，微服务都是用Docker容器进行部署的，在同一台主机下，把服务都部署上，注册到Nacos的IP与PORT都是内网的IP与Dockerfile中定义的端口号，看起来好像也没什么问题，通过网关去调用也是可以调通的，请注意这有一个大前提：
必须把所有服务容器部署在同一台主机上时才可以！
当服务实例没有部署在同一主机上，比如网关服务在A服务器，服务a在B服务器上，同样注册到Nacos (或其它注册中心) ，此时上报上来的都是内网的IP，那么当外部有请求进来的时候，网关通过Nacos的服务列表，找到了对应的服务a的内网IP，一调用发现调用不通
ps:内网怎么会通……
任务微服务容器可以不在同一台服务器上，互相调用
想法- 既然上报的是内网的IP，我直接让他上报宿主机的IP和端口呗
- 使用Docker的host网络模式
- 修改部署脚本，通过shell部署容器时，获取宿主机IP与设置的映射端口号
- 让Docker的网络互通
以下分别按上边的“想法”部分来进行说明下问题
1.翻遍官方文档与Github，得出的方案又有两个：
- 固定IP端口，把宿主机IP与端口写死在配置文件中：看起来是解决了，但是问题是无法水平扩展了 ——勉强能用
- 固定网卡，防止因多网卡环境上报错误IP端口：没有用的，进入容器中
ifconfig发现内部网卡只有两个，分别是eth0与lo，对应网卡的IP就是内网IP ——还是没用
2.使用Docker的Host网络模式，你会发现IP这回上报的的确是宿主机IP，但是端口号不对啊……如果自己去通过shell使用Java参数传入待映射的端口号的话，这种情况理论上是可行的，唯一缺点是docker ps 再也直接看不到端口号了，需要额外去docker inspect ——可以用
3.映射端口号可以获取，但是主机的网卡名称不同，写死后不灵活，如果有的是eth0，有的是ens33呢？还有更多不可测的情况！ ——或许可用
4.通过一些成熟的Docker容器网络共享，但是会有一定的性能损耗 ——完全可用
概念与选型最稳妥的办法——使用Docker网络共享，在搜索引擎的帮助下，我决定用Overlay的方式来实现效果
以下简单说下Overlay：
容器在两个跨主机进行通信的时候，是使用overlay network这个网络模式进行通信；如果使用host也可以实现跨主机进行通信，直接使用这个物理的ip地址就可以进行通信。overlay它会虚拟出一个网络比如10.0.2.3这个ip地址。在这个overlay网络模式里面，有一个类似于服务网关的地址，然后把这个包转发到物理服务器这个地址，最终通过路由和交换，到达另一个服务器的ip地址。
想要实现Overlay网络，需要引入一个K-V数据库，来保存网络状态信息，包括 Network、Endpoint、IP 等。Consul、Etcd 和 ZooKeeper 都是 Docker 支持的K-V数据库
我们这里使用 Consul，相比其它K-V数据库，Consul提供的界面化方便管理，所以这里使用Consul实现Overlay
通过让每个服务器的Docker daemon将自己的IP注册到Consul中，来共享Docker内网，这里共享的内网是Overlay网络模式的，也只有在注册的Docker环境下使用同overlay网络的容器，才能互相通讯
ps: 创建完成后，不使用overlay网络的跨服务器容器，不能ping通
小试身手单节点的Consul实现Overlay网络，使用Docker镜像
环境说明
本测试环境适用于Systemd管理的Linux发行版
Consul没有使用非官方的progrium/consul，主要是因为这个镜像实在太老了，四年前的如果有漏洞也没能及时修复，所以自己去<hub.docker.com>去趟了遍官方的坑！
欢迎分享，转载请注明来源：内存溢出
微信扫一扫
支付宝扫一扫
评论列表（0条）