持续集成测试(1) — docker-maven-plugin初探

背景

最近想搞持续集成测试,初步构想是使用Git、jekins、maven、Docker作为持续集成的基础组件,当然也是最常用的基础组件。
初步是想将Java的测试用例塞到docker容器中进行测试,测试环境部署只一次就好,镜像推送到仓库,随测随拉,直接使用docker命令运行,好处是环境一致,不需要重新部署测试代码所依附的环境;坏处是docker,docker,docker,也就是想运行测试用例必备的基础环境docker。

junit的命令行执行

我们最常见的执行测试用例多数是通过eclipse的run as,或者是mvn test执行测试用例。如果将测试用例塞到容器内,要么将mvn装到容器内,要么在物理机构建,并将构建后的环境也就是jar包塞到容器内使用java执行。
衡量了下,还是决定在物理机进行构建,将构建结果塞到容器内.
1. 重复构建mvn环境浪费时间;
2. 将mvn塞到容器内浪费资源;
3. blablabla,反正就是不爽

鉴于本人学艺不精,这里转载一篇对于junitcore使用的文章:

命令行执行使用java -cp *.jar org.junit.runner.JUnitCore classname可参考该篇文章了解及执行。

执行示例

使用junit简单的输出语句,没有功能,只是作为示例演示:

public class startTest {

    @Before
    public void setup(){
        System.out.println("this is setup...");
    }

    @After
    public void teardown(){
        System.out.println("this is teardown...");
    }

    @Test
    public void test1(){
        System.out.println("this is test1...");
    }
}
  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  • 7
  • 8
  • 9
  • 10
  • 11
  • 12
  • 13
  • 14
  • 15
  • 16
  • 17
  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  • 7
  • 8
  • 9
  • 10
  • 11
  • 12
  • 13
  • 14
  • 15
  • 16
  • 17

命令行之行junit:

java -cp $CLASS_PATH:target/test-classes org.junit.runner.JUnitCore $CLASS_NAME 
  • 1
  • 1

遇到的问题及解决办法

由于对java执行junit测试用例实在不是很熟,mvn打完包后,执行

java -cp $CLASS_PATH org.junit.runner.JUnitCore $CLASS_NAME
  • 1
  • 1

总是找不到测试类(本人技术不熟,喷子勿喷^o^),原因是由于jar包内默认查询的是src/main下的文件,而测试用例大都在src/test下

mv src/test src/main
mvn clean package -DskipTests=true
java -cp $CLASS_PATH org.junit.runner.JUnitCore $CLASS_NAME
bingo
  • 1
  • 2
  • 3
  • 4
  • 1
  • 2
  • 3
  • 4

或者指定classpath,指定去target/test-classes目录下查找测试类

java -cp $CLASS_PATH:target/test-classes org.junit.runner.JUnitCore $CLASS_NAME
  • 1
  • 1

进入主题

该插件有两种使用方式:
1. 不使用dockerfile
2. 使用dockerfile

不使用dockerfile

顾名思义就是不依赖于dockerfile构建镜像,即通过标签来定义镜像构建过程。

<plugin>
  <groupId>com.spotify</groupId>
  <artifactId>docker-maven-plugin</artifactId>
  <version>0.4.13</version>
  <configuration>
    <imageName>registry.test.com/example</imageName>
    <baseImage>registry.test.com/base_image</baseImage>
    <entryPoint>["sh", "start.sh"]</entryPoint>
    <resources>
      <resource>
        <targetPath>/</targetPath>
        <directory>${project.build.directory}</directory>
        <include>**/*</include>
      </resource>
    </resources>
  </configuration>
</plugin>
  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  • 7
  • 8
  • 9
  • 10
  • 11
  • 12
  • 13
  • 14
  • 15
  • 16
  • 17
  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  • 7
  • 8
  • 9
  • 10
  • 11
  • 12
  • 13
  • 14
  • 15
  • 16
  • 17

其中:

imageName:即将构建的镜像名
baseImage: 构建镜像时需要的基础镜像,类似于Dockerfile的From
entryPoint: 容器启动时执行的命令
resources:拷贝一些额外的文件到指定路径下,比如${project.build.finalName}.jar文件

一些maven的内置变量

${basedir} 项目根目录
${project.build.directory} 构建目录,默认为target
${project.build.outputDirectory} 构建过程输出目录,默认为target/classes,target/test-classes
${project.build.finalName} 打包后生成的结果名称,默认为${project.artifactId}-${project.version}
\${project.packaging} 打包类型,默认为jar

maven一些标签

targetPath:指定build资源到哪个目的目录,默认是base directory
directory:指定属性文件的目录,build的过程需要找到它,并且将其放到targetPath下。
includes:指定包含文件的patterns,符合样式并且在directory目录下的文件将会是包含进project的资源文件
excludes:指定不包含在内的patterns,如果includes与excludes有冲突,那么excludes胜利,那些符合冲突样式的文件还是不会包含进来的

使用dockerfile

依赖于Dockerfile构建镜像,需指定dockerDirectory 来查找Dockerfile所在文件目录,指定dockerDirectory 后,baseImagemaintainercmdentryPoint等标签均失效。dockerDirectory目录下的所有内容默认会被复制到${project.build.directory}/docker目录下。

<plugin>
  <groupId>com.spotify</groupId>
  <artifactId>docker-maven-plugin</artifactId>
  <version>0.4.13</version>
  <configuration>
    <imageName>registry.test.com/example</imageName>
    <dockerDirectory>${project.basedir}/</dockerDirectory>
    <resources>
      <resource>
        <targetPath>/</targetPath>
        <directory>${project.build.directory}</directory>
        <include>${project.build.finalName}.jar</include>
      </resource>
    </resources>
  </configuration>
</plugin>
  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  • 7
  • 8
  • 9
  • 10
  • 11
  • 12
  • 13
  • 14
  • 15
  • 16
  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  • 7
  • 8
  • 9
  • 10
  • 11
  • 12
  • 13
  • 14
  • 15
  • 16

我的根目录结构为:

-rw-r--r-- 1 ** **  437 Sep 21 10:38 Dockerfile
drwxr-xr-x 2 ** ** 4096 Sep 20 13:59 lib
drwxr-xr-x 3 ** ** 4096 Sep 20 11:18 logs
-rwxrwxrwx 1 ** ** 3015 Sep 20 18:40 pom.xml
-rwxr-xr-x 1 ** ** 3102 Sep 20 18:54 pom.xml.undocker
drwxrwxrwx 3 ** ** 4096 Sep 20 11:18 src
-rw-r--r-- 1 ** ** 1028 Sep 20 10:27 start.sh
  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  • 7
  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  • 7

我的Dockerfile指定在根目录下,当执行 mvn clean package docker:build后会生成一target文件,查看target目录后默认生成docker文件夹,继续查看docker文件夹时可见,根目录的所有内容都被copy到该文件夹下,在进行docker build的过程中也是在target/docker目录下根据Dockerfile执行。

Dockerfile文件内容如下,安装了jdk,添加测试代码所需的一些库:

From registry.test.com/base_image:centos6.6

ADD target/test-classes /data1/target/test-classes
ADD target/dockermaven/lib /data1/target/dockermaven/lib
ADD start.sh /data1/
ADD lib/jdk-1.8.0_77-2.el6.x86_64.rpm /jdk-1.8.0_77-2.el6.x86_64.rpm
RUN rpm -ivh /jdk-1.8.0_77-2.el6.x86_64.rpm
ENV JAVA_HOME /usr/local/jdk1.8.0_77
ENV PATH $PATH:$JAVA_HOME/bin
RUN chmod +x /data1/start.sh
WORKDIR /data1
CMD sh start.sh
  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  • 7
  • 8
  • 9
  • 10
  • 11
  • 12
  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  • 7
  • 8
  • 9
  • 10
  • 11
  • 12

构建命令

# maven打包并构建镜像
mvn clean package -DskipTests=true docker:build
# maven打包构建镜像并push到仓库
mvn clean package docker:build -DpushImage
# maven打包构建镜像,将指定tag的镜像push到仓库,该命令需使用
# <imageTags><imageTag>...</imageTag></imageTags>标签
mvn clean package docker:build -DpushImageTag

<plugin>
  <configuration>
    ...
    <imageTags>
       <imageTag>${project.version}</imageTag>
       <imageTag>latest</imageTag>
    </imageTags>
  </configuration>
</plugin>

# 关于tags配置也可在命令行直接设置
mvn ... docker:build -DpushImageTags -DdockerImageTag=latest -DdockerImageTag=another-tag

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.