company_banner

Запускаем тесты на 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, мы подготовили увлекательный онлайн-самоучитель по этой утилите — попробуйте!

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

    Флант
    DevOps-as-a-Service, Kubernetes, обслуживание 24×7

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

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

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