作者：民工肖某
目前Openstack和Docker都是各自领域很火的项目。关于Docker的背景，其实算是很有故事的。docker的老东家叫dotcloud，它开始是做stack的paas，用的就是container容器的技术.因为它们费了很多功夫去兼容了多个语言的版本，sandbox也用得炉火纯青，但对于容器本身的弊端却有些无可奈何。因为从 技术底层看，差异并不明显，都有考虑namespace/cgroup内核模块的共享、AUFS文件系统，关键的差异是对应用stack的统一，和对应用分发、部署的管理，因为这块container技术本身没有太多的规划。所以，如果说container在应用领域并不算杀手级应用，那么Docker的出现，将彻底改变这种局面，成为container在应用上的极具竞争力的标志。
说了这么多docker的赞美，理想很美好，现实很残酷。从openstack和docker集成的方案和进展看，还是很有挑战性的：
- 1. 两种典型的集成方案。
一是通过Nova-API，docker driver作为hypervisor部署。原理很好理解，nova-computer-api调用virt api 将nova docker driver作为http agent和docker rest api互通，从而控制docker和与容器的通信。另外，glance作为docker register服务的本地节点，提供image服务。同时一些问题也出现了，docker作为hypervisor方案简单，但社区在I版本已将把这个项目移出了主版本，放到stack forge中单独发展，所以近期来说，主版本merge的可能性不大。社区另外一种考虑，是单独将container service做成和裸机bare metal、vm同级别的模板，这或许会是更好的选择；
二是通过Heat组件来实现。利用heat来管理docker的资源模板，这样可以避免Nova仅仅在hypervisor层面对docker管理的限制，比如一些docker本身构建的能力，或是docker容器之间的网络管理等。heat的优势是对资源的协调，不仅有虚拟化的资源，还有更多和docker环境构建、集成和交付的内容。通过heat的管理，可以调用docker remote api，这是较nova调度更为丰富的容器资源。
- 2. 针对不同的集成方案。openstack最大的挑战还是如何定位docker的能力，从应用域来看，docker本身上生产系统的稳定性还是个问号，比如namespace中chroot的user控制权限，在云平台上如何针对tenant开放，而不被user在container渗透到kernel去逃逸；另外cgroup中对磁盘IO读写的配额，引入到NFS后，怎样实现配额管理，基于tenant，就必须事先定义，引入第3方的管理工具；如果动态管理，就很难控制写的能力，毕竟container不是做资源虚拟化的；
总之，很多问题其实是docker本身的问题，安全、网络都是目前的短板，那只有docker自身的改善，以及与openstack定制化的结合，才有可能尽快推动docker在生产系统上线的可能。现在，比较靠谱的做法，是1个vm中创建1套docker，针对应用进行差异化的部署；而且，这种方式如果部署在CI/CD领域，也是有一定借鉴性的，比如代码在docker中的快速构建及销毁，以及job提交后的分组测试等；
综合这些考虑，docker会在不断地应用领域逐步强壮起来，openstack作为兼容性及功能性最强的云平台，也一定和在docker集成方面有更出色的表现，我们拭目以待。
