🥇JUnit GitLab CI-s Kubernetesiga

Kuigi kõik teavad, et oma tarkvara testimine on oluline ja vajalik, ning paljud teevad seda automaatselt, ei leidunud Habras ühtegi retsepti, kuidas seadistada selliste populaarsete toodete nagu (meie lemmik) GitLab ja JUnit kombinatsiooni. Täidame selle tühiku!

Sissejuhatus

Alustuseks määratlen konteksti:

Kuna kõik meie rakendused töötavad Kuberneteses, käsitleme testide käivitamist vastavas infrastruktuuris.
Kogumise ja juurutamise jaoks kasutame werf (infrastruktuuri komponente arvestades tähendab see automaatselt, et on kaasatud ka Helm).
Ei süvene testide loomise üksikasjadesse: meie puhul kirjutab klient testid ise ja me tagame vaid nende käivitamise (ja vastava aruande olemasolu merge request'is).

Milline näeb välja üldine tegevuste järjekord?

Rakenduse kogumine — selle etapi kirjeldust jätame välja.
Rakenduse juurutamine Kubernetes klastris eraldi namespace'i ja testimise käivitamine.
Artefaktide otsimine ja JUnit aruande parsimine GitLabis.
Varasemalt loodud namespace'i kustutamine.

Nüüd — elluviimise juurde!

Seadistamine

GitLab CI-d

Alustame fragmentist .gitlab-ci.yaml, mis kirjeldab rakenduse juurutamist ja testide käivitamist. Loetelu osutus üsna mahukaks ning on seetõttu põhjalikult täiendatud kommentaaridega:

muutujad:
# deklareerime werf versiooni, mida kavatseme kasutada
  WERF_VERSION: "1.0 beta"

.base_deploy: &base_deploy
  skript:
# loome namespace K8s, kui seda ei ole
    - kubectl --context="${WERF_KUBE_CONTEXT}" get ns ${CI_ENVIRONMENT_SLUG} || kubectl create ns ${CI_ENVIRONMENT_SLUG}
# laadime werfi ja deploime — rohkem selle kohta leiate dokumentatsioonist
# (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 muutujat `run_tests`
# seda kasutatakse Helm-release'i renderdamisel
      --set "global.run_tests=${RUN_TESTS:-no}"
      --set "global.env=${CI_ENVIRONMENT_SLUG}"
# muudame timeout'i (mõnikord on testid pikad) ja edastame selle release'ile
      --set "global.ci_timeout=${CI_TIMEOUT:-900}"
     --timeout ${CI_TIMEOUT:-900}
  sõltuvused:
    - Build

.test-base: &test-base
  laiendab: .base_deploy
  before_script:
# loome kausta tulevase raporti jaoks, lähtudes $CI_COMMIT_REF_SLUG'ist
    - mkdir /mnt/tests/${CI_COMMIT_REF_SLUG} || true
# sunnitud lahendus, kuna GitLab tahab saada artefakte oma build-dir’ist
    - mkdir ./tests || true
    - ln -s /mnt/tests/${CI_COMMIT_REF_SLUG} ./tests/${CI_COMMIT_REF_SLUG}
  after_script:
# pärast testide lõppu eemaldame release koos Job'iga
# (ja võimalikult 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 tõrkeid, kuid saate teha teisiti
  allow_failure: true
  muutujad:
    RUN_TESTS: 'yes'
# seadistame konteksti werf'is
# (https://werf.io/how_to/gitlab_ci_cd_integration.html#infrastructure)
    WERF_KUBE_CONTEXT: 'admin@stage-cluster'
  sildid:
# kasutame runnerit sildiga `werf-runner`
    - werf-runner
  artefaktid:
# vajalik on koguda artefakt, et seda võiks näha
# pipeline'is ja alla laadida — näiteks põhjalikumaks uurimiseks
    paths:
      - ./tests/${CI_COMMIT_REF_SLUG}/*
# artefaktid, mis on vanemad kui nädal, kustutatakse
    expire_in: 7 day
# oluline: need read vastutavad GitLabi raporti töötlemise eest
    reports:
      junit: ./tests/${CI_COMMIT_REF_SLUG}/report.xml

# lihtsustamiseks on siin näidatud vaid kaks etappi
# tegelikult on teil neid rohkem — vähemalt deploimise tõttu
etapid:
  - build
  - tests

build:
  etapp: build
  skript:
# ehitamine — uuesti vastavalt werfi dokumentatsioonile
# (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:
    - schedules

käivita testid:
  <<: *test-base
  keskkond:
# "endiselt sool" namespace'i nimetamisel
# (https://docs.gitlab.com/ce/ci/variables/predefined_variables.html)
    name: tests-${CI_COMMIT_REF_SLUG}
  etapp: tests
  välja arvatud:
    - schedules

Kubernetes

Nüüd kaustas .helm/templates loome YAML Job'iga — tests-job.yaml — testide käivitamiseks ja vajalikeks Kubernetes'i ressurssideks. Selgitused on loetletud järgnevalt:

{{- 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 }}

Milliseid ressursse on selles konfiguratsioonis kirjeldatud? Deployimisel loome projekti jaoks ainulaadse nimi ({see on juba loetletud .gitlab-ci.yaml — tests-${CI_COMMIT_REF_SLUG}) ja viime selle sisse:

ConfigMap testiskripti;
Töö pod'i kirjeldust ja määratud direktiivi käsk, mis käivitab testid;
PV ja PVC, mis võimaldavad testide andmete salvestamist.

Pange tähele tingimuslauset if manifesti alguses — vastavalt sellele peavad teised Helm chart'i YAML-failid olema mähitud vastandlikku struktuuri, et need ei deployitaks testimise ajal. See tähendab:

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

Siiski, kui testid nõuavad mingit infrastruktuuri (nt Redis, RabbitMQ, Mongo, PostgreSQL…) — nende YAML-id võivad ei välja lülitama. Laadige ja neid testimiskeskkonnas… muidugi kohandage vastavalt oma soovidele.

Lõppviimistlus

Kuna kogumine ja juurutamine werf'i abil töötab praegu seda build-serveris (gitlab-runner'i kaudu), samas kui pod testide jaoks käivitatakse masteris, tuleb luua kataloog /mnt/tests masteris ja anda see runner'ile, näiteks NFS kaudu. Lahtise näitena koos selgitustega leiate K8s dokumentatsioonist.

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 teha NFS-shaari otse gitlab-runneris ja seejärel mountida see pod'idena.

Märkus

Võib-olla küsite, miks üldse keeruliseks teha Job'i loomisega, kui saab lihtsalt käivitada skripti testide jaoks otse shell-runneris? Vastus on piisavalt triviaalne…

Mõned testid vajavad infrastruktuuri (MongoDB, RabbitMQ, PostgreSQL jne) poole pöördumist, et kontrollida nendega töötamise õiguspärasust. Teeme testimise ühtseks — sellise lähenemisega on sarnaste lisasüsteemide kaasamine lihtne. Lisaks saame tavaline juurde lähenemise juurutamisel (isegi kui kasutatakse NFS'i ning lisakatkeste monteerimist).

Tulemus

Mida me näeme, kui rakendame ettevalmistatud konfiguratsiooni?

Merge request'is kuvatakse kokkuvõtlik statistika testide kohta, mis käivitati selle viimases torustikus:

Iga vea peal saab klikida, et saada rohkem detaile:

NB: Hoolikas lugeja märkab, et testime NodeJS rakendust, samal ajal kui ekraanipiltidel on .NET... Ära üllatu, et lihtsalt artikli ettevalmistamisel ei olnud esimeses rakenduses vigu, kuid leidsime need teisest.

Kokkuvõte

Nagu näha, pole midagi keerulist!

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

P.S.

Lugege ka meie blogist:

Allikas: habr.com

JUnit GitLab CI-s koos Kubernetesega