ProHoster > Blog > Adminisztráció > JUnit a GitLab CI-vel a Kubernetes alatt

JUnit a GitLab CI-vel a Kubernetes alatt

Bár mindenki jól tudja, hogy fontos és szükséges tesztelni a szoftverét, és sokan már régóta automatizáltan teszik ezt, a Habr területén nem találtunk egyetlen receptet sem a népszerű termékek, mint például (szeretett) GitLab és JUnit összekapcsolásának beállításáról. Pótoljuk ezt a hiányosságot!

JUnit a GitLab CI-vel a Kubernetes alatt

Bevezető

Első lépésként jelzem a kontextust:

  • Mivel minden alkalmazásunk Kubernetesben fut, a tesztek indítását a megfelelő infrastruktúrában fogjuk megvizsgálni.
  • A build és deploy folyamathoz használjuk werf (az infrastruktúra elemeit figyelembe véve ez automatikusan azt is jelenti, hogy Helm is használatban van).
  • A tesztek konkrét létrehozásának részleteire nem fogok kitérni: az esetünkben az ügyfél írja a teszteket, mi csak biztosítjuk a futtatásukat (és a megfelelő jelentés meglétét a merge request-ben).


Milyen lesz az általános lépések sorrendje?

  1. Az alkalmazás buildelése — ennek a lépésnek a leírását kihagyjuk.
  2. Az alkalmazás deployálása a Kubernetes klaszter egy külön namespace-ében és a tesztelés indítása.
  3. Artefaktumok keresése és a JUnit-jelentés parse-olása GitLab által.
  4. A korábban létrehozott namespace törlése.

Most — a megvalósításra!

Beállítás

GitLab CI

Kezdjük a frakcióval .gitlab-ci.yaml, amely leírja az alkalmazás deployálását és a tesztek futtatását. A lista meglehetősen terjedelmes lett, ezért alaposan kiegészítettük megjegyzésekkel:

változók:
# nyilvántartjuk a használandó werf verziót
  WERF_VERSION: "1.0 beta"

.base_deploy: &base_deploy
  script:
# namespace létrehozása a K8s-ben, ha az nem létezik
    - kubectl --context="${WERF_KUBE_CONTEXT}" get ns ${CI_ENVIRONMENT_SLUG} || kubectl create ns ${CI_ENVIRONMENT_SLUG}
# werf betöltése és telepítése — erről bővebben a dokumentációban olvashat
# (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:-''}"
# adja át a `run_tests` változót
# ezt a Helm-kiadás renderelésében használják
      --set "global.run_tests=${RUN_TESTS:-no}"
      --set "global.env=${CI_ENVIRONMENT_SLUG}"
# módosítja a timeout-ot (vannak hosszú tesztek) és átadja azt a kiadásnak
      --set "global.ci_timeout=${CI_TIMEOUT:-900}"
     --timeout ${CI_TIMEOUT:-900}
  dependencies:
    - Build

.test-base: &test-base
  extends: .base_deploy
  before_script:
# mappa létrehozása a jövőbeli jelentés számára, a $CI_COMMIT_REF_SLUG alapján
    - mkdir /mnt/tests/${CI_COMMIT_REF_SLUG} || true
# kényszermegoldás, mert a GitLab az artefaktumokat a saját build-mappájában akarja
    - mkdir ./tests || true
    - ln -s /mnt/tests/${CI_COMMIT_REF_SLUG} ./tests/${CI_COMMIT_REF_SLUG}
  after_script:
# a tesztek befejezését követően a kiadást töröljük a Job-bal együtt
# (és esetleg annak infrastruktúrájával)
    - 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
# engedélyezünk hibákat, de másképp is eljárhat
  allow_failure: true
  variables:
    RUN_TESTS: 'yes'
# összefüggés megadása a werf-ben
# (https://werf.io/how_to/gitlab_ci_cd_integration.html#infrastructure)
    WERF_KUBE_CONTEXT: 'admin@stage-cluster'
  tags:
# `werf-runner` címkézővel rendelkező futtatót használunk
    - werf-runner
  artifacts:
# artefaktum gyűjtése, hogy azt láthassuk
# a pipeline-ban és letölthessük — például alaposabb tanulmányozás céljából
    paths:
      - ./tests/${CI_COMMIT_REF_SLUG}/*
# a hétnél idősebb artefaktumokat töröljük
    expire_in: 7 day
# fontos: ezek a sorok felelősek a GitLab átiratainak elemzéséért
    reports:
      junit: ./tests/${CI_COMMIT_REF_SLUG}/report.xml

# egyszerűsítve itt csak két szakasz látható
# valójában több lesz — legalább a telepítés miatt
stages:
  - build
  - tests

build:
  stage: build
  script:
# építés — ismét a werf dokumentációja alapján
# (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:
# "a név" a namespace elnevezéséhez
# (https://docs.gitlab.com/ce/ci/variables/predefined_variables.html)
    name: tests-${CI_COMMIT_REF_SLUG}
  stage: tests
  except:
    - schedules

Kubernetes

Most már a könyvtárban .helm/templates YAML-t hozunk létre a Job-hoz - tests-job.yaml — a tesztek futtatásához és a Kubernetes számára szükséges erőforrásokkal. További magyarázatok a lista után találhatók:

{{- if eq .Values.global.run_tests "yes" }}
---
apiVersion: v1
kind: ConfigMap
metadata:
  name: tests-script
data:
  tests.sh: |
    echo "======================"
    echo "${APP_NAME} TESZTEK"
    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 }}

Milyen erőforrások vannak leírva ebben a konfigurációban? A telepítés során egy projekt-specifikus namespace-t hozunk létre (ezt még a .gitlab-ci.yaml — tests-${CI_COMMIT_REF_SLUG}) név alatt, és ebbe telepítjük:

  1. ConfigMap a teszt scriptet;
  2. Feladat a pod leírását és a megadott direktívát command, ami pontosan futtatja a teszteket;
  3. PV és PVC, amelyek lehetővé teszik a tesztadatok tárolását.

Felhívjuk a figyelmet a bevezető feltételre a if a manifest elején — ennek megfelelően a más YAML-fájlokat, amelyeket a Helm chart az alkalmazásról tartalmaz, a fordított szerkezetbe kell csomagolni, hogy ne települjenek a tesztelés során. Tehát:

{{- if ne .Values.global.run_tests "yes" }}
---
itt egy másik yaml
{{- end }}

Egyébként, ha a tesztek valamilyen infrastruktúrát igényelnek (például Redis, RabbitMQ, Mongo, PostgreSQL…) — ezek YAML fájljai megoldhatók. nem kapcsolja ki. Bővítse ki őket tesztkörnyezetben... természetesen a saját belátása szerint módosítva.

Végső simítás

Mivel a build és deploy a werf használatával még mindig működik a fő DB példányhoz a build szerveren (gitlab-runner segítségével), míg a tesztelést végző pod a mester gépen fut, létre kell hozni egy könyvtárat /mnt/tests a mesteren, és azt át kell adni a runner-nek, például NFS-en keresztül. A kibővített példát magyarázatokkal a K8s dokumentációjában.

Az eredmény a következő lesz:

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

Senki nem tilthatja meg, hogy közvetlenül a gitlab-runner-en hozzon létre NFS-megosztást, amelyet utána a pod-okba csatlakoztat.

Megjegyzés

Talán megkérdezi, miért bonyolítjuk a Job létrehozását, ha egyszerűen csak futtathatjuk a tesztelő szkriptet közvetlenül a shell-ronner-en? A válasz elég triviális...

Egyes tesztek infrastruktúrára (MongoDB, RabbitMQ, PostgreSQL stb.) támaszkodnak a működésük helyességének ellenőrzésére. Egységesítjük a tesztelést - ezzel a megközelítéssel könnyen bevonhatók hasonló kiegészítő elemek. Ezen kívül kapunk alapértelmezett megközelítést a telepítéshez (még akkor is, ha NFS-t használunk, további mappák csatlakoztatásával).

Eredmény

Mit fogunk látni, amikor alkalmazzuk a kész konfigurációt?

A merge request-ben összegző statisztika jelenik meg a legutóbbi pipeline-jában futott tesztekről:

JUnit a GitLab CI-vel a Kubernetes alatt

Itt minden hiba mellett kattinthat, hogy részleteket kapjon:

JUnit a GitLab CI-vel a Kubernetes alatt

NB: Figyelmes olvasó észreveszi, hogy NodeJS alkalmazást tesztelünk, míg a képernyőképeken .NET látható... Ne lepődjön meg: csak a cikk előkészítése során nem találtunk hibákat az első alkalmazás tesztelésében, viszont a másikban igen.

Zárás

Mint látható, semmi bonyolult!

Elvileg, ha már rendelkezik shell build-errel, és az működik, akkor a Kubernetes-re nincs szüksége - a tesztelést hozzácsatolni sokkal egyszerűbb feladat, mint amilyet itt leírtunk. A GitLab CI dokumentációjában példákat talál Ruby, Go, Gradle, Maven és néhány más számára.

P.S.

Olvasson további információkat a blogunkban:

Forrás: habr.com

Megbízható hosting vásárlása weboldalak számára, DDoS védelemmel, VPS VDS szerverek. 🔥 Megbízható webtárhely vásárlása DDoS védelemmel, VPS VDS szerverek | ProHoster