Docker和持续集成：案例学习
jopen
9年前
来自：http://dockone.io/article/582
对于使用java技术栈的企业，Maven往往是其持续集成的核心工具，在当前的dockerlize运动中，要如何把docker镜像的构建也加入到传统的Maven构建为基础的持续集成流程中呢？Alooma公司在本文中分享了他们使用Maven对docker镜像构建进行持续集成的经验。
在Alooma, 我们非常非常非常喜爱docker.
这是真的。 我们试着尽可能的在docker容器内部运行。 虽然在容器中打包模块有大量的好处，我们在这里并不是要说服你用Docker。相反的是，我们将仅仅假定你像我们一样热爱docker。
在这个假定下，让我们谈谈Alooma是怎么在生产中使用docker来使开发像流水线一样和快速发布代码。
概述
Docker允许你把你的基础架构当作代码一样来对待。这个代码就是你的Dockerfile们。像其他代码一样，我们想要使用一个紧密的改变->提交->构建->测试的周期(一个完整的持续集成解决方案)。为了实现这个目标，我们需要构建一个流畅的DevOps流水线。
让我们把目标分解为更加详细的需求：
- 在版本控制系统中管理Dockerfile们
- 在CI服务器上对每个commit构建docker镜像
- 上传构件并打标签（这个构件要能够简单的部署）
我们的工作流
在高层次上，我们的DevOps流水线围绕GitHub，Jenkins 和Maven 构建。下面是它工作的流程：- GitHub将repo的每一个push通知给Jenkins
- Jenkins触发一个Maven build
- Maven 构建所有的东西，包括docker 镜像
- 最后，Maven 构建以推送docker 镜像到我们的私有docker registry结束
这个工作流的好处是它允许我们能够很容易的为每个发布版本打标签（所有的commits都被构建并且在我们的docker registry中准备好了）。然后我们可以非常容易地通过pull和run这些docker镜像进行部署。
事实上这个部署过程是非常简单的，我们通过发送一个命令给我们信任的Slack机器人: "Aloominion"（关于我们的机器人朋友的更多情况将在未来的文章中发表）开始这个过程。
你可能对这个工作流中的其他元素非常熟悉，因为它们都很常见。所以，让我们特别地来深入了解用Maven 构建docker 镜像这个过程。
深入Docker 构建
Alooma 是一个Java 公司。我们已经使用Maven 作为我们构建流水线的中心工具，所以很自然的想到把构建docker的过程也加入到我们的Maven构建过程中去。当搜索和docker交互的Maven插件时，出现了3个选项。我们选择使用Spotify的maven-docker-plugin —— 虽然rhus的和alexec的同名插件看起来也是一个合适的选项。
另一个我们的构建计划依赖的Maven插件是maven-git-commit-id-plugin. 我们使用这个插件，所以我们的docker镜像能使用git的commit ID来打标签 —— 这在部署过程中非常有帮助，使我们了解运行的是哪个版本。
给我看代码！
每一个docker镜像有它自己的Maven模块（所有上面提到的docker-maven 插件在一个模块一个Dockerfile时都能顺利地工作）让我们从Spotify插件的一个简单配置开始：
<plugin> <groupId>com.spotify</groupId> <artifactId>docker-maven-plugin</artifactId> <version>0.2.3</version> <executions> <execution> <phase>package</phase> <goals> <goal>build</goal> </goals> </execution> </executions> <configuration> <dockerDirectory>${project.basedir}</dockerDirectory> <imageName>alooma/${project.artifactId}</imageName> </configuration> </plugin>我们看到这里我们把插件的build目标和Maven的package阶段绑定，我们也指导它去在我们模块的根目录下来寻找Dockerfile（使用dockerDirectory 元素来指定），我们还把镜像名称用它的构件Id来命名（用"alloma/"做前缀）。
这在一个简单的docker 构建上工作良好。
我们注意到的第一件事情是这个镜像没有被push到任何地方，我们可以通过加入<pushImage>true</pushImage>到配置中来解决。很好。
但是现在这个镜像会被push到默认的docker hub registry上。不好。
为了解决这个问题，我们定义了一个新的Maven属性<docker.registry>docker-registry.alooma.io:5000/</docker.registry>并且把镜像名称imageName改为${docker.registry}alooma/${project.artifactId}. 你可能会想，“为什么需要为docker registry设置一个属性？”， 你是对的！但是有这个属性可以使我们在我们的regsitry URL改变的时候能够更方便的修改。
有一个更重要的事情我们还没有处理的是——我们想让每一个镜像用它的git commit ID来打标签。这通过改变imageName为${docker.registry}alooma/${project.artifactId}:${git.commit.id.abbrev}来实现。
${git.commit.id.abbrev}属性是通过我上面提到的maven-git-commit-id-plugin插件来实现的。
所以，现在我们的插件配置看起来像下面这样：
<plugin> <groupId>com.spotify</groupId> <artifactId>docker-maven-plugin</artifactId> <version>0.2.3</version> <executions> <execution> <phase>package</phase> <goals> <goal>build</goal> </goals> </execution> </executions> <configuration> <dockerDirectory>${project.basedir}</dockerDirectory> <imageName> ${docker.registry}alooma/${project.artifactId}:${git.commit.id.abbrev} </imageName> <pushImage>true</pushImage> </configuration> </plugin>我们的下一个挑战是在我们的pom.xml中表达我们的Dockerfiles的依赖。一些我们的docker 镜像在构建时使用了FROM其他的docker 镜像作为基础镜像（也在同一个构建周期中构建）。例如，我们的webgate镜像（是我们的机遇Tomcat的WebApp）基于我们的base镜像（包含Java 8, 更新到最新的 apt-get, 等等）。
这些镜像在同一个构建过程中构建意味着我们不能简单的使用FROM docker-registry.alooma.io/alooma/base:some-tag因为我们需要这个标签编程当前构建的标签（即 git commit ID）。
为了在Dockerfile中获得这些属性，我们使用了Maven的resource filtering功能。这在一个资源文件中替换Maven 的属性。
<resource> <directory>${project.basedir}</directory> <filtering>true</filtering> <includes> <include>**/Dockerfile</include> </includes> </resource>在Dockerfile的内部我们有一个这样的FROM
FROM ${docker.registry}alooma/base:${git.commit.id.abbrevs}一些更多的事情... 我们需要是我们的配置来找到正确的Dockerfile（过滤过之后的），这可以在target/classes文件夹内找到，所以我们把dockerDirectory改为${project.build.directory}/classes。
这意味着现在我们的配置文件长这样：
<resources> <resource> <directory>${project.basedir}</directory> <filtering>true</filtering> <includes> <include>**/Dockerfile</include> </includes> </resource> </resources> <pluginManagement> <plugins> <plugin> <groupId>com.spotify</groupId> <artifactId>docker-maven-plugin</artifactId> <version>0.2.3</version> <executions> <execution> <phase>package</phase> <goals> <goal>build</goal> </goals> </execution> </executions> <configuration> <dockerDirectory>${project.build.directory}/classes</dockerDirectory> <pushImage>true</pushImage> <imageName> ${docker.registry}alooma/${project.artifactId}:${git.commit.id.abbrev} </imageName> </configuration> </plugin> </plugins> </pluginManagement>此外，我们还要添加base构件作为webgate模块的一个Maven依赖来保证正确的Maven构建顺序。
但是我们还有另一个挑战：我们如何把我们编译和打包了的源文件添加到我们的docker镜像中呢？我们的Dockerfile依赖于很多其他文件，它们通过ADD或COPY命令插入。（你可以在这里读到更多的关于Dockerfile的指导）
为了让这些文件可以被获取，我们需要使用插件配置的resources标签。
<resources> <resource> <targetPath>/</targetPath> <directory>${project.basedir}</directory> <excludes> <exclude>target/**/*</exclude> <exclude>pom.xml</exclude> <exclude>*.iml</exclude> </excludes> </resource> </resources>注意到我们排除了一些文件（这些文件事实上不被docker需要）。
记住这个resources标签不应该喝通常的Mavenresources标签弄混，看看下面的例子，它来自于我们的pom.xml的一部分：
<resources> <!-- general Maven resources --> <resource> <directory>${project.basedir}</directory> <filtering>true</filtering> <includes> <include>**/Dockerfile</include> </includes> </resource> </resources> <pluginManagement> <plugins> <plugin> <groupId>com.spotify</groupId> <artifactId>docker-maven-plugin</artifactId> <version>0.2.3</version> <executions> <execution> <phase>package</phase> <goals> <goal>build</goal> </goals> </execution> </executions> <configuration> <dockerDirectory>${project.build.directory}/classes</dockerDirectory> <pushImage>true</pushImage> <imageName> ${docker.registry}alooma/${project.artifactId}:${git.commit.id.abbrev} </imageName> <resources> <!-- Dockerfile building resources --> <resource> <targetPath>/</targetPath> <directory>${project.basedir}</directory> <excludes> <exclude>target/**/*</exclude> <exclude>pom.xml</exclude> <exclude>*.iml</exclude> </excludes> </resource> </resources> </configuration> </plugin> </plugins> </pluginManagement>前一个添加在我们想添加一些静态资源到镜像时工作，但是如果我们想要添加一个在同一个构建中构建的构件时需要更多的调整。
例如，我们的webgatedocker镜像包含了我们的webgate.war，这是由另一个module构建的。
为了添加这个war作为资源，我们手写必须把它作为我们的Maven依赖加进来，然后使用maven-dependency-plugin插件的copy目标来把它加到我们当前的构建目录中。
<plugin> <groupId>org.apache.maven.plugins</groupId> <artifactId>maven-dependency-plugin</artifactId> <executions> <execution> <goals> <goal>copy</goal> </goals> <configuration> <artifactItems> <artifactItem> <groupId>com.alooma</groupId> <artifactId>webgate</artifactId> <version>${project.parent.version}</version> <type>war</type> <outputDirectory>${project.build.directory}</outputDirectory> <destFileName>webgate.war</destFileName> </artifactItem> </artifactItems> </configuration> </execution> </executions> </plugin>现在这允许我们简单的把这个文件加到docker插件的resources中去
<resources> <resource> <directory>${project.basedir}</directory> <filtering>true</filtering> <includes> <include>**/Dockerfile</include> </includes> </resource> </resources> <pluginManagement> <plugins> <plugin> <groupId>com.spotify</groupId> <artifactId>docker-maven-plugin</artifactId> <version>0.2.3</version> <executions> <execution> <phase>package</phase> <goals> <goal>build</goal> </goals> </execution> </executions> <configuration> <dockerDirectory>${project.build.directory}/classes</dockerDirectory> <pushImage>true</pushImage> <imageName> ${docker.registry}alooma/${project.artifactId}:${git.commit.id.abbrev} </imageName> <resources> <resource> <targetPath>/</targetPath> <directory>${project.basedir}</directory> <excludes> <exclude>target/**/*</exclude> <exclude>pom.xml</exclude> <exclude>*.iml</exclude> </excludes> </resource> <rescource> <targetPath>/</targetPath> <directory>${project.build.directory}</directory> <include>webgate.war</include> </rescource> </resources> </configuration> </plugin> </plugins> </pluginManagement>我们需要做的最后一件事情是让我们的CI服务器（Jenkins）真的讲镜像push到docker registry上。请记住本地构件默认是不会push镜像的。
为了push这些镜像，我们改变我们的<pushImage>标签的值从true变为${push.image}属性，这默认是被设置为false，并且只会在CI服务器上设置为true。（译注：这里的意思是，由于开发人员也要在本地构建然后测试之后才会提交，而测试的镜像不应该被提交到registry，所以<pushImage>应该使用一个属性，默认为false，在CI服务器上覆盖为true在构建后去push镜像）
这就完成了！让我们看一下最终的代码：
<resources> <resource> <directory>${project.basedir}</directory> <filtering>true</filtering> <includes> <include>**/Dockerfile</include> </includes> </resource> </resources> <pluginManagement> <plugins> <plugin> <groupId>com.spotify</groupId> <artifactId>docker-maven-plugin</artifactId> <version>0.2.3</version> <executions> <execution> <phase>package</phase> <goals> <goal>build</goal> </goals> </execution> </executions> <configuration> <dockerDirectory>${project.build.directory}/classes</dockerDirectory> <pushImage>${push.image}</pushImage> <!-- true when Jenkins builds, false otherwise --> <imageName> ${docker.registry}alooma/${project.artifactId}:${git.commit.id.abbrev} </imageName> <resources> <resource> <targetPath>/</targetPath> <directory>${project.basedir}</directory> <excludes> <exclude>target/**/*</exclude> <exclude>pom.xml</exclude> <exclude>*.iml</exclude> </excludes> </resource> <rescource> <targetPath>/</targetPath> <directory>${project.build.directory}</directory> <include>webgate.war</include> </rescource> </resources> </configuration> </plugin> </plugins> </pluginManagement>性能
这个过程有两个能够提高你的构建和部署的性能的改进地方：- 让你的基础的机器镜像（在EC2的例子下是AMI）包含一些你的docker镜像的基础版本。这样会使得docker pull只去pull那些改变了的层，即增量（相对于整个镜像来说要小得多）。
- 在docker registry的前端放一个Redis缓存。这可以缓存标签和元数据，减少和真实存储（在我们的例子下是S3）的回环。
我们现在已经使用这个构建过程一段时间了，并且对它非常满意。然而仍然有提高的空间，如果你有任何关于让这个过程更加流畅的建议，我很乐意在评论中听到你的想法。
原文链接：Continuous Integration for Dockers: Case study （翻译：陈光）