互联网服务Docker

探讨:docker/compose 中关于 link 的设计怎么样?

compose中,对于link的处理是这样的(以 A -> B 为例 )——A的hosts中写入B的地址,便于地址访问在A中设定B的环境变量,为了避免名字冲突,添加前缀 B_ENV_根据 B 容器对应镜像的 EXPOSE 指令,在A中添加一组 ADDR、PORT 环境变量在A中添加一个环境变量指明B的容器全名称,类似这样: /_A...显示全部

compose中,对于link的处理是这样的(以 A -> B 为例 )——

A的hosts中写入B的地址,便于地址访问在A中设定B的环境变量,为了避免名字冲突,添加前缀 B_ENV_根据 B 容器对应镜像的 EXPOSE 指令,在A中添加一组 ADDR、PORT 环境变量在A中添加一个环境变量指明B的容器全名称,类似这样: /_A_run_1/B

但是试用时速云的时候发现不兼容compose的做法,沟通后的回答是这样的——

我们的确实跟docker compose不一样,不过一个服务的非接口信息,另外一个服务也需要拿到,不知道这个应用场景是什么?这种环境变量应该是那个服务独享吧。在Kubernetes里面没有docker 的 --link 的概念,两个关系紧密的容器可以放到一个Pod里面,通过localhost和共享存储进行通信。

这样就变成了 docker compose 和 k8s 的设计取舍问题,哪个设计更合理呢?

收起
参与10

查看其它 2 个回答zhuhongcheng9的回答

zhuhongcheng9zhuhongcheng9系统架构师58同城

先说说我自己的观点——

docker/compose还不完善,不过方向是对的。

我是从使用者角度看容器之间编排的时候应该使用什么机制,docker/compose的做法是hosts+环境变量,k8s据说是利用 localhost和共享存储,感觉后者的设计不是很好。

有一个大前提,docker是能梳理整条研发线路的技术,凡是能帮助实现这个目标的设计就是好设计(拿集装箱作比较,如果技术仅限于码头到码头,不能上公路,那就是集装箱的失败)。

比如有同学建议用etcd解耦,但是这个要应用自己去etcd读,即要依赖etcd基础设施。这在开发环境中基本是不可能实现的,于是这个解决办法给开发和线上建立了一个壁垒,这不是好主意!

互联网服务 · 2015-10-12
浏览1786

回答者

zhuhongcheng9
系统架构师58同城
擅长领域: 云计算容器Docker

zhuhongcheng9 最近回答过的问题

回答状态

  • 发布时间:2015-10-12
  • 关注会员:3 人
  • 回答浏览:1786
  • X社区推广