GitLab CI：助力Kubernetes应用完成JUnist测试

每个人都知道软件测试的重要性和必要性——我相信许多人都坚持这样做。但出乎意料的是，我很难找到一个很好的例子来用GitLab和JUnit配置CI/CD。现在让我来填补这个空白。

背景

首先，让我定义完整的上下文：

由于我们所有的应用程序都在Kubernetes中运行，因此我仅介绍相关架构中的测试
我会使用werf[1]来构建和部署镜像（这意味着Helm也会参与到流水线中）
我不会详细介绍测试本身：在我们的案例中，测试是使用者实施的，我们仅确保测试正常运行（并在合并请求中显示相应的报告）

以下是我们的示例中常见的操作顺序：

构建应用程序——我们将省略此步骤的描述
将应用程序部署到Kubernetes集群的独立命名空间并运行测试
通过GitLab检索artifacts并解析JUnit报告
删除之前创建的命名空间

让我们开始实践吧！

GitLab CI（Continuous Integration，持续集成）

我们将从 .gitlab-ci.yaml的代码开始，以下部分描述了应用程序的部署和运行测试。代码有点长，我在其中插入了详细的注释：

variables:
# 声明我们将使用的werf的版本



    
  WERF_VERSION: "1.0 beta"
.base_deploy: &base_deploy
  script:
# 如果Kubernetes不存在该命名空间则创建命名空间
   - kubectl --context="${WERF_KUBE_CONTEXT}" get ns ${CI_ENVIRONMENT_SLUG} || kubectl create ns ${CI_ENVIRONMENT_SLUG}
# 加载werf并部署——详情请查看文档
#（https://werf.io/how_to/gitlab_ci_cd_integration.html#deploy-stage）
    - type multiwerf && source multiwerf use ${WERF_VERSION


    
})
    - werf version
    - type werf && source werf ci-env gitlab --tagging-strategy tag-or-branch --verbose)
    - werf deploy --stages-storage :local
      --namespace ${CI_ENVIRONMENT_SLUG}
      --set "global.commit_ref_slug=${CI_COMMIT_REF_SLUG:-''}"
# 传递变量 `run_tests`



    
# 这个变量会在渲染Helm版本时使用
      --set "global.run_tests=${RUN_TESTS:-no}"
      --set "global.env=${CI_ENVIRONMENT_SLUG}"
# 设置超时（某些测试耗时很长）
# 并将其传递给发布
      --set "global.ci_timeout=${CI_TIMEOUT:-900}"
     --timeout ${CI_TIMEOUT:-900}
  dependencies:
    - Build
.test-base: &


    
test-base
  extends: .base_deploy
  before_script:
# 为接下来的报告创建文件夹
# 使用 $CI_COMMIT_REF_SLUG
    - mkdir /mnt/tests/${CI_COMMIT_REF_SLUG} || true
# 强制解决方法，因为GitLab需要artifacts在其构建目录中
    - mkdir ./tests || true
    - ln -s 


    
/mnt/tests/${CI_COMMIT_REF_SLUG} ./tests/${CI_COMMIT_REF_SLUG}
  after_script:
# 在完成测试后用作业删除发布（以及其基础设施）
    - type multiwerf && source multiwerf use ${WERF_VERSION})
    - werf version
    - type werf && source werf ci-env gitlab --tagging-strategy tag-or-branch --


    
verbose)
    - werf dismiss --namespace ${CI_ENVIRONMENT_SLUG} --with-namespace
# 这里我们定义允许失败发生，但是您也可以自定义
  allow_failure: true
  variables:
    RUN_TESTS: 'yes'
# 设置werf context, 文档请查看以下连接
# （https://werf.io/how_to/gitlab_ci_cd_integration.html#infrastructure）
    WERF_KUBE_CONTEXT: 'admin@stage-cluster'
  tags:



    
# 使用带有`werf-runner`标签的runner
    - werf-runner
  artifacts:
# 首先必须创建一个artifact才能在流水线中查看
# 并下载它（例如，用于进行更深入的研究）
    paths:
      - ./tests/${CI_COMMIT_REF_SLUG}/*
# 超过一周的artifact将被删除
    expire_in: 7 day
# 注意：以下这几行用于GitLab解析报告
    reports:
      junit: ./tests/${CI_COMMIT_REF_SLUG}/report.xml



    
# 为了简单起见，这里仅显示两个阶段
# 在现实中，你可能有更多阶段
stages:
  - build
  - tests
build:
  stage: build
  script:
# build stage - 请查看werf相关文档：
# （https://werf.io/how_to/gitlab_ci_cd_integration.html#build-stage）
    - type multiwerf && source 
    - werf version
    - type werf && source 
    - werf build-and-publish --stages-storage :local
  tags:
    - werf-runner



    
  except:
    - schedules
run tests:
  <<:>
  environment:
# 给命名空间命名
# （https://docs.gitlab.com/ce/ci/variables/predefined_variables.html）
    name: tests-${CI_COMMIT_REF_SLUG}
  stage: tests
  except:
    - schedules

Kubernetes

现在是时候创建一个YAML文件（ tests-job.yaml）了，这个文件用来做两件事：

描述这个Job了
描述在 .helm/templates目录中所有必要的Kubernetes资源。

请参阅以下说明：

{{- if eq .Values.global.run_tests "yes" }}
---
apiVersion: v1
kind: ConfigMap
metadata:
  name: tests-script
data:
  tests.sh: |



    
    echo "======================"
    echo "${APP_NAME} TESTS"
    echo "======================"
cd /app
    npm run test:ci
    cp report.xml /app/test_results/${CI_COMMIT_REF_SLUG}/
echo ""
    echo ""
    echo ""
chown -R 999:999 /


    
app/test_results/${CI_COMMIT_REF_SLUG}
---
apiVersion: batch/v1
kind: Job
metadata:
  name: {{ .Chart.Name }}-test
  annotations:
    "helm.sh/hook": post-install,post-upgrade



    
    "helm.sh/hook-weight": "2"
    "werf/watch-logs": "true"
spec:
  activeDeadlineSeconds: {{ .Values.global.ci_timeout }}
  backoffLimit: 1
  template:
    metadata:
      name: {{ .Chart.Name }}-test



    
    spec:
      containers:
      - name: test
        command: ['bash', '-c', '/app/tests.sh']
{{ tuple "application" . | include "werf_container_image" | indent 8 }}
        env:
        - name: env
          value


    
: {{ .Values.global.env }}
        - name: CI_COMMIT_REF_SLUG
          value: {{ .Values.global.commit_ref_slug }}
       - name: APP_NAME
          value: {{ .Chart.Name }}
{{ tuple "application" . | include "werf_container_env"


    
 | indent 8 }}
        volumeMounts:
        - mountPath: /app/test_results/
          name: data
        - mountPath: /app/tests.sh
          name: tests-script
          subPath: tests.sh
      tolerations:
      - key


    
: dedicated
        operator: Exists
      - key: node-role.kubernetes.io/master
        operator: Exists
      restartPolicy: OnFailure
      volumes:
      - name: data
        persistentVolumeClaim:
          claimName: {{ 


    
.Chart.Name }}-pvc
      - name: tests-script
        configMap:
          name: tests-script
---
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: {{ .Chart.Name }}-pvc



    
spec:
  accessModes:
  - ReadWriteOnce
  resources:
    requests:
      storage: 10Mi
  storageClassName: {{ .Chart.Name }}-{{ .Values.global.commit_ref_slug }}
  volumeName: {{ .Values.global


    
.commit_ref_slug }}
---
apiVersion: v1
kind: PersistentVolume
metadata:
  name: {{ .Values.global.commit_ref_slug }}
spec:
  accessModes:
  - ReadWriteOnce
  capacity:
    storage


    
: 10Mi
  local:
    path: /mnt/tests/
  nodeAffinity:
   required:
     nodeSelectorTerms:
     - matchExpressions:
       - key: kubernetes.io/hostname
         operator: In
         values:



    
         - kube-master
  persistentVolumeReclaimPolicy: Delete
  storageClassName: {{ .Chart.Name }}-{{ .Values.global.commit_ref_slug }}
{{- end }}

这个配置描述哪些资源呢？我们将会在部署期间为应用程序创建一个唯一的命名空间（ .gitlab-ci.yaml文件中定义了命名空间 — tests-${CI_COMMIT_REF_SLUG}），并在其中部署几个组件：

带有测试脚本的ConfigMap
带有Pod描述和运行测试的指令的Job
PV和PVC将存储测试数据

注意清单开头的初始 if语句。为了防止使用应用程序部署Helm图表的其他YAML文件，您必须插入以下相反条件：




    
{{- if ne .Values.global.run_tests "yes" }}
---
Hey, I'm another YAML
{{- end }}

但是，如果一些测试需要其他的基础设施 （如Redis，RabbitMQ，Mongo，PostgreSQL等等），那么你可以在相应的YAML文件中启动并部署这些组件到测试环境中。

最后一点

当前，仅通过构建服务器（使用gitlab-runner）支持使用werf进行构建和部署。但是，测试容器在主节点上运行。在这种情况下，你必须在主节点上创建 /mnt/tests文件夹并将其安装到运行器（runner），例如通过NFS。Kubernetes文档中提供了详细示例[2]。

我们将会得到以下结果：

user@kube-master:~$ cat /etc/exports | grep tests



    
/mnt/tests    IP_gitlab-builder/32(rw,nohide,insecure,no_subtree_check,sync,all_squash,anonuid=999,anongid=998)

user@gitlab-runner:~$ cat /etc/fstab | grep tests
IP_kube-master:/mnt/tests    /mnt/tests   nfs4    _netdev,auto  0       0

另一种可能性是直接在gitlab-runner上创建一个共享的NFS目录，然后将其安装到Pod上。

注释

您可能会问，如果可以轻松地在shell中运行测试脚本，那么创建Job的意义何在？答案很明显：

有些测试需要基础架构（例如MongoDB，RabbitMQ，PostgreSQL等）来检查功能。我的方法是一个统一的解决方案，可以轻松集成其他实例。另外，我们获得了标准的部署方法（即使用NFS和额外的目录）。

结果

如果应用提前准备好的配置会是什么结果？

合并请求中将显示在其先前流水线中执行的测试的摘要：

单击错误获取更多信息：

注意：细心的读者会注意到我们正在测试Node.js应用程序，但是屏幕截图上有一个.NET。不必感到惊讶：虽然我们在原始的应用程序中没有发现任何问题，但在另一个应用程序中暴露出了一些小问题。

结论

如你所见，它是如此简单！

如果你已经有可以使用的Shell脚本并且不需要Kubernetes，则可以通过更简单的方法实现以上例子。请查看GitLab CI 文档[3]。CI文档中提供了Ruby，Go，Gradle，Maven和其他一些产品的示例。