JUnit ក្នុង GitLab CI ជាមួយ Kubernetes

ទោះបីជាការពិតដែលថាមនុស្សគ្រប់គ្នាដឹងយ៉ាងច្បាស់ថាការសាកល្បងកម្មវិធីរបស់អ្នកមានសារៈសំខាន់ និងចាំបាច់ ហើយមនុស្សជាច្រើនបានធ្វើវាដោយស្វ័យប្រវត្តិអស់រយៈពេលជាយូរមកហើយ ប៉ុន្តែនៅក្នុងភាពធំទូលាយនៃ Habr មិនមានរូបមន្តតែមួយសម្រាប់បង្កើតការរួមបញ្ចូលគ្នានៃផលិតផលពេញនិយមបែបនេះនៅក្នុង ទីផ្សារពិសេសនេះជា (សំណព្វរបស់យើង) GitLab និង JUnit ។ តោះបំពេញចន្លោះនេះ!

ការណែនាំ

ជាដំបូងខ្ញុំសូមផ្តល់បរិបទមួយចំនួន៖

• ដោយសារកម្មវិធីទាំងអស់របស់យើងដំណើរការលើ Kubernetes យើងនឹងពិចារណាការសាកល្បងដំណើរការលើហេដ្ឋារចនាសម្ព័ន្ធសមស្រប។
• សម្រាប់ការផ្គុំ និងដាក់ពង្រាយ យើងប្រើ werf (បើ​និយាយ​ពី​ផ្នែក​ហេដ្ឋារចនាសម្ព័ន្ធ វា​ក៏​មាន​ន័យ​ស្វ័យ​ប្រវត្តិ​ដែរ​ថា Helm ត្រូវ​បាន​ចូល​រួម)។
• ខ្ញុំនឹងមិនចូលទៅក្នុងព័ត៌មានលម្អិតនៃការបង្កើតការធ្វើតេស្តជាក់ស្តែងទេ៖ ក្នុងករណីរបស់យើង អតិថិជនសរសេរការធ្វើតេស្តដោយខ្លួនឯង ហើយយើងគ្រាន់តែធានាការបើកដំណើរការរបស់ពួកគេប៉ុណ្ណោះ (និងវត្តមាននៃរបាយការណ៍ដែលត្រូវគ្នានៅក្នុងសំណើបញ្ចូលគ្នា)។

តើលំដាប់ទូទៅនៃសកម្មភាពនឹងមើលទៅដូចអ្វី?

1. ការកសាងកម្មវិធី - យើងនឹងលុបចោលការពិពណ៌នានៃដំណាក់កាលនេះ។
2. ដាក់ពង្រាយកម្មវិធីទៅកន្លែងឈ្មោះដាច់ដោយឡែកនៃចង្កោម Kubernetes ហើយចាប់ផ្តើមសាកល្បង។
3. ការស្វែងរកវត្ថុបុរាណ និងការញែករបាយការណ៍ JUnit ជាមួយ GitLab ។
4. ការលុបឈ្មោះដែលបានបង្កើតពីមុន។

ឥឡូវនេះ - ដើម្បីអនុវត្ត!

ការលៃតម្រូវ

GitLab ស៊ីអាយ

ចូរចាប់ផ្តើមជាមួយនឹងបំណែកមួយ។ .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} 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. ការងារ ជាមួយនឹងការពិពណ៌នាអំពី pod និងការណែនាំដែលបានបញ្ជាក់ commandដែលទើបតែដំណើរការការធ្វើតេស្ត;
3. PV និង PVCដែលអនុញ្ញាតឱ្យអ្នករក្សាទុកទិន្នន័យសាកល្បង។

យកចិត្តទុកដាក់លើលក្ខខណ្ឌណែនាំជាមួយ if នៅដើមដំបូងនៃការបង្ហាញ - យោងទៅតាមឯកសារ YAML ផ្សេងទៀតនៃគំនូសតាង Helm ជាមួយកម្មវិធីត្រូវតែត្រូវបានរុំនៅក្នុង បញ្ច្រាស ការរចនាដើម្បីកុំឱ្យពួកវាត្រូវបានដាក់ពង្រាយកំឡុងពេលធ្វើតេស្ត។ នោះគឺ៖

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

ទោះយ៉ាងណាក៏ដោយប្រសិនបើការធ្វើតេស្ត ទាមទារហេដ្ឋារចនាសម្ព័ន្ធមួយចំនួន (ឧទាហរណ៍ Redis, RabbitMQ, Mongo, PostgreSQL ... ) - YAMLs របស់ពួកគេអាចជា មិនមាន បិទ។ ដាក់ពង្រាយពួកវាទៅក្នុងបរិយាកាសសាកល្បងផងដែរ... ការកែតម្រូវពួកវាតាមដែលអ្នកឃើញថាសម។

ការប៉ះចុងក្រោយ

ដោយសារតែ ការផ្គុំនិងការដាក់ពង្រាយដោយប្រើ werf ដំណើរការសម្រាប់ពេលនេះ តែ នៅលើ build server (ជាមួយ gitlab-runner) ហើយ pod with tests ត្រូវបានដាក់ឱ្យដំណើរការនៅលើ master អ្នកនឹងត្រូវបង្កើត directory /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 ហើយបន្ទាប់មកដំឡើងវានៅក្នុង pods ។

ការកត់សម្គាល់

អ្នកប្រហែលជាកំពុងសួរថាហេតុអ្វីបានជាធ្វើឱ្យអ្វីៗមានភាពស្មុគស្មាញដោយបង្កើត Job ប្រសិនបើអ្នកគ្រាន់តែអាចដំណើរការស្គ្រីបជាមួយនឹងការធ្វើតេស្តដោយផ្ទាល់នៅលើកម្មវិធីរត់សែល? ចម្លើយ​គឺ​ជា​រឿង​តូចតាច...

ការធ្វើតេស្តមួយចំនួនតម្រូវឱ្យមានការចូលទៅកាន់ហេដ្ឋារចនាសម្ព័ន្ធ (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