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

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

背景

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

• 由于我们所有的应用程序都在Kubernetes中运行，因此我仅介绍相关架构中的测试

• 我会使用werf[1]来构建和部署镜像（这意味着Helm也会参与到流水线中）

• 我不会详细介绍测试本身：在我们的案例中，测试是使用者实施的，我们仅确保测试正常运行（并在合并请求中显示相应的报告）

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

1. 构建应用程序——我们将省略此步骤的描述

2. 将应用程序部署到Kubernetes集群的独立命名空间并运行测试

3. 通过GitLab检索artifacts并解析JUnit报告

4. 删除之前创建的命名空间

让我们开始实践吧！

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 <(multiwerf use ${WERF_VERSION})
      
      
      
      
 - werf version
      
      
      
      
 - type werf && source <(werf ci-env gitlab --tagging-strategy tag-or-branch --verbose)
      
      
      
      
 - werf build-and-publish --stages-storage :local
      
      
      
      
 tags:
      
      
      
      
 - werf-runner
      
      
      
      
 except:
      
      
      
      
 - schedules
      
      
      
      
run tests:
      
      
      
      
 <<: *test-base
      
      
      
      
 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）了，这个文件用来做两件事：

1. 描述这个Job了

2. 描述在 .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}），并在其中部署几个组件：

1. 带有测试脚本的ConfigMap

2. 带有Pod描述和运行测试的 指令的Job

3. 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和其他一些产品的示例。

相关链接：

1. https://github.com/flant/werf

2. https://kubernetes.io/docs/concepts/storage/persistent-volumes/#persistent-volumes

3. https://docs.gitlab.com/ee/ci/junittestreports.html

原文链接：https://medium.com/flant-com/junit-gitlab-ci-kubernetes-27921ec36823

基于Kubernetes的DevOps实战培训

基于Kubernetes的DevOps实战培训将于2019年12月27日在上海开课，3天时间带你系统掌握Kubernetes，学习效果不好可以继续学习。本次培训包括：容器特性、镜像、网络；Kubernetes架构、核心组件、基本功能；Kubernetes设计理念、架构设计、基本功能、常用对象、设计原则；Kubernetes的数据库、运行时、网络、插件已经落地经验；微服务架构、组件、监控方案等，点击下方图片或者阅读原文链接查看详情。