Если в качестве инфраструктуры, где разворачивается приложение, выступает 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. В этом образе требуются следующие элементы:
- исходный код приложения;
- необходимые пакеты/файлы для запуска Sonar-тестов;
- информация о токене, 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 можно найти в документации. Здесь мы рассмотрим только основные инструкции. Итак, установка необходимых компонентов в образ состоит из следующих операций:
- Добавление исходного кода приложения в образ с помощью Git-модуля werf.
- Инсталляция через NPM пакетов
sonarиsonarqube-scanner. Эти пакеты требуются для поддержки SonarQube в Node.js-приложении. - Установка JDK, который потребуется для запуска тестов.
- Загрузка .jar-файла
sonar-scanner, для которого мы и устанавливаем JDK. - Добавление конфигурационного файла
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). Подробнее об определяемых переменных:
-
SONAR_TOKEN— токен, который вы создаете в самом SonarQube; именно через него производится авторизация в SonarQube; -
SONAR_PROJECT— название созданного проекта в SonarQube; 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, мы подготовили увлекательный онлайн-самоучитель по этой утилите — попробуйте!
Читайте также в нашем блоге:
