Как мы автоматизировали тестирование OpenStack с помощью Rally и Tempest

в 12:42, , рубрики: backend, ci/cd, gitlab, octavia, openstack, rally, selectel, tempest, Блог компании Selectel, разработка, Разработка веб-сайтов, тестирование, Тестирование IT-систем, Тестирование веб-сервисов
Как мы автоматизировали тестирование OpenStack с помощью Rally и Tempest - 1

Всем привет, меня зовут Валентина! Уже около пяти лет я работаю в тестировании, из них более трех занимаюсь прожаркой OpenStack с помощью Tempest и Rally. Заметила, что в сети не так много информации об этих фреймворках. Пора это исправить.

В этой статье я расскажу, как мы в Selectel тестировали Octavia с помощью Tempest и Rally, с какими трудностями столкнулись, как преодолевали их и что в итоге получилось. Если интересно, добро пожаловать под кат!

Используйте навигацию, если не хотите читать текст полностью:

Инструменты для тестирования OpenStack
Настройка ручного тестирования
Автоматизация тестирования
Результаты работы и дальнейшие планы

Инструменты для тестирования OpenStack


Для начала давайте вспомним, что такое Tempest и Rally, из чего они состоят и какие у них особенности. Если кратко, то это самая популярная комбинация фреймворков для тестирования OpenStack. Рассмотрим их подробнее.

Фреймворк Tempest — это набор интеграционных тестов и сценариев, предназначенных для запуска на кластере OpenStack и проверки его API. По умолчанию фреймворк позволяет тестировать следующие сервисы:

  • Nova — контроллер вычислительных ресурсов,
  • Keystone — сервис идентификации,
  • Glance — библиотека образов виртуальных машин,
  • Neutron — сервис «подключение к сети как услуга» между интерфейсами устройств, которые управляются другими сервисами OpenStack,
  • Cinder — служба работы с блочными устройствами хранения данных.

Для запуска тестов Tempest используется инструмент Rally, в котором есть специальный компонент проверки — rally verify. Он предоставляет интерфейс для удобной установки и настройки самого Tempest.

Преимущества фреймворков

Tempest имеет достаточно обширный набор уже готовых тестов, который позволяет легко тестировать базовую функциональность OpenStack. С помощью него можно покрыть проект функциональными, интеграционными и нагрузочными тестами.

Tempest и Rally развиваются по настоящее время, и база тестов пополняется с каждым OpenStack-релизом. Кроме того, весь исходный код фреймворков находится в открытом доступе.

Также хочу отдельно отметить установку дополнительных наборов тестов и плагинов, как часть запуска Tempest. Для нас это было особенно полезно, поскольку мы работаем не только с основными сервисами OpenStack, но также с дополнительными вроде Octavia, тесты для которого не входят в базовый набор. В результате мы подключили плагин octavia-tempest-plugin. Но все ли так просто?

Особенности тестирования модифицированного OpenStack

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

Кроме того, процесс настройки и запуска тестов ручной, что требует дополнительного времени при каждом запуске. Поэтому у нас появилась идея автоматизировать процесс — сделать так, чтобы тесты запускались самостоятельно на модифицированном OpenStack, без прямого участия человека.

Здесь возникает один из самых интересных вопросов, который нам предстояло решить: как запустить тесты в продакшене такими образом, чтобы это не повлияло на работу клиентов?

Как мы автоматизировали тестирование OpenStack с помощью Rally и Tempest - 2

Настройка ручного тестирования


Для начала необходимо было понять, какие результаты мы получим, если настроим простое ручное тестирование Tempest для модифицированного OpenStack.

После первого запуска была стопка упавших тестов, с которой мне предстояло разобраться. Было важно понять, с чем связано падение теста: с измененным функционалом или багом на стороне сервиса.

Для ответа на вопрос пришлось перерыть кучу информации, потому что в некоторых случаях тесты зависели от значений параметров в конфигурационном файле Tempest, и нужно было понять, какие значения актуальны для модифицированного OpenStack. А поскольку мы еще установили octavia-tempest-plugin, нужно было также настроить секцию load_balancer.

Одна часть тестов была налажена путем переписывания логики сценариев Tempest, другая — с помощью правильной настройки конфигурационного файла. Так, например, для некоторых тестов нужно было просто указать путь до SSH-ключей, заполнив параметр amphora_ssh_key, для остальных — loadbalancer_topology или RBAC_test_type.

Изоляция тестов

Хорошо — вопрос с ручным запуском решен, тесты исправлены и показывают корректные и актуальные результаты. Следующим логическим шагом была автоматизация. Но чтобы все работало «хорошо и безопасно», нужно было изолировать тесты: запускать их в отдельном домене, не мешая клиентам.

Для изоляции мы создали отдельный домен, предназначенный только для тестирования. Внутри него можно создавать проекты с пользователями отдельно для каждого сервиса. Например, для тестирования сервиса Octavia мы используем проекты с именем tempest_octavia_, для сервиса Neutron — tempest_neutron_, и так далее.

Но как предотвратить создание shared-сети, которая будет видна абсолютно во всех проектах? Мы нашли решение — полиси-фреймворк rbac-policy. Он позволяет пользователям и админам выдавать доступы к ресурсам внутри определенного проекта. Таким образом, мы создали сеть видимой лишь для тестовых проектов и добились изоляции.

Как мы автоматизировали тестирование OpenStack с помощью Rally и Tempest - 3

Создание сети с помощью rbac-policy.

Автоматизация тестирования


Когда мы наладили механизм ручного тестирования и изолировали рабочую среду, можно было приступить к автоматизации.

В качестве CI/CD под пайплайн мы выбрали GitLab — его синтаксис гораздо проще чем в Jenkins, а поддержка CI более проста. Это позволяет сократить время вхождения для инженеров, у которых нет опыта в автоматизации — это как раз моя остановочка!

В качестве конечной цели был выбран автоматический запуск тестов по нажатию кнопки. Внутри пайплайна было сделано разделение по двум критериям — окружение, на котором будут запущены тесты (staging и production), и вид тестов (Rally-сценарии или Tempest-тесты). Таким образом, было необходимо создать 4 джобы:

  • запуск Tempest-тестов в staging окружении,
  • запуск Tempest-тестов в production окружении,
  • запуск Rally-сценариев в staging окружении,
  • запуск Rally-сценариев в production окружении.

Как я уже говорила, мы не используем решение OpenStack из коробки, поэтому изменениям подверглись и сами фреймворки для тестирования. Следовательно, нам нужно было собрать новый Docker-образ, включающий в себя изменения, которые мы добавили в Tempest и Rally. В итоге получилась следующая цепочка:

  1. В репозитории rally-openstack собирается образ с необходимой версией, куда включаются все необходимые изменения.
  2. На основе получившегося образа Rally собирается образ в репозитории Tempest, куда аналогичным образом подгружаются проделанные изменения.
  3. На основе полученного Tempest-образа собирается новый для octavia tempest plugin с тестами, в которых происходит установка всех необходимых зависимостей и самого плагина.

После того, как все образы были подготовлены и протестированы, можно было приступить к написанию пайплайна.

Подготовка и запуск пайплайна

В основе пайплайна находится скрипт c конфигурациями, генерацией отчетов и самим сценарием запуска тестов. Поскольку у нас два вида тестирования — Rally и Tempest, — то и скриптов должно быть два. Их настройка и подготовка окружения идентична, поэтому рассмотрим пример на базе Tempest-тестов.

Для запуска тестов нам понадобятся готовые конфигурационные файлы:

  • YAML-файл с записью информации об окружении, на котором будут запущены тесты.
  • skip-list в формате YAML, содержащий список тестов, которые будут пропущены при запуске, и причины пропуска.
  • Надстройка для конфигурационного файла tempest.conf, в котором содержатся параметры с уже заготовленными значениями.
  • Файл accounts.yaml, содержащий список из пользователей и проектов, которые будут использоваться для запуска тестов.

Все эти файлы хранятся в качестве gitlab variables типа file. Сам же скрипт пайплайна состоит из нескольких этапов.

1. Создание и проверка окружения, на котором будут запущены тесты.

# Creation of environment
rally env create --name octavia --spec "$ENV_OCTAVIA" > /dev/null
# Checking of created environment
rally env check

2. Создание набора тестов и конфигурационного файла.

# Creation of verify
rally --debug verify create-verifier --system-wide --type tempest --name tempest-octavia --source /home/rally/tempest/
# Reconfigure existing verifier
rally --debug verify configure-verifier --show --extend "$TEMPEST_EXTRA_CONF"

3. Запуск тестов.

# Run of Tempest tests for Octavia
rally --debug verify start --concurrency 4 --detailed --pattern octavia_tempest_plugin --skip-list "$SKIP_LIST"

4. Генерация отчета и загрузка в облачное хранилище.

# Make report
rally verify report --type html --to ./octavia_tempest_reports/"$ENVIRONMENT"-"$REGION"-$(date "+%F-%H_%M_%S").html
# Upload reports to the storage
swift upload rally_reports octavia_tempest_reports

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

  1. lint — этап, на котором происходит запуск линтера flake8. Это анализатор кода, который помогает находить распространенные ошибки, делать код единообразным и более читаемым.
  2. unit — этап, на котором происходит запуск unit тестов, которые содержатся внутри octavia tempest plugin.
  3. build image — этап, на котором происходит создание Docker-образа, на основе dockerfile.

Данные этапы являются автоматическими и при добавлении изменений в репозиторий octavia tempest plugin они запускаются.

Как мы автоматизировали тестирование OpenStack с помощью Rally и Tempest - 4

Супер — все готово к запуску тестов и можно выбрать необходимую джобу для старта.

Доступные джобы для старта:

octavia tempest tests staging — запускает Tempest для Octavia-сервиса в staging-окружении.

octavia tempest tests production — делает то же самое, но в production.

rally octavia staging — запускает сценарии Rally для Octavia сервиса в staging-окружении.

rally octavia production — запускает сценарии Rally для Octavia-сервиса в production-окружении.

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

Сохранение отчетов

Раньше после того, как все тесты «пробежали», сгенерированный отчет подгружался в PVC-хранилище. Там хранится вся информация по проведенным циклам тестирования и в любой момент ее можно достать по уникальному названию, содержащем информацию об окружении, на котором были запущены тесты, дате и времени запуска.

В ходе работы мы поняли, что это не совсем удобно, потому что количество отчетов постоянно растет. И решили добавить артефакты к нашим джобам. Теперь после прогона тестов генерируется HTML-отчет и сохраняется в папку artifacts. Так получилось удобнее хранить их для дальнейшего анализа.

Как мы автоматизировали тестирование OpenStack с помощью Rally и Tempest - 5

Как мы автоматизировали тестирование OpenStack с помощью Rally и Tempest - 6

Job artifacts.

Возможно, эти тексты тоже вас заинтересуют:

Ampere Altra Dev Kit: ATX-плата с ARM-процессором Amere Altra. Что за система и для чего она нужна?
6 дисплеев, 192 ядра и 3 ТБ ОЗУ DDR5: на что способен «ноутбук» от Mediaworkstations и другие подобные системы
Что изменилось в инструментах OpenStack? Рассказываем о самых важных обновлениях в релизе Antelope

Результаты работы и дальнейшие планы


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

Благодаря красивым и понятным HTML-отчетам можно отслеживать статистику по результатам тестов. Если нашлись упавшие тесты, можно сразу посмотреть причину — без дополнительных манипуляций. Так мы сократили время анализа и поиска проблем.

Используя Tempest и Rally удалось в сжатые сроки увеличить тестовое покрытие сервиса, наладить процесс тестирования внутри команды и поделиться опытом с другими командами внутри компании.

Однако в бочке меда всегда можно найти ложку дегтя — мы столкнулись с проблемой очистки ресурсов. Некоторые объекты зависали в статусе immutable или падали в error. А базовый инструмент cleanup далеко не всегда справлялся с задачей очистки, оставляя за собой балансировщики, сети, роутеры и плавающие адреса.

Если это происходило, то после n-го цикла тестирования выделенные ресурсы и квоты переполнялись. Конечно, можно было вручную пройтись по всем проектам и удалить оставшиеся объекты, но это требует времени и большого внимания.

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

А как тестируете бэкенд-сервисы вы? Поделитесь своим опытом в комментариях.

Автор: Валентина

Источник


* - обязательные к заполнению поля


https://ajax.googleapis.com/ajax/libs/jquery/3.4.1/jquery.min.js