![](https://habrastorage.org/webt/_k/qj/6f/_kqj6fpnojgpcjqdbmx9e_4e2us.png)
Всем привет, меня зовут Валентина! Уже около пяти лет я работаю в тестировании, из них более трех занимаюсь прожаркой 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, без прямого участия человека.
Здесь возникает один из самых интересных вопросов, который нам предстояло решить: как запустить тесты в продакшене такими образом, чтобы это не повлияло на работу клиентов?
![](https://habrastorage.org/webt/0x/6c/p2/0x6cp2dicsi2zttywtzpmaww0kg.jpeg)
Настройка ручного тестирования
Для начала необходимо было понять, какие результаты мы получим, если настроим простое ручное тестирование 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. Он позволяет пользователям и админам выдавать доступы к ресурсам внутри определенного проекта. Таким образом, мы создали сеть видимой лишь для тестовых проектов и добились изоляции.
![](https://habrastorage.org/webt/1s/0-/4n/1s0-4nmc0k3em_iuqza9qc_pyr0.png)
Создание сети с помощью rbac-policy.
Автоматизация тестирования
Когда мы наладили механизм ручного тестирования и изолировали рабочую среду, можно было приступить к автоматизации.
В качестве CI/CD под пайплайн мы выбрали GitLab — его синтаксис гораздо проще чем в Jenkins, а поддержка CI более проста. Это позволяет сократить время вхождения для инженеров, у которых нет опыта в автоматизации — это как раз моя остановочка!
В качестве конечной цели был выбран автоматический запуск тестов по нажатию кнопки. Внутри пайплайна было сделано разделение по двум критериям — окружение, на котором будут запущены тесты (staging и production), и вид тестов (Rally-сценарии или Tempest-тесты). Таким образом, было необходимо создать 4 джобы:
- запуск Tempest-тестов в staging окружении,
- запуск Tempest-тестов в production окружении,
- запуск Rally-сценариев в staging окружении,
- запуск Rally-сценариев в production окружении.
Как я уже говорила, мы не используем решение OpenStack из коробки, поэтому изменениям подверглись и сами фреймворки для тестирования. Следовательно, нам нужно было собрать новый Docker-образ, включающий в себя изменения, которые мы добавили в Tempest и Rally. В итоге получилась следующая цепочка:
- В репозитории rally-openstack собирается образ с необходимой версией, куда включаются все необходимые изменения.
- На основе получившегося образа Rally собирается образ в репозитории Tempest, куда аналогичным образом подгружаются проделанные изменения.
- На основе полученного 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
В результате у нас получился пайплайн, состоящий из трех основных этапов. В его основу вошли не только джобы для запуска тестов, описанные выше, но и джобы, позволяющие проверить работоспособность и единообразие кода:
-
lint
— этап, на котором происходит запуск линтера flake8. Это анализатор кода, который помогает находить распространенные ошибки, делать код единообразным и более читаемым. -
unit
— этап, на котором происходит запуск unit тестов, которые содержатся внутри octavia tempest plugin. -
build image
— этап, на котором происходит создание Docker-образа, на основе dockerfile.
Данные этапы являются автоматическими и при добавлении изменений в репозиторий octavia tempest plugin они запускаются.
![](https://habrastorage.org/webt/uc/zk/ph/uczkphiq4crrgii-hasz4y6sfpm.gif)
Супер — все готово к запуску тестов и можно выбрать необходимую джобу для старта.
Доступные джобы для старта:
→
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. Так получилось удобнее хранить их для дальнейшего анализа.
![](https://habrastorage.org/webt/su/4m/v_/su4mv_t7ro9_vefn0xoryyktgwm.png)
![](https://habrastorage.org/webt/fu/qd/w2/fuqdw2zvfplhbe4t1s0_rrhmqtg.png)
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, который умеет мониторить тестовые проекты и подчищать все то, что осталось после тестирования. Но это уже тема следующей статьи. Следите за публикациями в нашем блоге на Хабре!
А как тестируете бэкенд-сервисы вы? Поделитесь своим опытом в комментариях.