JUnit ב- GitLab CI עם Kubernetes

למרות העובדה שכולם יודעים היטב שבדיקת התוכנה שלך היא חשובה והכרחית, ורבים עושים זאת אוטומטית כבר זמן רב, במרחב העצום של הבר לא היה מתכון אחד להקמת שילוב של מוצרים פופולריים כל כך ב הנישה הזו כמו (האהובה עלינו) GitLab ו-JUnit. בואו נמלא את החסר הזה!

אֲקָדֵמַאִי

ראשית, הרשה לי לתת קצת הקשר:

• מכיוון שכל האפליקציות שלנו פועלות על Kubernetes, נשקול להפעיל בדיקות על התשתית המתאימה.
• להרכבה ופריסה אנו משתמשים werf (מבחינת רכיבי תשתית, זה גם אומר אוטומטית שהלם מעורב).
• לא אכנס לפרטי יצירת הבדיקות בפועל: במקרה שלנו הלקוח כותב את הבדיקות בעצמו, ואנו רק מבטיחים את השקתן (ונוכחות דיווח מקביל בבקשת המיזוג).

איך ייראה רצף הפעולות הכללי?

1. בניית האפליקציה – נשמיט את תיאור השלב הזה.
2. פרוס את היישום למרחב שמות נפרד של אשכול Kubernetes והתחל בבדיקה.
3. חיפוש חפצים וניתוח דוחות JUnit עם GitLab.
4. מחיקת מרחב שמות שנוצר בעבר.

עכשיו - ליישום!

התאמה

GitLab CI

נתחיל עם קטע .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

קוברנט

עכשיו בספרייה .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 }}

איזה סוג של משאבים המתואר בתצורה זו? בעת הפריסה, אנו יוצרים מרחב שמות ייחודי עבור הפרויקט (זה מצוין ב .gitlab-ci.yaml - tests-${CI_COMMIT_REF_SLUG}) וגלגל אותו החוצה:

1. ConfigMap עם תסריט בדיקה;
2. עבודה עם תיאור של התרמיל וההנחיה שצוינה command, שרק מריץ את הבדיקות;
3. PV ו-PVC, המאפשרים לך לאחסן נתוני בדיקה.

שימו לב לתנאי המבוא עם if בתחילת המניפסט - בהתאם, יש לעטוף קבצי YAML אחרים של תרשים Helm עם האפליקציה обратную לתכנן כך שהם לא ייפרסו במהלך הבדיקה. זה:

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

עם זאת, אם הבדיקות דורשים תשתית כלשהי (לדוגמה, Redis, RabbitMQ, Mongo, PostgreSQL...) - ה-YAML שלהם יכולים להיות לא לכבות. פרוס אותם גם בסביבת מבחן... התאמת אותם כראות עיניך, כמובן.

המגע הסופי

כי הרכבה ופריסה באמצעות werf עדיין עובדת רק בשרת ה-build (עם 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, ולאחר מכן להרכיב אותו ב-pods.

שים לב

אתה אולי שואל למה לסבך הכל על ידי יצירת ג'וב אם אתה יכול פשוט להריץ סקריפט עם בדיקות ישירות על רץ המעטפת? התשובה די טריוויאלית...

חלק מהבדיקות דורשות גישה לתשתית (MongoDB, RabbitMQ, PostgreSQL וכו') כדי לוודא שהן פועלות כהלכה. אנו הופכים את הבדיקות למאוחדות - עם גישה זו, קל לכלול ישויות נוספות כאלה. בנוסף לזה, אנחנו מקבלים סטנדרטי גישת פריסה (גם אם משתמשים ב-NFS, הרכבה נוספת של ספריות).

תוצאה

מה נראה כשנחיל את התצורה המוכנה?

בקשת המיזוג תציג נתונים סטטיסטיים מסכם עבור בדיקות המופעלות בצינור האחרון שלה:

כל שגיאה ניתן ללחוץ כאן לפרטים:

NB: הקורא הקשוב ישים לב שאנו בודקים אפליקציית NodeJS, ובצילומי המסך - .NET... אל תתפלאו: רק שבזמן הכנת המאמר לא נמצאו שגיאות בבדיקת האפליקציה הראשונה, אבל הן נמצאו באחר.

מסקנה

כפי שאתה יכול לראות, שום דבר לא מסובך!

באופן עקרוני, אם כבר יש לך אספן קליפות והוא עובד, אבל אתה לא צריך Kubernetes, צירוף בדיקות אליו תהיה משימה פשוטה אפילו יותר ממה שמתואר כאן. ובתוך תיעוד GitLab CI תמצאו דוגמאות עבור Ruby, Go, Gradle, Maven ועוד כמה.

נ.ב.

קרא גם בבלוג שלנו:

• «שיטות העבודה המומלצות ל-CI/CD עם Kubernetes ו-GitLab (סקירה ודוח וידאו)";
• «טיפים ליצירת זרימות עבודה מותאמות אישית ב- GitLab CI";
• «GitLab CI לשילוב ואספקה ​​מתמשכים בייצור".

מקור: www.habr.com