JUnit GitLab CI-ში Kubernetes-თან ერთად

იმისდა მიუხედავად, რომ ყველამ მშვენივრად იცის, რომ თქვენი პროგრამული უზრუნველყოფის ტესტირება მნიშვნელოვანია და აუცილებელია, და ბევრი ამას აკეთებს ავტომატურად დიდი ხნის განმავლობაში, ჰაბრის უზარმაზარ სივრცეში არ არსებობდა არც ერთი რეცეპტი ასეთი პოპულარული პროდუქტების კომბინაციის დასაყენებლად. ეს ნიშა, როგორც (ჩვენი საყვარელი) GitLab და JUnit. შევავსოთ ეს ხარვეზი!

შესავალი

პირველ რიგში, ნება მიბოძეთ მოგცეთ კონტექსტი:

• ვინაიდან ყველა ჩვენი აპლიკაცია მუშაობს Kubernetes-ზე, განვიხილავთ ტესტების გაშვებას შესაბამის ინფრასტრუქტურაზე.
• შეკრებისა და განლაგებისთვის ჩვენ ვიყენებთ ვერფ (ინფრასტრუქტურული კომპონენტების თვალსაზრისით, ეს ასევე ავტომატურად ნიშნავს, რომ Helm არის ჩართული).
• მე არ შევუდგები ტესტების ფაქტობრივი შექმნის დეტალებს: ჩვენს შემთხვევაში, კლიენტი თავად წერს ტესტებს და ჩვენ მხოლოდ უზრუნველვყოფთ მათ გაშვებას (და შესაბამისი ანგარიშის არსებობას შერწყმის მოთხოვნაში).

როგორი იქნება მოქმედებების ზოგადი თანმიმდევრობა?

1. აპლიკაციის აგება - ამ ეტაპის აღწერას გამოვტოვებთ.
2. განათავსეთ აპლიკაცია Kubernetes კლასტერის ცალკეულ სახელთა სივრცეში და დაიწყეთ ტესტირება.
3. არტეფაქტების ძიება და JUnit ანგარიშების ანალიზი GitLab-ით.
4. ადრე შექმნილი სახელების სივრცის წაშლა.

ახლა - განხორციელებამდე!

რეგულირება

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

კუბერნეტები

ახლა დირექტორიაში .helm/templates მოდით შევქმნათ YAML სამუშაოსთან ერთად - 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}) და გააფართოვეთ:

1. ConfigMap ტესტის სკრიპტით;
2. სამუშაო პოდის აღწერილობით და მითითებული დირექტივით command, რომელიც უბრალოდ ატარებს ტესტებს;
3. PV და PVC, რომელიც საშუალებას გაძლევთ შეინახოთ ტესტის მონაცემები.

ყურადღება მიაქციეთ შესავალი პირობას if მანიფესტის დასაწყისში - შესაბამისად, Helm სქემის სხვა YAML ფაილები აპლიკაციასთან ერთად უნდა იყოს შეფუთული უკუ დიზაინი ისე, რომ ისინი არ განლაგდნენ ტესტირების დროს. ანუ:

{{- if ne .Values.global.run_tests "yes" }}
---
я другой ямлик
{{- end }}

თუმცა თუ ტესტები მოითხოვს გარკვეულ ინფრასტრუქტურას (მაგალითად, Redis, RabbitMQ, Mongo, PostgreSQL...) - მათი YAML შეიძლება იყოს არარის გამორთვა. განათავსეთ ისინი სატესტო გარემოშიც... დაარეგულირეთ ისინი, როგორც თქვენთვის შესაფერისია, რა თქმა უნდა.

საბოლოო შეხება

იმიტომ რომ შეკრება და განლაგება werf სამუშაოების გამოყენებით ამჟამად მხოლოდ build სერვერზე (gitlab-runner-ით) და ტესტების მქონე pod გაშვებულია მასტერზე, თქვენ უნდა შექმნათ დირექტორია /mnt/tests ოსტატზე და მიეცი მორბენალს, მაგალითად, 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-ზე, შემდეგ კი მის პოდებში დამონტაჟებას.

შენიშვნა

შეიძლება გკითხოთ, რატომ ართულებთ ყველაფერს სამუშაოს შექმნით, თუ თქვენ შეგიძლიათ უბრალოდ აწარმოოთ სკრიპტი ტესტებით პირდაპირ shell runner-ზე? პასუხი საკმაოდ ტრივიალურია...

ზოგიერთი ტესტი საჭიროებს წვდომას ინფრასტრუქტურაზე (MongoDB, RabbitMQ, PostgreSQL და ა.შ.), რათა დაადასტუროს, რომ ისინი სწორად მუშაობენ. ჩვენ ტესტირებას ვქმნით უნიფიცირებულს - ამ მიდგომით ადვილი ხდება ასეთი დამატებითი ერთეულების ჩართვა. ამას გარდა ვიღებთ სტანდარტი განლაგების მიდგომა (თუნდაც NFS-ის გამოყენებით, დირექტორიების დამატებითი მონტაჟი).

შედეგი

რას დავინახავთ მომზადებული კონფიგურაციის გამოყენებისას?

შერწყმის მოთხოვნა აჩვენებს შემაჯამებელ სტატისტიკას მის უახლეს მილსადენში ჩატარებული ტესტებისთვის:

თითოეული შეცდომა შეიძლება დააწკაპუნოთ აქ დეტალებისთვის:

NB: ყურადღებიანი მკითხველი შეამჩნევს, რომ ვამოწმებთ NodeJS აპლიკაციას, ხოლო სკრინშოტებში - .NET... ნუ გაგიკვირდებათ: უბრალოდ, სტატიის მომზადებისას პირველი აპლიკაციის ტესტირებაში შეცდომები არ აღმოჩნდა, მაგრამ ისინი სხვაში აღმოაჩინეს.

დასკვნა

როგორც ხედავთ, არაფერია რთული!

პრინციპში, თუ თქვენ უკვე გაქვთ ჭურვის კოლექტორი და ის მუშაობს, მაგრამ არ გჭირდებათ Kubernetes, მასზე ტესტირების მიმაგრება კიდევ უფრო მარტივი ამოცანა იქნება, ვიდრე აქ აღწერილია. Და ში GitLab CI დოკუმენტაცია თქვენ ნახავთ მაგალითებს Ruby, Go, Gradle, Maven და ზოგიერთი სხვა.

PS

ასევე წაიკითხეთ ჩვენს ბლოგზე:

• «საუკეთესო CI/CD პრაქტიკა Kubernetes-თან და GitLab-თან (მიმოხილვა და ვიდეო ანგარიში)";
• «რჩევები GitLab CI-ში მორგებული სამუშაო ნაკადების შესაქმნელად";
• «GitLab CI წარმოებაში უწყვეტი ინტეგრაციისა და მიწოდებისთვის".

წყარო: www.habr.com