Русский
Русский
English
Статистика
Реклама

Запускаем тесты на GitLab Runner с werf на примере SonarQube



Если в качестве инфраструктуры, где разворачивается приложение, выступает Kubernetes, можно сказать, что существует два способа запуска тестов (и других утилит для анализа кода) в CI/CD:

  • непосредственно в кластере K8s с помощью отдельных Job или Helm hooks;
  • снаружи K8s например, на сервере сборки/деплоя или локально у разработчиков.

Первый подход мы достаточно подробно описывали на интересном примере с базами данных в статье Как мы выносили СУБД (и не только) из review-окружений в статическое. В этой статье рассмотрен более простой путь запуск вне K8s-кластера. Делать мы это будем на примере SonarQube-тестов в рамках CI/CD, построенного на базе GitLab с использованием werf.

Стоит помнить, что такой метод подходит только для тех тестов, которые не требуют подключения к другим объектам в инфраструктуре. С другой стороны, этот вариант хорош тем, что позволяет экономить кластерные ресурсы: нам не нужно выделять дополнительные ресурсы в K8s, поскольку вместо этого используются внешние мощности (локальных машин или сервера сборки/деплоя).

Для запуска тестов будет использоваться CI/CD-утилита werf, которая позволяет работать с полным жизненным циклом доставки приложений, а в частности удобно собирать Docker-образы, а потом запускать их локально. Если вы уже используете werf, встраивание дополнительных команд будет совсем тривиальным, а если нет на данном примере можно увидеть, как удобно контролировать все процессы CI/CD в одном месте.

Теперь к непосредственной практике.

Подготовка: внедряем тесты в пайплайн приложения


Основная особенность использования тестов и других анализаторов кода в CI/CD необходимость устанавливать дополнительные пакеты/конфигурационные файлы в Docker-образ приложения. Установка все в один образ увеличивает размер итогового образа и добавляет неиспользуемые файлы во время запуска самого приложения.

В качестве альтернативного варианта* можно использовать отдельную сборку Docker-образа со всеми необходимыми зависимостями для тестов. Такая сборка будет выполняться параллельно сборке основного образа и использоваться только там, где требуется.

* Известная многим лучшая практика гласит, что для всех целей применения (от тестов и отладки до запуска в production) должен собираться единственный образ. Поэтому вариант со сборкой другого образа может быть допустим разве что для случаев, когда требуется тестировать только исходный код приложения. В таком варианте можно основной образ приложения использовать в виде артефакта в образе для тестов.

Также обращаю внимание, что хотя последующие примеры основаны на использовании тестов с SonarQube, это не мешает выполнять аналогичные действия и с другими инструментами.

В werf реализация задуманного осуществляется с помощью переменных окружения, устанавливаемых в определенной Job в CI/CD-пайплайне.

Для конфигурации на стороне GitLab CI/CD потребуется определить Job с тестами (в .gitlab-ci.yml) примерно так:

Build sonar-tests:  stage: build  script:    - werf build-and-publish  variables:    SONAR_TESTS: "yes"  tags:    - werf  only:    - schedules

Как видно, в variables определяется переменная SONAR_TESTS, которая и будет задействована в сборке через werf.

Не будем подробно останавливаться на том, как в целом реализуется сборка с помощью werf: эту информацию можно найти в документации утилиты, а полный конфиг для нашего случая будет приведен ниже.

В рамках подготовительных работ важно заметить, что в конфигурации сборки (werf.yaml) появится следующий блок:

{{ if eq (env "SONAR_TESTS") "yes" }}---image: sonar-testsfrom: node:10.16.0# остальные этапы сборки# ...{{ end }}

Т.е. теперь мы можем обратиться к той переменной SONAR_TESTS, что задали в GitLab CI/CD. Так легко контролировать этапы сборки с помощью переменных.

Собираем образы тестов в werf


Перейдем к непосредственному созданию инструкций для сборки Docker-образа с помощью werf. В этом образе требуются следующие элементы:

  1. исходный код приложения;
  2. необходимые пакеты/файлы для запуска Sonar-тестов;
  3. информация о токене, URL до Sonarqube dashboard и названии приложения в конфигурационном файле.

Получается следующий набор инструкций для werf:

{{ $sonar_version := "4.4.0.2170"}}{{ if eq (env "SONAR_TESTS") "yes" }}---image: sonar-testsfrom: node:10.16.0git:  - add: /    to: /appansible:  install:  - name: "npm install sonar"    shell: |      npm install --no-save -D sonarqube-scanner    args:      chdir: /app  - name: "Install default-jdk"    apt:      update_cache: yes      state: present      name:      - default-jdk  - name: "install sonarqube scanner"    args:      chdir: /app    shell: |      wget https://binaries.sonarsource.com/Distribution/sonar-scanner-cli/sonar-scanner-cli-{{ $sonar_version }}.zip      mkdir -p /root/.sonar/native-sonar-scanner/      unzip -qq sonar-scanner-cli-{{ $sonar_version }}.zip -d /root/.sonar/native-sonar-scanner/      mv /root/.sonar/native-sonar-scanner/sonar-scanner-{{ $sonar_version }}/ /root/.sonar/native-sonar-scanner/sonar-scanner-{{ $sonar_version }}-linux/  - name: "Setup /app/sonar.js"    copy:      content: |{{ tpl (.Files.Get ".werf/sonar.js") . | indent 8 }}      dest: /app/sonar.js{{ end }}{{ end }}

Опять же, полную информацию по структуре и содержанию werf.yaml можно найти в документации. Здесь мы рассмотрим только основные инструкции. Итак, установка необходимых компонентов в образ состоит из следующих операций:

  1. Добавление исходного кода приложения в образ с помощью Git-модуля werf.
  2. Инсталляция через NPM пакетов sonar и sonarqube-scanner. Эти пакеты требуются для поддержки SonarQube в Node.js-приложении.
  3. Установка JDK, который потребуется для запуска тестов.
  4. Загрузка .jar-файла sonar-scanner, для которого мы и устанавливаем JDK.
  5. Добавление конфигурационного файла sonar.js с помощью функции .Files.Get. Подробнее см. далее.

Что за файл, находящийся по адресу .werf/sonar.js? Это конфиг, в котором хранится вся необходимая информация для запуска Sonar-тестов. Посмотрим на его содержимое:

{{ $_ := env "SONAR_TOKEN" | set . "Token" }}{{ $_ := env "SONAR_PROJECT" | set . "Project" }}{{ $_ := env "SONAR_URL" | set . "Url" }}    const sonarqubeScanner = require('sonarqube-scanner');    sonarqubeScanner( {      serverUrl : "{{ .Url }}",       token : "{{ .Token }}",      options: {        'sonar.projectName': "{{ .Project }}",        'sonar.projectDescription': 'Description for "{{ .Project }}" project...',        'sonar.sources': '.',        'sonar.projectKey': "{{ .Project }}",        'sonar.projectBaseDir': '/app'      }      },      () => process.exit()    )

В трёх первых строчках перечисляются переменные окружения, которые определяются, например, в GitLab CI/CD Variables. В дальнейшем, т.е. во время сборки/деплоя, эти переменные могут использоваться аналогично тому, как мы уже показывали в werf.yaml (через встроенную конструкцию werf).

Подробнее об определяемых переменных:

  1. SONAR_TOKEN токен, который вы создаете в самом SonarQube; именно через него производится авторизация в SonarQube;
  2. SONAR_PROJECT название созданного проекта в SonarQube;
  3. SONAR_URL URL к SonarQube (может быть как внешним URL, так и адресом до сервиса).

В результате сборки (werf build) по таким конфигам (werf.yaml
и sonar.js) получается Docker-образ (под названием sonar-tests), который можно использовать для запуска Sonar-тестов, чем мы и займемся в следующей главе.

NB: Аналогичным образом можно собирать и запускать linting-тесты (речь не про что-то компилируемое), интеграционные тесты и т.д., причем даже в Kubernetes-окружении, а не только локально (в любом случае как минимум экономится место в основном образе).

Запускаем тесты с помощью команды werf run


Последний этап запуск тестов локально на GitLab Runner.

Для этого в GitLab CI/CD определяется отдельная Job, в которой будут запускаться тесты. Например:

Deploy sonar-tests:  script:    - werf run sonar-tests -- bash -c "node /app/sonar.js"  tags:    - werf  stage: deploy  environment:    name: sonar-tests  only:    - schedules  variables:    SONAR_TESTS: "yes"  after_script:    - echo "Scan results are here https://sonar/dashboard?id=${SONAR_PROJECT}"  when: always  dependencies:    - Build sonar-tests

Здесь используется единственная команда:

werf run sonar-tests -- bash -c "node /app/sonar.js"

В её первой части указывается название образа для запуска (sonar-tests, берётся из werf.yaml), во второй команда для выполнения внутри контейнера.

Теперь пайплайн будет запускать Sonar-тесты на GitLab Runner, а их результаты публиковать в SonarQube Dashboard.



Заключение


Описанный вариант запуска тестов в первую очередь будет полезен тем, кто уже использует werf или собирается его внедрить в своем проекте. С werf run можно выполнять тесты непосредственно на самом Runner'е и вместо отдельных Docker-инструкций описывать всё непосредственно в werf, аккумулируя подобные элементы в одном месте.

Этот подход, конечно, позволяет запускать не только SonarQube-тесты: подойдут и любые другие решения, не требующие создания отдельного окружения для них (в виде отдельного сервера БД, очередей сообщений и т.д.).

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

P.S.


Кстати, для разработчиков, только начинающих знакомиться с werf, мы подготовили увлекательный онлайн-самоучитель по этой утилите попробуйте!

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

Источник: habr.com
К списку статей
Опубликовано: 09.11.2020 10:07:58
0

Сейчас читают

Комментариев (0)
Имя
Электронная почта

Блог компании флант

Тестирование веб-сервисов

Devops

Continuous delivery

Werf

Gitlab

Gitlab ci

Sonarqube

Категории

Последние комментарии

  • Имя: Макс
    24.08.2022 | 11:28
    Я разраб в IT компании, работаю на арбитражную команду. Мы работаем с приламы и сайтами, при работе замечаются постоянные баны и лаги. Пацаны посоветовали сервис по анализу исходного кода,https://app Подробнее..
  • Имя: 9055410337
    20.08.2022 | 17:41
    поможем пишите в телеграм Подробнее..
  • Имя: sabbat
    17.08.2022 | 20:42
    Охренеть.. это просто шикарная статья, феноменально круто. Большое спасибо за разбор! Надеюсь как-нибудь с тобой связаться для обсуждений чего-либо) Подробнее..
  • Имя: Мария
    09.08.2022 | 14:44
    Добрый день. Если обладаете такой информацией, то подскажите, пожалуйста, где можно найти много-много материала по Yggdrasil и его уязвимостях для написания диплома? Благодарю. Подробнее..
© 2006-2024, personeltest.ru