Docker几个疑难问题的最佳实践?


现在我觉得Docker在以下几方面还没有很好的解决方案,但是对应用的部署影响又比较大:
  1. 应用配置的管理,比如API_KEY, 数据库用户名及密码等。如果用环境变量传递,那么在多个应用共享一台主机的情况下,很容易发生泄露。就算是独占主机,用了CAdvisor,Shipyard等集群管理工具后,也会通过HTTP REST API暴露环境变量。另一种方法是通过—env_file或volumes等方式使用host上的配置文件。但这种方式的缺点就是无法享受快速横向扩展的好处。同时对这些配置文件的管理又带来更多的工作。
  2. 容器间不通过LINK方式无法方便的互相访问。见https://github.com/docker/docker/issues/1143
  3. 容器的滚动升级问题,见https://github.com/docker/docker/issues/2733


大家在这几个方面有什么比较好的做法,请指教。
已邀请:

许四两 - 北京数字安全公司运维工程师

赞同来自: 石海旭 xiaolunsanguo


目前以docker项目的进展,等于集装箱好了,还缺码头,缺邮轮运输,缺叉车运送,也看到了docker官方的努力,其它周边也在补充。
1,3点我理解其实就是CI持续继承的问题,创建一个container很简单,持续维护一个container很麻烦,无论是抽象配置,升级镜像在生产环境也会带来风险,尤其是大公司运维和研发完全隔离,运维不敢轻易通过升级镜像来变更配置。
或许以后docker的周边越来越完善,这些问题都可以解决,比如docker1.5.0 可以让根分区只读,这样确保了升级镜像不会因为老container在根中写入临时数据而造成困扰。
我们的想法还是最专业的工具做最专业的事情,puppet的配置管理最专业的,那么配置管理交给它,docker开应用很快隔离性也有保障,它只负责开应用。
2点网络互通问题,可以用linxu桥接方式,我们也在尝试openstack newton方式。

寻觅神迹 - 华为工程师。专注云计算和美食。

赞同来自: hisen_huawei


关于2,有很多解决方案。
比如pipeworks,soketplane,bridge/ovs bridge
关于3,用ambassador似乎是可以解决的呀~

家里网速太满,明天找个环境实验下~~

william - cSphere CEO

赞同来自: BetaCZ


我也来谈谈个人的意见:
1关于配置管理和容器,两者之间的融合费劲。个人的建议是将配置指令分成两类:
a、链接相关的参数,如ip/port/username/passwd
b、调优的参数,比如某个数值从500调整到1000
对于a类,passwd暴露到env中确实从安全角度不科学,非动态业务还是放到配置文件中去简单,如果动态性高的业务放到etcd里。但其实都有点破坏了容器的self-contain 对于b类,对于一般指令建议固化而不要改来改去,很容易故障,实在需要经常修改的使用环境变量传递,配置模版化

但总的来说,docker和cm存在冲突,docker强调闭合,强调immutable。cm强调收敛。这是很大的差异。

3实际上时一个生产环境的应用发布问题,如何在100台机器上批量升级应用?
2是网络问题,可以参考网络虚拟化技术,在一般业务场景,使用物理网桥也可以很好地解决容器通讯问题

henryon - 本人从事系统运维,运维架构相关工作多年。对开源技术有强烈兴趣。

赞同来自:


ansible多docker的支持也不差呀!

BetaCZ - 电信企业IT人

赞同来自:


对于2来说,的确有很多工具可以解决,而且那个issue中也给出了很多方法。但是,都涉及到对应用本身的改造。而且对容器的启动方式、系统的配置方面都有要求。

3的话和ambassador没有关系啊,它是解决跨主机容器互联的问题。我说的是镜像升级后自动进行容器的升级的问题

carson - 90后IT男

赞同来自:


应用配置管理,自动化 ansible

跨主机link 可以使用flannel+k8s解决
ambassador 多部署2个container,通讯方式也是走的外部网络(个人不喜欢)

对于升级container这种方法貌似不太可取(这只是我暂时的想法),container本身是灵活用于的,立刻生成一个运行环境,如果一直保持container不被删除,和之前所使用vm的模式岂不是又一样了。

要回复问题请先登录注册