Вводные
Для начала обозначу контекст:
- Так как все наши приложения работают в Kubernetes, будет рассмотрен запуск тестов в соответствующей инфраструктуре.
- Для сборки и деплоя мы используем werf (в смысле инфраструктурных компонентов это также автоматически означает, что задействован Helm).
- В детали непосредственного создания тестов вдаваться не буду: в нашем случае клиент пишет тесты сам, а мы лишь обеспечиваем их запуск (и наличие соответствующего отчета в merge request’е).
Как будет выглядеть общая последовательность действий?
- Сборка приложения — описание этого этапа мы опустим.
- Деплой приложения в отдельный namespace кластера Kubernetes и запуск тестирования.
- Поиск артефактов и парсинг JUnit-отчета GitLab’ом.
- Удаление созданного ранее namespace’а.
Теперь — к реализации!
Настройка
GitLab CI
Начнем с фрагмента .gitlab-ci.yaml, описывающего деплой приложения и запуск тестов. Листинг получился довольно объемным, поэтому основательно дополнен комментариями:
variables: # объявляем версию werf, которую собираемся использовать WERF_VERSION: "1.0 beta" .base_deploy: &base_deploy script: # создаем namespace в K8s, если его нет - 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}" # изменяем timeout (бывают долгие тесты) и передаем его в релиз --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 хочет получить артефакты в своем build-dir’е - mkdir ./tests || true - ln -s /mnt/tests/${CI_COMMIT_REF_SLUG} ./tests/${CI_COMMIT_REF_SLUG} after_script: # после окончания тестов удаляем релиз вместе с Job’ом # (и, возможно, его инфраструктурой) - 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 # (https://werf.io/how_to/gitlab_ci_cd_integration.html#infrastructure) WERF_KUBE_CONTEXT: 'admin@stage-cluster' tags: # используем раннер с тегом `werf-runner` - werf-runner artifacts: # требуется собрать артефакт для того, чтобы его можно было увидеть # в пайплайне и скачать — например, для более вдумчивого изучения paths: - ./tests/${CI_COMMIT_REF_SLUG}/* # артефакты старше недели будут удалены expire_in: 7 day # важно: эти строки отвечают за парсинг отчета GitLab’ом reports: junit: ./tests/${CI_COMMIT_REF_SLUG}/report.xml # для упрощения здесь показаны всего две стадии # в реальности же у вас их будет больше — как минимум из-за деплоя stages: - build - tests build: stage: build script: # сборка — снова по документации по 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: # "сама соль" именования namespace’а # (https://docs.gitlab.com/ce/ci/variables/predefined_variables.html) name: tests-${CI_COMMIT_REF_SLUG} stage: tests except: - schedules
Kubernetes
Теперь в директории .helm/templates создадим YAML с Job’ом — tests-job.yaml — для запуска тестов и необходимыми ему ресурсами 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 }} Что за ресурсы описаны в этой конфигурации? При деплое создаем уникальный для проекта namespace (это указано еще в .gitlab-ci.yaml — tests-${CI_COMMIT_REF_SLUG}) и в него выкатываем:
- ConfigMap со скриптом теста;
- Job с описанием pod’а и указанной директивой
command, которая как раз и запускает тесты; - PV и PVC, что позволяют хранить данные тестов.
Обратите внимание на вводное условие с if в начале манифеста — соответственно, другие YAML-файлы Helm-чарта с приложением надо обернуть в обратную конструкцию, чтобы они не деплоились при тестировании. То есть:
{{- if ne .Values.global.run_tests "yes" }} --- я другой ямлик {{- end }}Впрочем, если тесты требуют некоторую инфраструктуру (например, Redis, RabbitMQ, Mongo, PostgreSQL…) — их YAML’ы можно не выключать. Разверните и их в тестовой среде… конечно же, подправив по своему усмотрению.
Финальный штрих
Т.к. сборка и деплой с помощью werf пока что работает только на build-сервере (с gitlab-runner), а pod с тестами запускается на мастере, потребуется создать директорию /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Никто не запрещает и сделать NFS-шару прямо на gitlab-runner’е, после чего монтировать её в pod’ы.
Примечание
Возможно, вы спросите, зачем вообще все усложнять созданием Job’а, если можно просто запустить скрипт с тестами прямо на shell-раннере? Ответ достаточно тривиален…
Некоторые тесты требуют обращения к инфраструктуре (MongoDB, RabbitMQ, PostgreSQL и т.п.) для проверки корректности работы с ними. Мы делаем тестирование унифицированным — при таком подходе включать подобные дополнительные сущности становится легко. Вдобавок к этому, мы получаем стандартный подход в деплое (пусть даже и с использованием NFS, дополнительным монтированием каталогов).
Результат
Что мы увидим, когда применим подготовленную конфигурацию?
В merge request’е будет показана сводная статистика по тестам, запущенным в его последнем пайплайне:
На каждую ошибку здесь можно нажать, чтобы получить подробности:
NB: Внимательный читатель заметит, что мы тестируем NodeJS-приложение, а на скриншотах — .NET… Не удивляйтесь: просто в рамках подготовки статьи не нашлось ошибок в тестировании первого приложения, зато нашли их в другом.
Заключение
Как видно, ничего сложного!
В принципе, если у вас уже есть shell-сборщик и он работает, а Kubernetes вам не нужен — прикрутить к нему тестирование будет еще более простой задачей, чем описанная здесь. А в документации GitLab CI вы найдете примеры для Ruby, Go, Gradle, Maven и некоторых других.
P.S.
Читайте также в нашем блоге:
ссылка на оригинал статьи https://habr.com/ru/company/flant/blog/460897/
Добавить комментарий