广告

使用Gitlab CI对Kubernetes上的应用进行JUnit测试

  • 浏览(108)
  • 评论(0)
  • 译者:k8s

众所周知,软件测试非常重要,而且也是必要的,我相信很多读者已经在做软件测试了。令人惊讶的是想找到一个“建立两个有联系的选项”的好例子并不容易。我的意思是CICD的问题—我们喜欢用Gitlab和Junit。接下来,我们一起看一看!



背景

首先,定义完整的上下文:

  • 因为我们所有的应用都在Kubernetes上,所以只涵盖了相关基础设施上的测试。

  • 我们用werf构建和部署图片(相当于Helm自然而然地参与到流水线中)。

  • 我不会介绍测试本身的一些细节:我们的测试主要在客户端实现,我们只需要确保其(合并请求中存在相应的报告)正常运行即可。

以下是我们示例的相关操作顺序:

1、构建一个应用-我们将省略此步骤的描述。

2、在Kubernetes集群单独的命名空间部署应用,并运行测试。

3、通过Gitlab检索工件并解析JUnit报告。

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

 现在,让我们开始实践!

GitLab CI

我们将从“.gitlab-ci.yaml”部分开始,描述应用部署及测试运行。由于代码相对较长,我插入了一些详细的注释。

variables: # declare the version of werf we are going to use WERF_VERSION: "1.0 beta" .base_deploy: &base_deploy script: # create the namespace in K8s if it isn’t there - kubectl --context="${WERF_KUBE_CONTEXT}" get ns ${CI_ENVIRONMENT_SLUG} || kubectl create ns ${CI_ENVIRONMENT_SLUG} # load werf and deploy — please check docs for details # (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:-''}" # pass the `run_tests` variable # it will be used during rendering of Helm release --set "global.run_tests=${RUN_TESTS:-no}" --set "global.env=${CI_ENVIRONMENT_SLUG}" # set the timeout (some tests are rather long) # and pass it to the release --set "global.ci_timeout=${CI_TIMEOUT:-900}" --timeout ${CI_TIMEOUT:-900} dependencies:
    - Build .test-base: &test-base extends: .base_deploy before_script: # create the directory for the coming report # using $CI_COMMIT_REF_SLUG - mkdir /mnt/tests/${CI_COMMIT_REF_SLUG} || true # forced workaround 'cause GitLab requires artifacts # in its build directory - mkdir ./tests || true - ln -s /mnt/tests/${CI_COMMIT_REF_SLUG} ./tests/${CI_COMMIT_REF_SLUG} after_script: # delete the release with a Job (and possibly its infrastructure) # after the tests are finished - 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 # we allow failures to happen, but you can decide otherwise allow_failure: true variables: RUN_TESTS: 'yes' # set the context in werf # (https://werf.io/how_to/gitlab_ci_cd_integration.html#infrastructure) WERF_KUBE_CONTEXT: 'admin@stage-cluster' tags: # using runner with the `werf-runner` tag - werf-runner artifacts: # you first have to create an artifact to see it in the pipeline # and download (e.g. for a more thoughtful study) paths:
      - ./tests/${CI_COMMIT_REF_SLUG}/* # artifacts older than one week will be deleted expire_in: 7 day # note: these lines are responsible for parsing the report by GitLab reports: junit: ./tests/${CI_COMMIT_REF_SLUG}/report.xml # to make it simple, only two stages are shown here # you will have more of them in real life, # at least because of deploying stages:
  - build - tests build: stage: build script: # build stage - check details in the werf docs: # (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: # the point of naming the namespace # (https://docs.gitlab.com/ce/ci/variables/predefined_variables.html) name: tests-${CI_COMMIT_REF_SLUG} stage: tests except:
    - schedules

Kubernetes

现在可以创建一个带有任务描述(tests-job.yaml)的YAML文件,所需的Kubernetes资源均在(.helm/templates)目录中。如下所示:

{{- 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描述及实际运行测试指令的任务;

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的构建和部署,但测试pod依然在主节点上运行。在这种情况下,你需要在主节点上创建/ mnt / tests文件夹并将其安装到运行程序中。例如,通过NFS。K8s文档中提供了详细的示例。

我们会得到以下结果:


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目录,然后将其挂载到pods上。

备注

你可能会问,如果可以在shell-runner中轻松运行测试脚本,那么创建任务有什么意义?答案很明显:某些测试需要基础设施(如MongoDB,RabbitMQ,PostgreSQL等)来检查功能。我们的方法是一个统一的解决方案,可以轻松集成其他实例。作为红利,我们获得了标准的部署方法(即使使用NFS和额外的目录安装)。

结果

应用准备好的配置会得到什么结果?

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

点击“error”获得更多信息

备注:细心的读者会注意到我们正在测试Node.js应用程序,但屏幕截图上有一个.NET。不要感到惊讶:虽然我们在初始程序中没有发现任何问题(在写这篇文章的那一刻),但其中一些已在另一个中被揭示。


总结

像你看到的那么简单!

如果你已经有一个shell的工作构建器而不需要Kubernetes,你可以通过测试来补充它,可能比描述的更加毫不费力。可参考 Ruby, Go, Gradle, Maven,以及 GitLab CI文档中的产品示例。


  • 分享到:
  • icon
  • icon
  • icon
  • icon
箭头