company_banner

JUnit в GitLab CI с Kubernetes

    Несмотря на то, что все прекрасно знают, что тестировать свой софт важно и нужно, а многие давно делают это автоматически, на просторах Хабра не нашлось ни одного рецепта по настройке связки таких популярных в этой нише продуктов, как (любимый нами) GitLab и JUnit. Восполним этот пробел!



    Вводные


    Для начала обозначу контекст:

    • Так как все наши приложения работают в Kubernetes, будет рассмотрен запуск тестов в соответствующей инфраструктуре.
    • Для сборки и деплоя мы используем werf (в смысле инфраструктурных компонентов это также автоматически означает, что задействован Helm).
    • В детали непосредственного создания тестов вдаваться не буду: в нашем случае клиент пишет тесты сам, а мы лишь обеспечиваем их запуск (и наличие соответствующего отчета в merge request'е).

    Как будет выглядеть общая последовательность действий?

    1. Сборка приложения — описание этого этапа мы опустим.
    2. Деплой приложения в отдельный namespace кластера Kubernetes и запуск тестирования.
    3. Поиск артефактов и парсинг JUnit-отчета GitLab’ом.
    4. Удаление созданного ранее namespace’а.

    Теперь — к реализации!

    Настройка


    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

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

    Что за ресурсы описаны в этой конфигурации? При деплое создаем уникальный для проекта namespace (это указано еще в .gitlab-ci.yamltests-${CI_COMMIT_REF_SLUG}) и в него выкатываем:

    1. ConfigMap со скриптом теста;
    2. Job с описанием pod’а и указанной директивой command, которая как раз и запускает тесты;
    3. PV и PVC, что позволяют хранить данные тестов.

    Обратите внимание на вводное условие с if в начале манифеста — соответственно, другие YAML-файлы Helm-чарта с приложением надо обернуть в обратную конструкцию, чтобы они не деплоились при тестировании. То есть:

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

    Впрочем, если тесты требуют некоторую инфраструктуру (например, Redis, RabbitMQ, Mongo, PostgreSQL…) — их YAML’ы можно не выключать. Разверните и их в тестовой среде… конечно же, подправив по своему усмотрению.

    Финальный штрих


    Т.к. сборка и деплой с помощью werf пока что работает только на build-сервере (с gitlab-runner), а pod с тестами запускается на мастере, потребуется создать директорию /mnt/tests на мастере и отдать ее на runner, например, по 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’е, после чего монтировать её в pod’ы.

    Примечание


    Возможно, вы спросите, зачем вообще все усложнять созданием Job'а, если можно просто запустить скрипт с тестами прямо на shell-раннере? Ответ достаточно тривиален…

    Некоторые тесты требуют обращения к инфраструктуре (MongoDB, RabbitMQ, PostgreSQL и т.п.) для проверки корректности работы с ними. Мы делаем тестирование унифицированным — при таком подходе включать подобные дополнительные сущности становится легко. Вдобавок к этому, мы получаем стандартный подход в деплое (пусть даже и с использованием NFS, дополнительным монтированием каталогов).

    Результат


    Что мы увидим, когда применим подготовленную конфигурацию?

    В merge request’е будет показана сводная статистика по тестам, запущенным в его последнем пайплайне:



    На каждую ошибку здесь можно нажать, чтобы получить подробности:



    NB: Внимательный читатель заметит, что мы тестируем NodeJS-приложение, а на скриншотах — .NET… Не удивляйтесь: просто в рамках подготовки статьи не нашлось ошибок в тестировании первого приложения, зато нашли их в другом.

    Заключение


    Как видно, ничего сложного!

    В принципе, если у вас уже есть shell-сборщик и он работает, а Kubernetes вам не нужен — прикрутить к нему тестирование будет еще более простой задачей, чем описанная здесь. А в документации GitLab CI вы найдете примеры для Ruby, Go, Gradle, Maven и некоторых других.

    P.S.


    Читайте также в нашем блоге:

    • +35
    • 4,1k
    • 2
    Флант
    453,52
    Специалисты по DevOps и Kubernetes
    Поделиться публикацией

    Комментарии 2

      0

      Может подскажут господа знатоки, чем можно потестировать REST api не в пределах одного языка и аппликации, а для того чтобы охватить целый спектр сервисов написанных на разных языках. Так получилось что тестов нет совсем, а проблемы есть

        0
        artifacts:
        paths:
        — ./tests/${CI_COMMIT_REF_SLUG}/*
        expire_in: 7 day

        Не лучше ли вынести артефакты в другую систему, а не хранить их в GitLab? За 7 дней там может много лишнего накопиться.

        Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

        Самое читаемое