请教 Docker 正确的使用姿势...

Docker是个好东西,能用极少的系统资源消耗获得一个干净的系统.
但是Docker同时让人感到困惑.
看上去官方的推荐用法是一个Docker运行一个服务,多个Docker联合组成一个对外的应用.

例如:
使用Dockerfile构建
Web, DB, Nginx三个服务分别分布在3个Docker镜像.
通过卷挂载的形式,把外部的数据引入到容器中实现数据持久化.
运行容器,并使用内部互连的方式实现数据交互.容器之间只有网络对接.
各个子系统间实现高度的隔离与解耦.

很美好的做法, 但是Docker的容器并不保存任何数据, 重启后就会丢失.
这意味着即便是一个配置文件,一个额外添加的包,也是需要从外部卷引入.
(或者配置或添加一个额外的扩展的时候重新封装成新的镜像,并使用这个镜像运行)

没感觉到这做法和传统的虚拟机+快照除了资源占用以外有什么别的优势...
官方并不推荐在Docker里面运行bash,而所有的数据都运行在外部卷.
而这个外部的卷是个文件夹,而不是一个单一的文件.
(单一的文件或者少数的文件在分布式部署的时候有优势..)

现在纠结在于,Docker在生产环境中是如何应用的...
而在测试环境又是如何应用的...
Docker一个容器运行一个进程,通过网络对接的方式是解耦了.
但貌似官方并没提供一个方式能简单快捷的把一堆容器作为一个整体的服务来看待.

请教各位, Docker正确的使用姿势是怎样的?

HowardMei

2015-06-09 12:33:55 +08:00

Docker Best practice 还没有公论，但是官方提倡的One proc per container 目前只有Coreos用systemd实现了，而且他们还在搞自己的RKT，直接在其它主流OS里照搬并不好用，像Kubernetes这样的外部管理工具都还在开发中，且K在底层实现上比较依赖GCE平台特性，另外像Mesosphere也支持Docker管理，但也在初级阶段。

持久数据管理，有flocker & codexd之类，但我觉得数据库还是搞成RDS那样的独立服务比较好，用Docker比较蛋疼，最起码目前Volume管理就很鸡肋。网络拓扑之类的，就更不用说了，也就Coreos的flannel解决得好点。

于是，至今的公开主流用法是把它当轻量级VM部署工具用，内部多进程外部放数据，不讲究的用supervisor，讲究点的用runit/s6之类管理，然后用etcd/consul进行动态参数配置，用fig/compose或者docker-in-docker组合容器形成应用。

用在生产环境，坑点是不少的，自有管理工具开发有蛮多开源项目参考，慢慢摸索就是了。

cxshun

2015-06-09 17:19:45 +08:00

如果你每次都通过dockerfile来创建，那肯定数据就没了，每次都是一个新的image，你应该只创建一次，之后提交更新到image，之后就直接run那个image就行了。

我是不大习惯用dockerfile，我喜欢一个原生image，然后自己commit需要的东西。但官网是建议用dockerfile，我觉得各有各好处了。