使用Docker做开发的建议团队工作流

Tags Docker Linux


2015-06-04 14:00:14


意义

在之前的文章中我们使用了BusyBox来完成简化到合适大小的DockerImage。因此我们结合我们的团队工作流程介绍如何利用Docker来进行快速开发的。

自从Docker进入到我们的工作流程之后给环境配置框架搭建,持续集成,持续交付方面带来了很多好处,首先相对于虚拟机来说,最直接的好处是带来了更小的镜像,同时程序以容器的方式运行不但启动速度快而且性能也好过虚拟机,同时它的配置可以非常快速的调整。其次对于开发来说,我们整个团队都使用的是Sublime+git的方式进行开发,使用Docker之后无论是什么平台只要有Shell都可以很方便的统一测试&开发环境。

Docker特性的使用

  1. 磁盘挂载(-v) 一直以来我们在使用Docker过程中都遵循着一个道理Docker只是一个环境他只是运行程序的一种手段。我们不能在docker中持久化数据,无论是文件还是数据库都是不允许的,因为很有可能测试结束之后会丢失数据。用于开发的Docker Image我们需要针对数据持久化新开方便调试使用的数据库,我们需要挂载针对应用的数据库持久化文件夹,当然我们还需要针对脚本进行目录挂载,如果是golang的话运行之前可能要自动化构建golang程序。
  2. 端口映射 虽然docker给我们提供了link的方法来实现容器之间的链接,但是我们依赖还是使用了最传统的端口映射的方式来进行服务的对外发布。因为我们觉得关系越简单,整个平台的服务就越稳定,虽然链接的这种方式并没有什么不好之处。

工作流程

定制容器准备开发&&运行环境

从Dockerfile开始部署环境,有两个方向上的选择,一种是自己定制操作系统,另外一种是依赖其他人做好的。

先说第一种方法:在我之前的blog中已经有提到:http://open.daocloud.io/build-and-deploy-the-thinnest-docker-image/ (DaoCloud首发)可以大概参考一下。

这种方法缺点主要在于,需要非常了解Linux或者至少做过LFS才能方便自己定制操作系统,要对业务底层依赖有一定了解。因为此方法需要精简image所以需要手动解决依赖问题。对于依赖比较多的情况不适用。

第二种方法,在之前的blog中也有提到过:http://www.philo.top/2015/05/28/Build-Hexo-env-by-docker-Under-OSX/ 里面有详细的过程以及Dockerfile参考。

这种方法构建的image大概100MB+虽然比虚拟机(按G来算)小了很多,但是在迁移分发Image的时候还是要注意(如果你没有自己的Docker Hub)。如果使用文件迁移请用save的方式来分发image,在上面链接的blog中有提到备份迁移的问题。

另外一个注意的地方,如果是用别人的image要注意安全,会不会里面挂了后门之类的,然后要摸清系统配置,准备好 代码 Or bin的挂载位置,数据库持久化文件存放的位置等等都要摸清。最后在运行的时候都要给出挂载方案。

发布之后要做的事

因为Docker只是一个容器而不是项目中的一部分,所以只是项目实现的一种手段,具体应该如何使用它,需要一定的文档支撑,也就是开发业务流程文档。

文档中要详细的提出所有依赖的Service配置文件的位置,配置的状态,持久化目录位置,输出的端口,开发完成之后业务部署的位置这些关于项目的尽量能想到的信息,因为这套容器会跟着项目整个周期中作为基础设施的一部分在运行。

除了配置方面,第二部分是建议的使用方法流程,比如:要说清楚代码是在容器内部编译还是在其他容器中有做好的辅助工具编译,还是有一个独立的服务器(项目比较大的时候需要一个独立的构建服务器,甚至需要一个专门管理构建&&版本的同事),如果是脚本语言写的就不需要这么麻烦了。

项目Release

项目进行到一个阶段之后需要release把代码 or bin直接build到image里面就行了。注意先要判断项目是否要使用Docker。

好处总结

在文件持久化方面我们挂载的目录实现了统一,配置文件也实现了统一。 在PHP开发中再也不用担心目录大小写敏感,文件大小写敏感,目录长度限制等因为操作系统不统一的问题。

由于不同项目有不同的限制因素,因此在这里介绍总体的工作流程,项目中涉及到不同的应用服务只需要比较小的调整。


本人博客文章采用CC Attribution-NonCommercial协议: CC Attribution-NonCommercial 必须保留原作者署名,并且不允许用于商业用途,其他行为都是允许的。