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, описващ деплоя на приложението и стартирането на тестовете. Листингът стана доста обемен, затова е обстойно допълнен с коментари:

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} ТЕСТОВЕ"
    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}) и в него деплоираме:

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

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

{{- if ne .Values.global.run_tests "yes" }}
---
друг yaml файл
{{- end }}

Въпреки това, ако тестовете изискват определена инфраструктура (например, Redis, RabbitMQ, Mongo, PostgreSQL…) — техните YAML файлове могат не изключване. Разширете и ги в тестова среда… разбира се, коригирайки по ваше усмотрение.

Финален щрих

Тъй като изграждането и разполагането с помощта на werf все още работи само на build-сервера (с gitlab-runner), а пода с тестовете се стартира на мастер, ще е необходимо да се създаде директория /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 и след това да я монтирате в подовете.

Забележка

Възможно е да зададете въпроса, защо изобщо да усложняваме нещата, създавайки Job, ако просто можем да стартираме скрипта с тестовете направо на shell-раннера? Отговорът е доста тривиален...

Някои тестове изискват достъп до инфраструктура (MongoDB, RabbitMQ, PostgreSQL и др.) за проверка на коректността на работата с тях. Ние правим тестването унифицирано — с такъв подход включването на подобни допълнителни единици става лесно. В допълнение, получаваме стандартен подход в разполагането (въпреки че и с използване на NFS, допълнително монтиране на директории).

Резултат

Какво ще видим, когато приложим подготвената конфигурация?

В merge request ще бъде показана сводна статистика по тестовете, стартирани в последния му pipeline:

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