使用GitLab CI运行Kubernetes里的应用程序的JUnit测试
摘要:我们将会在部署期间为应用程序创建一个唯一的命名空间( .gitlab-ci.yaml 文件中定义了命名空间 — tests-$ {CI_COMMIT_REF_SLUG} ),并在其中部署几个组件:。echo "${APP_NAME} TESTS"。
每个人都知道软件测试的重要性和必要性-我相信许多人都坚持这样做。但出乎意料的是,我很难找到一个很好的例子来用GitLab和JUnit配置CI / CD。让我来填补这个空白。
背景
首先,让我定义完整的上下文:
- 由于我们所有的应用程序都在Kubernetes中运行,因此我仅介绍相关架构中的测试
- 我会使用 werf 来构建和部署映像(这意味着Helm也会参与到流水线中)
- 我不会详细介绍测试本身:在我们的案例中,测试是在使用者实施的,我们仅确保测试正常运行(并在合并请求中显示相应的报告)
以下是我们的示例中常见的操作顺序:
- 构建应用程序-我们将省略此步骤的描述
- 将应用程序部署到Kubernetes集群的独立命名空间并运行测试
- 通过GitLab检索artifacts并解析JUnit报告
- 删除之前创建的命名空间
让我们开始实践吧!
GitLab CI (Continuous Integration, 持续集成)
我们将从 .gitlab-ci.yaml
的代码开始,以下部分描述了应用程序的部署和运行测试。代码有点长,我在其中插入了详细的注释:
variables:
声明我们将使用的werf的版本
WERF_VERSION: "1.0 beta"
.base_deploy: &base_deploy
script:
如果K8S不存在该命名空间则创建命名空间
- kubectl --context="${WERF_KUBE_CONTEXT}" get ns ${CI_ENVIRONMENT_SLUG} || kubectl create ns ${CI_ENVIRONMENT_SLUG}
加载werf并部署 - 详情请查看文档
( https://werf.io/how_to/gitlab_ ... -stag e)
- 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_ ... uctur e)
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_ ... -stag e)
- 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/ ... s.htm l)
name: tests-${CI_COMMIT_REF_SLUG}
stage: tests
except:
- schedules
Kubernetes
现在是时候创建一个YAML文件( tests-job.yaml
)了,这个文件用来做两件事
.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}
),并在其中部署几个组件:
- 带有测试脚本的 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 。 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目录,然后将其安装到pod上。
注释
您可能会问,如果可以轻松地在shell中运行测试脚本,那么创建Job的意义何在?答案很明显:
有些测试需要基础架构(例如MongoDB,RabbitMQ,PostgreSQL等)来检查功能。我的方法是一个统一的解决方案,可以轻松集成其他实例。另外,我们获得了 标准 的部署方法(即使用NFS和额外的目录)。
结果
如果应用提前准备好的配置会是什么结果?
合并请求中将显示在其先前流水线中执行的测试的摘要:
单击错误获取更多信息:
*注意:细心的读者会注意到我们正在测试Node.js应用程序,但是屏幕截图上有一个.NET。不必感到惊讶:虽然我们在原始的应用程序中没有发现任何问题,但在另一个应用程序中暴露出了一些小问题。
结论
如您所见,它是如此简单!
如果您已经有可以使用的Shell脚本并且不需要Kubernetes,则可以通过更简单的方法实现以上例子。 请查看 GitLab CI 文档 。CI文档中提供了Ruby,Go,Gradle,Maven和其他一些产品的示例。