Docker 容器测试全探索

共计 4487 个字符，预计需要花费 12 分钟才能阅读完成。

大多数人会将此作为默认方案。其利用 CI 服务器实现任务执行。在这项方案中，开发人员利用 Docker 作为软件包管理器，其实际效果优于 jar/rpm/deb 方案。CI 服务器对应用程序代码进行编译，而后执行测试（包括单元、服务及功能等）。Docker 中的 build 可复用以生成新的镜像，由此生成的镜像不仅包含应用程序的“二进制代码”，同时亦拥有运行时所必需的依赖性及配置。

不过为了实现应用程序的可移植性，我们需要放弃开发与测试的可移植能力。在这种情况下，我们无法在 CI 之外重新建立同样的开发与测试环境。为了创始这样一套新的测试环境，我们需要设置测试工具（正确版本与插件）、配置运行时与操作系统设定，同时获取相同版本的测试脚本与测试数据。

为了解决上述难题，我们需要考虑以下方案。

现在我们尝试创建单一捆绑包，其中应用程序“二进制代码”中包含全部必需的软件包、测试工具（包括对应版本）、测试工具插件、测试脚本以及其它各类测试环境元素。但这种方式也存在着显著弊端：
镜像体积直线增长——这是因为其中包含有测试工具、必要软件包、测试脚本甚至是测试数据。
特定测试配置可能对镜像运行时环境造成污染，甚至引入不必要的依赖性（集成测试中需要用到）。
我们还需要考虑如何处理测试结果与记录日志；

如何将其导出以及向哪里导出, 通过以下经过简化的 Dockerfile，我们可以了解上述方案的整个流程。

FROM "":""

WORKDIR ""

# install packages required to run app and tests
RUN apt-get update && apt-get install -y /
"and" / # add app runtime and required packages
"and" / # add testing tools and required packages
&& rm -rf /var/lib/apt/lists/*

# copy app files
COPY app app
COPY run.sh run.sh

# copy test scripts
COPY tests tests

# copy "main" test command
COPY test.sh test.sh

# ... EXPOSE, RUN, ADD ... for app and test environment

# main app command
CMD [run.sh, ""]

# it's not possible to have multiple CMD commands, but this is the"main" test command
# CMD [/test.sh, ""]

毫无疑问，应该有更好的容器内测试方案可供选择。

目前，Docker 承诺以“Build -> Ship -> Run”这一简单操作完成镜像构建、发布至注册表并在其它位置运行等任务。Test 这一重要环节，正确且完整的流程应该是 Build -> Test -> Ship -> Run。下面让我们看看能够为 Docker 命令提供“测试友好”型语法与扩展的 Dockerfile 是如何建立而成的。“理想”版本，大家应该能够看出其中可用于实践的指导思路。

ONTEST [INSTRUCTION]

首先定义一条特殊的 ONTEST 指令，其与现有 ONBUILD 指令非常相似。ONTEST 指令会向镜像添加一条触发指令，其在随后镜像接受测试时自动执行。任意 build 指令都可被注册为触发条件。

ONTEST 指令可由一条新的 docker test 命令进行识别。

docker test [OPTIONS] IMAGE [COMMAND] [ARG...]

事实上，docker test 命令的语法与 docker run 命令非常相似，docker test 会自动生成一套新的“可测试”镜像, 执行全部 build 操作，于 ONTEST 命令后进行定义并执行 ONTEST CMD（或者 ONTEST ENTRYPOINT）。其中若测试发生错误，docker test 命令应当返回一段非零代码。此测试结果应当被写入至自动生成且指向 /var/tests/results 文件夹的 VOLUME。

下面我们来看看经过修改的 Dockerfile——其中包含新的 ONTEST 指令。

FROM "":""

WORKDIR ""

# install packages required to run app
RUN apt-get update && apt-get install -y /
"and" / # add app runtime and required packages
&& rm -rf /var/lib/apt/lists/*

# install packages required to run tests
ONTEST RUN apt-get update && apt-get install -y /
"and" / # add testing tools and required packages
&& rm -rf /var/lib/apt/lists/*

# copy app files
COPY app app
COPY run.sh run.sh

# copy test scripts
ONTEST COPY tests tests

# copy "main" test command
ONTEST COPY test.sh test.sh

# auto-generated volume for test results
# ONTEST VOLUME "/var/tests/results"

# ... EXPOSE, RUN, ADD ... for app and test environment

# main app command
CMD [run.sh, ""]

# main test command
ONTEST CMD [/test.sh, ""]

Docker 拥有 ONBUILD 这样一条非常实用的指令。该指令允许我们在已经成功的 build 之上触发另一 build 指令。其基本思路是在运行 docker-test 命令的同时，使用 ONBUILD 指令。

以下为 docker-test 命令的执行流程:

docker-test 将在应用程序 Dockerfile 当中搜索 ONBUILD 指令后，利用初始 Dockerfile 生成临时的 Dockerfile.test，再执行 docker build -f Dockerfile.test [OPTIONS] PATH，其中包含受 docker build 命令支持的其它选项：-test 将自动被添加至 tag 选项当中。
如果构建成功，则执行 docker run -v ./tests/results:/var/tests/results [OPTIONS] IMAGE:TAG-test [COMMAND] [ARG…] 移除 Dockerfile.test 文件
那么，为什么不创建一个无需配合 ONBUILD 指令的 Dockerfile.test 文件？

这是因为，为了测试正确的镜像（及标签），我们需要保证 FROM 始终在测试目标的 image:tag 中得到不过前面提到的方案仍然存在局限——其不适用于“onbuild”镜像（即用于自动化构建应用的镜像），例如 Maven:onbuild。

下面来看一条简单的 docker-test 命令实现流程。其中强调了一大重要概念：docker-test 命令应当能够处理 build 与 run 命令选项，同时能够妥善处理错误状况。

#!/bin/bash
image="app"
tag="latest"

echo "FROM ${image}:${tag}" > Dockerfile.test &&
docker build -t "${image}:${tag}-test" -f Dockerfile.test . &&
docker run -it --rm -v $(pwd)/tests/results:/var/tests/results "${image}:${tag}-test" &&
rm Dockerfile.test

让我们把注意力集中在最值得关注的重要部分。

假设我们拥有一套自动化 CI/CD 通道，我的的应用程序由数十甚至数百项微服务构建而成，每项微服务都由 CI 进行构建与测试，并在之后被部署到某种环境当中（例如测试、分段或者生产环境）。我们的 CI 会对各项微服务进行分别测试——运行单元与服务测试（或者 API 合同测试）。甚至有可能进行微集成测试——即将测试运行在特设的子系统之上但这又会带来一些新问题：

 实际集成测试或者长期运行测试该如何完成（例如性能与压力测试）？弹性测试该如何实现（例如‘混乱猴子’测试）？如何实现安全扫描？那些需要耗费较长时间且运行在完整操作系统之上的测试与扫描要如何完成？

应当存在一类特殊的集成测试容器。这些容器将仅包含测试工具与测试元素：测试脚本、测试数据、测试环境配置等等。为了简化此类容器的编排与自动化流程，我们应当定义并遵循某些约定并使用元数据标签（Dockerfile 中的 LABEL 指令）。

test.type – 测试类型，负责定义 integration; 可属于 integration, performance, security, chaos 或者其它任意文本之一; 此标签代表其属于一套集成测试容器

test.results – 用于存放测试结果的 VOLUME ; 默认位置为 /var/tests/results

test.XXX - 任何其它相关元数据，仅使用 test. 后缀名作为标签名称

集成测试容器其实就是一种常规 Docker 容器，其中不包含任何应用程序逻辑及代码。它的惟一用途就是创建可重复且可移植的测试流程。以下为建议纳入集成测试容器的内容：

 测试工具 - Phantom.js, Selenium, Chakram, Gatling, …

测试工具运行时 - Node.js, JVM, Python, Ruby, …

测试管理配置 – 环境变量, 配置文件, 引导脚本, …

测试 - 作为经过编译的软件包或者脚本文件存在

测试数据 – 任何用于测试的数据文件类型: json, csv, txt, xml, …

测试启动脚本 - 用于运行测试的部分“main”启动脚本，仅负责创建 test.sh 并借此启动该测试工具。

集成测试容器应当运行在全部微服务都已经部署到位的运营环境之下，这些容器可与其它服务采取一致的部署方式。在实际集成测试当中，我们必须对多项服务进行访问来测试多种不同环境下是否能正常运行。将集成测试纳入应用服务容器不仅会增加容器自身体积，同时亦会在各服务之间带来不必要的依赖性。因此，我们将所有依赖性都限制在集成测试容器当中。

阿里云 2 核 2G 服务器 3M 带宽 61 元 1 年，有高配

腾讯云新客低至 82 元 / 年，老客户 99 元 / 年

代金券：在阿里云专用满减优惠券