JUnit ໃນ GitLab CI ກັບ Kubernetes

ເຖິງວ່າຈະມີຄວາມຈິງທີ່ວ່າທຸກຄົນຮູ້ຢ່າງສົມບູນວ່າການທົດສອບຊອບແວຂອງທ່ານແມ່ນສໍາຄັນແລະຈໍາເປັນ, ແລະຫຼາຍຄົນໄດ້ເຮັດມັນອັດຕະໂນມັດເປັນເວລາດົນນານ, ໃນຄວາມກວ້າງໃຫຍ່ຂອງ Habr ບໍ່ມີສູດດຽວສໍາລັບການສ້າງຕັ້ງປະສົມປະສານຂອງຜະລິດຕະພັນທີ່ນິຍົມດັ່ງກ່າວໃນ. niche ນີ້ເປັນ ( favorite ຂອງພວກເຮົາ) GitLab ແລະ JUnit . ໃຫ້ຕື່ມຊ່ອງຫວ່າງນີ້!

ແນະນໍາ

ທໍາອິດ, ໃຫ້ຂ້າພະເຈົ້າໃຫ້ບາງສະພາບການ:

• ເນື່ອງຈາກທຸກແອັບພລິເຄຊັນຂອງພວກເຮົາແລ່ນຢູ່ໃນ Kubernetes, ພວກເຮົາຈະພິຈາລະນາການທົດສອບແລ່ນໃນໂຄງສ້າງພື້ນຖານທີ່ເຫມາະສົມ.
• ສໍາລັບການປະກອບແລະການນໍາໃຊ້ພວກເຮົາໃຊ້ werf (ໃນແງ່ຂອງອົງປະກອບພື້ນຖານໂຄງລ່າງ, ນີ້ຍັງຫມາຍຄວາມວ່າ Helm ມີສ່ວນຮ່ວມໂດຍອັດຕະໂນມັດ).
• ຂ້າພະເຈົ້າຈະບໍ່ເຂົ້າໄປໃນລາຍລະອຽດຂອງການສ້າງຕົວຈິງຂອງການທົດສອບ: ໃນກໍລະນີຂອງພວກເຮົາ, ລູກຄ້າຂຽນການທົດສອບດ້ວຍຕົນເອງ, ແລະພວກເຮົາພຽງແຕ່ຮັບປະກັນການເປີດຕົວຂອງພວກເຂົາ (ແລະການປະກົດຕົວຂອງບົດລາຍງານທີ່ສອດຄ້ອງກັນໃນຄໍາຮ້ອງຂໍລວມ).

ລໍາດັບທົ່ວໄປຂອງການກະທໍາຈະມີລັກສະນະແນວໃດ?

1. ການກໍ່ສ້າງຄໍາຮ້ອງສະຫມັກ - ພວກເຮົາຈະຍົກເວັ້ນຄໍາອະທິບາຍຂອງຂັ້ນຕອນນີ້.
2. ນຳໃຊ້ແອັບພລິເຄຊັນໄປສູ່ namespace ແຍກຕ່າງຫາກຂອງກຸ່ມ Kubernetes ແລະເລີ່ມການທົດສອບ.
3. ຄົ້ນຫາສິ່ງປອມ ແລະວິເຄາະລາຍງານ JUnit ດ້ວຍ GitLab.
4. ການລຶບ namespace ທີ່ສ້າງຂຶ້ນກ່ອນໜ້ານີ້.

ໃນປັດຈຸບັນ - ເພື່ອປະຕິບັດ!

ການປັບ

GitLab CI

ໃຫ້ເລີ່ມຕົ້ນດ້ວຍຊິ້ນສ່ວນ .gitlab-ci.yaml, ເຊິ່ງອະທິບາຍການນໍາໃຊ້ຄໍາຮ້ອງສະຫມັກແລະການທົດສອບແລ່ນ. ບັນຊີລາຍຊື່ໄດ້ຫັນອອກເປັນ voluminous, ສະນັ້ນມັນໄດ້ຖືກປະກອບຢ່າງລະອຽດກັບຄໍາເຫັນ:

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 ດ້ວຍວຽກ - 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 }}

ຊັບພະຍາກອນປະເພດໃດ ອະທິບາຍໃນການຕັ້ງຄ່ານີ້ບໍ? ໃນ​ເວ​ລາ​ທີ່​ການ​ນໍາ​ໃຊ້​, ພວກ​ເຮົາ​ສ້າງ namespace ເປັນ​ເອ​ກະ​ລັກ​ສໍາ​ລັບ​ໂຄງ​ການ (ອັນ​ນີ້​ແມ່ນ​ລະ​ບຸ​ໄວ້​ໃນ​ .gitlab-ci.yaml - tests-${CI_COMMIT_REF_SLUG}) ແລະ​ມ້ວນ​ມັນ​ອອກ​:

1. ConfigMap ກັບ script ການທົດສອບ;
2. ວຽກເຮັດງານທໍາ ມີຄໍາອະທິບາຍຂອງຝັກແລະຄໍາແນະນໍາທີ່ກໍານົດໄວ້ command, ເຊິ່ງພຽງແຕ່ແລ່ນການທົດສອບ;
3. PV ແລະ PVC, ເຊິ່ງອະນຸຍາດໃຫ້ທ່ານສາມາດເກັບຮັກສາຂໍ້ມູນການທົດສອບ.

ເອົາໃຈໃສ່ກັບເງື່ອນໄຂການແນະນໍາກັບ if ໃນຕອນເລີ່ມຕົ້ນຂອງ manifest - ຕາມຄວາມເຫມາະສົມ, ໄຟລ໌ YAML ອື່ນໆຂອງຕາຕະລາງ Helm ກັບຄໍາຮ້ອງສະຫມັກຕ້ອງໄດ້ຮັບການຫໍ່ຢູ່ໃນ. ດ້ານຫລັງ ການອອກແບບເພື່ອບໍ່ໃຫ້ພວກມັນຖືກນຳໃຊ້ໃນລະຫວ່າງການທົດສອບ. ນັ້ນ​ແມ່ນ:

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

ຢ່າງໃດກໍຕາມ, ຖ້າຫາກວ່າການທົດສອບ ຕ້ອງການໂຄງສ້າງພື້ນຖານບາງຢ່າງ (ຕົວຢ່າງ, Redis, RabbitMQ, Mongo, PostgreSQL...) - YAMLs ຂອງເຂົາເຈົ້າສາມາດເປັນ. ບໍ່ ປິດ. ນຳໃຊ້ພວກມັນເຂົ້າໃນສະພາບແວດລ້ອມການທົດສອບເຊັ່ນດຽວກັນ... ການປັບພວກມັນຕາມທີ່ເຈົ້າເຫັນວ່າເໝາະສົມ, ແນ່ນອນ.

ການສໍາພັດສຸດທ້າຍ

ເນື່ອງຈາກວ່າ ການປະກອບແລະການນໍາໃຊ້ werf ເຮັດວຽກສໍາລັບໃນປັດຈຸບັນ ພຽງແຕ່ ໃນເຊີບເວີສ້າງ (ກັບ gitlab-runner), ແລະຝັກທີ່ມີການທົດສອບຖືກເປີດຕົວໃນແມ່ບົດ, ທ່ານຈະຕ້ອງສ້າງໄດເລກະທໍລີ. /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, ແລະຫຼັງຈາກນັ້ນຕິດຕັ້ງມັນຢູ່ໃນຝັກ.

Примечание

ເຈົ້າອາດຈະຖາມວ່າເປັນຫຍັງທຸກຢ່າງສັບສົນໂດຍການສ້າງ Job ຖ້າເຈົ້າສາມາດແລ່ນສະຄຣິບດ້ວຍການທົດສອບໂດຍກົງໃສ່ shell runner? ຄໍາຕອບແມ່ນຂ້ອນຂ້າງເລັກນ້ອຍ ...

ການທົດສອບບາງຢ່າງຕ້ອງການການເຂົ້າເຖິງໂຄງສ້າງພື້ນຖານ (MongoDB, RabbitMQ, PostgreSQL, ແລະອື່ນໆ) ເພື່ອກວດສອບວ່າພວກມັນເຮັດວຽກຢ່າງຖືກຕ້ອງ. ພວກເຮົາເຮັດໃຫ້ການທົດສອບເປັນເອກະພາບ - ດ້ວຍວິທີການນີ້, ມັນຈະກາຍເປັນເລື່ອງງ່າຍທີ່ຈະລວມເອົາຫນ່ວຍງານເພີ່ມເຕີມດັ່ງກ່າວ. ນອກເຫນືອໄປຈາກນີ້, ພວກເຮົາໄດ້ຮັບ ມາດຕະຖານ ວິທີການນໍາໃຊ້ (ເຖິງແມ່ນວ່າຈະໃຊ້ NFS, ການຕິດຕັ້ງໄດເລກະທໍລີເພີ່ມເຕີມ).

ຜົນ

ພວກເຮົາຈະເຫັນຫຍັງເມື່ອພວກເຮົານໍາໃຊ້ການຕັ້ງຄ່າທີ່ກຽມໄວ້?

ການຮ້ອງຂໍການລວມກັນຈະສະແດງສະຖິຕິສະຫຼຸບສໍາລັບການທົດສອບທີ່ດໍາເນີນຢູ່ໃນທໍ່ຫລ້າສຸດຂອງມັນ:

ແຕ່ລະຂໍ້ຜິດພາດສາມາດຄລິກທີ່ນີ້ສໍາລັບລາຍລະອຽດ:

NB: ຜູ້ອ່ານທີ່ເອົາໃຈໃສ່ຈະສັງເກດເຫັນວ່າພວກເຮົາກໍາລັງທົດສອບຄໍາຮ້ອງສະຫມັກ NodeJS, ແລະໃນ screenshots - .NET ... ບໍ່ຕ້ອງແປກໃຈ: ມັນເປັນພຽງແຕ່ວ່າໃນຂະນະທີ່ກະກຽມບົດຄວາມ, ບໍ່ພົບຂໍ້ຜິດພາດໃນການທົດສອບຄໍາຮ້ອງສະຫມັກຄັ້ງທໍາອິດ, ແຕ່ພວກເຂົາ ໄດ້ຖືກພົບເຫັນຢູ່ໃນບ່ອນອື່ນ.

ສະຫລຸບ

ດັ່ງທີ່ເຈົ້າເຫັນ, ບໍ່ມີຫຍັງສັບສົນ!

ໃນຫຼັກການ, ຖ້າທ່ານມີຕົວເກັບແກະແລ້ວແລະມັນເຮັດວຽກ, ແຕ່ທ່ານບໍ່ຕ້ອງການ Kubernetes, ການທົດສອບການຕິດຢູ່ກັບມັນຈະເປັນວຽກງານທີ່ງ່າຍດາຍກວ່າທີ່ໄດ້ອະທິບາຍຢູ່ທີ່ນີ້. ແລະໃນ ເອກະສານ GitLab CI ເຈົ້າຈະພົບເຫັນຕົວຢ່າງສໍາລັບ Ruby, Go, Gradle, Maven ແລະອື່ນໆຈໍານວນຫນຶ່ງ.

PS

ອ່ານຍັງຢູ່ໃນ blog ຂອງພວກເຮົາ:

• «ການປະຕິບັດ CI/CD ທີ່ດີທີ່ສຸດກັບ Kubernetes ແລະ GitLab (ການທົບທວນຄືນແລະບົດລາຍງານວິດີໂອ)"
• «ຄໍາແນະນໍາສໍາລັບການສ້າງຂະບວນການເຮັດວຽກທີ່ກໍາຫນົດເອງໃນ GitLab CI"
• «GitLab CI ສໍາລັບການເຊື່ອມໂຍງຢ່າງຕໍ່ເນື່ອງແລະການຈັດສົ່ງໃນການຜະລິດ".

ແຫຼ່ງຂໍ້ມູນ: www.habr.com