🥇JUnit GitLab CI-s Kubernetesiga

Kuigi kõik teavad, et oma tarkvara testimine on oluline, ja paljud teevad seda juba automaatselt, ei leidunud Habras ühtegi retsepti, mis käsitleks selliste populaarsete toodete nagu (meie lemmik) GitLab ja JUnit seostamist. Täidame selle tühimiku!

Sissejuhatus

Alustuseks määratleksin konteksti:

Kuna kõik meie rakendused töötavad Kuberneteses, arutame testide käivitamist vastavas infrastruktuuris.
Kogumise ja juurutamise jaoks kasutame werf (infrastruktuuri komponente silmas pidades tähendab see ka automaatselt, et on kasutusel Helm).
Katsesideme loomise detailidesse süvenema ei hakka: meie puhul kirjutab kliendi testid ise ning meie tagame vaid nende käivitamise (ja vastava aruande olemasolu merge request'is).

Kuidas näeb välja üldine tegevuste järjestus?

Rakenduse kogumine — selle etapi kirjeldamise jätame kõrvale.
Rakenduse juurutamine eraldi Kubernetes klastrinimesse ja testimise käivitamine.
Artefaktide otsimine ja JUnit aruande parsimine GitLabi poolt.
Varasemalt loodud nimede asendamine eemaldamine.

Nüüd — rakenduse juurde!

Seadistamine

GitLab CI

Alustame lõigust .gitlab-ci.yaml, mis sisaldab rakenduse juurutamise ja testide käivitamise kirjeldust. Loend osutus üsna mahukaks, seega on see hoolikalt täiendatud kommentaaridega:

muutujad:
# kuulutame välja werf versiooni, mida plaanime kasutada
  WERF_VERSION: "1.0 beta"

.base_deploy: &base_deploy
  skript:
# loome K8s-i nimelruumi, kui seda pole
    - kubectl --context="${WERF_KUBE_CONTEXT}" get ns ${CI_ENVIRONMENT_SLUG} || kubectl create ns ${CI_ENVIRONMENT_SLUG}
# laeme werfi ja teeme väljalaskmise — lähemalt vt dokumentatsioonis
# (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:-''}"
# edastame muutuja `run_tests`
# seda kasutatakse Helm-väljalaske renderdamisel
      --set "global.run_tests=${RUN_TESTS:-no}"
      --set "global.env=${CI_ENVIRONMENT_SLUG}"
# muudame timeouti (kasutada võib pikki teste) ja edastame selle väljalaskesse
      --set "global.ci_timeout=${CI_TIMEOUT:-900}"
     --timeout ${CI_TIMEOUT:-900}
  sõltuvused:
    - Ehitus

.test-base: &test-base
  laiendab: .base_deploy
  before_script:
# loome kausta tulevase aruande jaoks, lähtudes $CI_COMMIT_REF_SLUG-st
    - mkdir /mnt/tests/${CI_COMMIT_REF_SLUG} || true
# sunnitud lahendus, kuna GitLab soovib, et saaks arhiivid oma build-dir’isse
    - mkdir ./tests || true
    - ln -s /mnt/tests/${CI_COMMIT_REF_SLUG} ./tests/${CI_COMMIT_REF_SLUG}
  after_script:
# pärast testide lõppemist eemaldame väljalaske koos Job’iga
# (ja võib-olla ka selle infrastruktuuriga)
    - 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
# lubame vead, kuid võite teha teisiti
  allow_failure: true
  muutujad:
    RUN_TESTS: 'jah'
# määrame konteksti werf-is
# (https://werf.io/how_to/gitlab_ci_cd_integration.html#infrastructure)
    WERF_KUBE_CONTEXT: 'admin@stage-cluster'
  sildid:
# kasutame jooksjat sildiga `werf-runner`
    - werf-runner
  artefaktid:
# oluline on koguda artefakt, et saaks seda näha
# protsessis ja alla laadida — näiteks hoolikalt uurimiseks
    teed:
      - ./tests/${CI_COMMIT_REF_SLUG}/*
# nädala vanused artefaktid eemaldatakse
    expire_in: 7 päeva
# oluline: need read vastutavad GitLab-i aruande parsimise eest
    aruanded:
      junit: ./tests/${CI_COMMIT_REF_SLUG}/report.xml

# lihtsustamiseks on siin näidatud vaid kaks etappi
# tegelikult on neid rohkem — vähemalt väljalaskmise tõttu
etapid:
  - ehitus
  - testid

ehitus:
  etapp: ehitus
  skript:
# kokkupanek — jälle werfi dokumentatsiooni järgi
# (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
  sildid:
    - werf-runner
  välja arvatud:
    - ajakavad

testide käitamine:
  <<: *test-base
  keskkond:
# "nime" nimete ruumi nimed
# (https://docs.gitlab.com/ce/ci/variables/predefined_variables.html)
    nimi: tests-${CI_COMMIT_REF_SLUG}
  etapp: testid
  välja arvatud:
    - ajakavad

Kubernetes

Nüüd kataloogis .helm/templates loome YAML koos Job'iga — tests-job.yaml — testide käivitamiseks ja vajalike Kubernetes'i ressurssidega. Täiendavad selgitused on loendi pärast:

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

Millised ressursid on selle konfiguratsiooni all kirjeldatud? Rakenduse juurutamisel loome projekti jaoks ainulaadse nimiruumi (see on näidatud ka .gitlab-ci.yaml — tests-${CI_COMMIT_REF_SLUG}) ja siia paigaldame:

ConfigMap testi skripti;
Töö pod'i kirjelduse ja määratud käsu command, mis käivitab testid;
PV ja PVC, mis võimaldavad testide andmete salvestamist.

Pange tähele sissejuhatav tingimus if maniifesti alguses — vastavalt tuleb teised Helm-chart YAML-failid rakenduse kohta ümbritseda tagurpidi struktuuriga, et neid ei juurutataks testimise ajal. See tähendab:

{{- if ne .Values.global.run_tests "yes" }}
---
teine yaml fail
{{- end }}

Siiski, kui testid nõuavad teatud infrastruktuuri (näiteks Redis, RabbitMQ, Mongo, PostgreSQL…) — nende YAML-id saab ei välja lülitada. Juurutage need testkeskkonnas… muidugi, kohandades vastavalt oma soovidele.

Viimane puudutus

Kuna build ja juurutamine werfi abil toimib seni ainult build-serveris (gitlab-runneriga), ja testa pod käivitatakse meistris, tuleb luua kataloog /mnt/tests meistris ja anda see runnerile, näiteks NFS. Näidis koos selgitustega on saadaval K8s dokumendis.

Tulemuseks saab olema:

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

Keegi ei keela NFS-share tegemist otse gitlab-runner'is, mille järel saab selle pod'idesse monteerida.

Märkus

Võib-olla küsite, miks üldse seda kõike keeruliseks ajada Job'i loomisega, kui saab lihtsalt käivitada skripti testidega otse shell-runner'is? Vastus on piisavalt triviaalne…

Mõned testid nõuavad infrastruktuuri (MongoDB, RabbitMQ, PostgreSQL jne) poole pöördumist nende õige toimimise kontrollimiseks. Me teeme testimise ühtseks — selle lähenemisega on selliste lisade kaasamine lihtne. Lisaks saame tava lähenemise juurutamisel (isegi NFS-i kasutamise ja kataloogide täiendava monteerimisega).

Tulemus

Mida me näeme, kui rakendame ettevalmistatud konfiguratsiooni?

Merge request'is kuvatakse kokkuvõtlik statistika testide kohta, mida käidi läbi tema viimasel pipeline'il:

Iga vea puhul saab siia klõpsata, et saada üksikasju:

NBEttevaatlik lugeja märkab, et testime NodeJS-rakendust, kuid ekraanipiltidel on .NET... Ärge imestage: lihtsalt artikli ettevalmistamise käigus ei leidnud me ühtegi viga esimeses rakenduses, kuid leidisime need teises.

Kokkuvõte

Nagu näha, pole midagi keerulist!

Põhimõtteliselt, kui teil on juba shell-koguja ja see töötab ning Kubernetes pole vajalik — testimise ühendamine sellega on veelgi lihtsam ülesanne kui siin kirjeldatud. Ja GitLab CI dokumentatsioonist leiate näiteid Ruby, Go, Gradle, Maven ja mõnede teiste jaoks.

P.S.

Lugege ka meie blogist:

Allikas: habr.com

JUnit GitLab CI-s koos Kubernetesega