И поред тога што сви одлично знају да је тестирање вашег софтвера важно и неопходно, а многи то већ дуже време раде аутоматски, на пространствима Хабра није постојао ни један рецепт за постављање комбинације тако популарних производа у ову нишу као (наш омиљени) ГитЛаб и ЈУнит. Хајде да попунимо ову празнину!
уводни
Прво, дозволите ми да дам неки контекст:
- Пошто све наше апликације раде на Кубернетес-у, размотрићемо покретање тестова на одговарајућој инфраструктури.
- За монтажу и постављање користимо (у смислу инфраструктурних компоненти, ово такође аутоматски значи да је Хелм укључен).
- Нећу улазити у детаље стварног креирања тестова: у нашем случају, клијент сам пише тестове, а ми само обезбеђујемо њихово покретање (и присуство одговарајућег извештаја у захтеву за спајање).
Како ће изгледати општи редослед радњи?
- Израда апликације - изоставићемо опис ове фазе.
- Поставите апликацију у посебан простор имена Кубернетес кластера и почните да тестирате.
- Тражење артефаката и рашчлањивање ЈУнит извештаја помоћу ГитЛаб-а.
- Брисање претходно креираног простора имена.
Сада - на имплементацију!
подешавање
ГитЛаб ЦИ
Почнимо са фрагментом .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Кубернетес
Сада у именику .helm/templates хајде да направимо ИАМЛ са Јобом - tests-job.yaml — за покретање тестова и потребних Кубернетес ресурса. Погледајте објашњења након навођења:
{{- 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}) и развуците га:
- ЦонфигМап са тест скриптом;
- посао са описом под и наведеном директивом
command, који само покреће тестове; - ПВ и ПВЦ, који вам омогућавају да чувате тестне податке.
Обратите пажњу на уводни услов са if на почетку манифеста - сходно томе, друге ИАМЛ датотеке Хелм графикона са апликацијом морају бити умотане у обрнуто дизајнирати тако да се не распоређују током тестирања. То је:
{{- if ne .Values.global.run_tests "yes" }}
---
я другой ямлик
{{- end }}Међутим, ако тестови захтевају одређену инфраструктуру (на пример, Редис, РаббитМК, Монго, ПостгреСКЛ...) - њихови ИАМЛ-ови могу бити не искључи. Поставите их иу тестно окружење... прилагођавајући их како вам одговара, наравно.
Финал тоуцх
Јер монтажу и постављање користећи верф за сада само на буилд серверу (са гитлаб-руннер-ом), а под са тестовима је покренут на мастеру, мораћете да креирате директоријум /mnt/tests на господара и дај га тркачу, на пример, преко НФС-а. Детаљан пример са објашњењима може се наћи у .
Резултат ће бити:
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Нико не забрањује прављење НФС дељења директно на гитлаб-руннер-у, а затим га монтирање у подове.
Приметити
Можда се питате зашто све компликовати креирањем Јоб-а ако можете једноставно да покренете скрипту са тестовима директно на схелл руннер-у? Одговор је сасвим тривијалан...
Неки тестови захтевају приступ инфраструктури (МонгоДБ, РаббитМК, ПостгреСКЛ, итд.) да би се проверило да ли раде исправно. Обједињавамо тестирање – са овим приступом постаје лако укључити такве додатне ентитете. Поред овога добијамо стандард приступ имплементацији (чак и ако користите НФС, додатно монтирање директоријума).
Резултат
Шта ћемо видети када применимо припремљену конфигурацију?
Захтев за спајање ће приказати збирну статистику за тестове који се покрећу у свом најновијем цевоводу:
Свака грешка се може кликнути овде за детаље:
NB: Пажљиви читалац ће приметити да тестирамо НодеЈС апликацију, а на снимцима екрана - .НЕТ... Немојте се изненадити: само што током припреме чланка нису пронађене грешке у тестирању прве апликације, али оне пронађени су у другом.
Закључак
Као што видите, ништа компликовано!
У принципу, ако већ имате колектор шкољки и он ради, али вам не треба Кубернетес, прикључивање тестирања на њега биће још једноставнији задатак него што је овде описано. А у наћи ћете примере за Руби, Го, Градле, Мавен и неке друге.
ПС
Прочитајте и на нашем блогу:
- «";
- «";
- «'.
Извор: ввв.хабр.цом