Запускаем тесты на 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-tests from: 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-tests from: node:10.16.0 git:   - add: /     to: /app ansible:   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, мы подготовили увлекательный онлайн-самоучитель по этой утилите — попробуйте!

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

• «Из жизни с Kubernetes: Как мы выносили СУБД (и не только) из review-окружений в статическое»;
• «Организация распределенного CI/CD с помощью werf»;
• «Динамическая сборка и деплой Docker-образов с werf на примере сайта версионированной документации».