ProHoster > Блог > Администриране > JUnit в GitLab CI с Kubernetes

JUnit в GitLab CI с Kubernetes

Въпреки че всички прекрасно знаят, че е важно и необходимо да тестваме софтуера си, а много хора вече го правят автоматично, на пространството на Хабра не намерихме нито една рецепта за настройка на комбинация от толкова популярни продукти в тази ниша, като (нашия любим) GitLab и JUnit. Нека запълним тази празнина!

JUnit в GitLab CI с Kubernetes

Въведителни

Първо, нека уточня контекста:

  • Тъй като всичките ни приложения работят в Kubernetes, ще разгледаме стартирането на тестовете в съответната инфраструктура.
  • За изграждане и внедряване използваме werf (в смисъл на инфраструктурни компоненти, това автоматично означава, че е включен Helm).
  • Няма да задълбавам в детайлите около създаването на тестовете: в нашия случай клиентът пише тестовете сам, а ние само осигуряваме тяхното стартиране (и наличието на съответен отчет в merge request’а).


Как ще изглежда общата последователност на действията?

  1. Изграждане на приложението — описание на този етап ще пропуснем.
  2. Внедряване на приложението в отделен namespace на кластера Kubernetes и стартиране на тестването.
  3. Намиране на артефакти и парсиране на JUnit-отчета от GitLab.
  4. Изтриване на създадения по-рано namespace.

Сега — към реализацията!

Настройка

GitLab CI

Нека започнем с фрагмент .gitlab-ci.yaml, който описва внедряването на приложението и стартирането на тестовете. Листингът се получи доста обемен, затова е обстойно допълнен с коментари:

променливи:
# обявяваме версията на werf, която ще използваме
  WERF_VERSION: "1.0 beta"

.base_deploy: &base_deploy
  скрипт:
# създаваме 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}
  зависимости:
    - Build

.test-base: &test-base
  разширява: .base_deploy
  преди_скрипт:
# създаваме директория за бъдещия отчет, въз основа на $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}
  след_скрипт:
# след завършване на тестовете, изтриваме релиза заедно с 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
  променливи:
    RUN_TESTS: 'yes'
# задаваме контекста в werf
# (https://werf.io/how_to/gitlab_ci_cd_integration.html#infrastructure)
    WERF_KUBE_CONTEXT: 'admin@stage-cluster'
  тагове:
# използваме ръннер с таг `werf-runner`
    - werf-runner
  артефакти:
# нужно е да съберем артефакт, за да може да бъде видян
# в пайплайна и изтеглен — например, за по-задълбочено проучване
    paths:
      - ./tests/${CI_COMMIT_REF_SLUG}/*
# артефактите, по-възрастни от седмица, ще бъдат изтрити
    expire_in: 7 day
# важно: тези редове отговарят за парсинга на отчета от GitLab
    reports:
      junit: ./tests/${CI_COMMIT_REF_SLUG}/report.xml

# за опростяване тук са показани само две стадии
# в действителност ще имате повече — поне заради деплоя
стадии:
  - build
  - tests

build:
  stage: build
  скрипт:
# изграждане — отново по документацията на 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
  тагове:
    - werf-runner
  except:
    - schedules

run tests:
  <<: *test-base
  среда:
# "самата сол" на именуването на 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}\/\n
    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\/\n          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\/\n  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}) и в него разглеждаме:

  1. ConfigMap със скрипта за теста;
  2. Работа с описанието на pod’а и указаната директива command, която стартира тестовете;
  3. PV и PVC, които позволяват съхранение на данните от тестовете.

Обърнете внимание на условието в if в началото на манифеста — следователно, другите YAML файлове от Helm-чарта на приложението трябва да бъдат поставени в обратната конструкция, за да не се деплоят при тестове. Тоест:

{{- if ne .Values.global.run_tests "yes" }}
---
аз друг YAML файл
{{- 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-а ще бъде показана обобщена статистика за тестовете, стартирани в последния му пайплайн:

JUnit в GitLab CI с Kubernetes

На всяка грешка тук може да се кликне, за да получите подробности:

JUnit в GitLab CI с Kubernetes

NB: Внимателният читател ще забележи, че тестваме NodeJS приложение, а на скрийншотовете — .NET… Не се учудвайте: просто в рамките на подготовката на статията не е имало грешки в тестването на първото приложение, но сме намерили грешки в другото.

Заключение

Както виждате, нищо сложно!

По принцип, ако вече имате shell-сборка и тя работи, а Kubernetes не ви е необходим — свързването на тестове към нея ще бъде още по-проста задача, отколкото описаната тук. А в документацията на GitLab CI ще намерите примери за Ruby, Go, Gradle, Maven и някои други.

P.S.

Прочетете също в нашия блог:

Източник: habr.com

Купете надежден хостинг за сайтове с защита от DDoS, VPS VDS сървъри 🔥 Купете надежден хостинг за сайтове с защита от DDoS, VPS VDS сървъри | ProHoster