今天闲暇看了一下宏亮同学写的一篇《 Docker的大坑小洼》,非常受启发。因为Docker的文章真的很多了,但大家如果只是玩一玩,有很多坑是不会碰到的。通读完宏亮同学的列出来的坑之后,我发现可能是角度不同,我有一些不同的理解,借此机会分享给大家:
1.Docker中同种类型不同tag的镜像并非可互相替代
这个问题描述的挺绕的,看了好几遍才理解笔者的问题。意思就是不同版本的Mysql镜像不能混用。用户的环境如果想依赖不同版本Mysql镜像,一定要在测试一遍,因为镜像变了,内容也变了。所以我更认为这是使用方法的问题, 不是Docker的坑。
2.不同时间段使用tag为latest的镜像,效果不尽相同
这个是Docker设计成这样,在分布式计算中,自动升级镜像后是无法知道下次启动的job会启动那个镜像。所以增加了这个设计。我认为还是使用方法的问题, 不是Docker的坑。或者说,掌握最佳实践,如宏亮说的,不要用latest tag。
3.使用fig部署依赖性强的容器时出错
我在实际使用fig做开发是也遇到这个问题,我觉得fig就是一个不可用的工具。如果你大量使用fig会知道我想吐槽。目前还不如直接Build。
4.Swarm管理多个Docker Node时,Docker Node注册失败
我没有用过,没法发表意见。
5.Docker容器的DNS问题
这个坑有点冤枉Docker,设计成这样了。但到了中国,确实变成了坑。实际使用中,不要用Docker镜像去访问外网的内容,最好做到本地访问。
3 个回复
bnuhero - 读书喝茶踢球写程序
赞同来自: dockerone
第一个:不同tag的镜像不能想当然地视为等同。我也觉得这不是问题,同一个git代码仓库中,标记为不同tag的代码往往也有很大差别。
第二个:latest标签这个名字确实有很大的误导性,应当避免使用。 英文博客, 中文翻译
管理多个Docker Host,我使用的是Mesos,暂时没用swarm。
苦逼少侠
赞同来自: wangzi19870227
大部分见解一致,关于docker-compose(fig),我觉得没那么糟糕,当你有几十个系统,依赖关系错综复杂时,docker-compose(fig)是挺好的选择。
对于docker-compose(fig)服务依赖的问题,我自己是这么解决的:
在容器启动时,执行下面的脚本来检测links是否都已经启动了,都启动后自己才启动。
最后等待这部分可以视情况是否需要:wait links init themself, like mysql import sql。
扁豆焖面先生
赞同来自:
Docker 组件实例:
http://www.tudou.com/plcover/Ica4-YYZ-r0/