Всем привет, меня зовут Валентина! Уже около пяти лет я работаю в тестировании, из них более трех занимаюсь прожаркой 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, без прямого участия человека.
Здесь возникает один из самых интересных вопросов, который нам предстояло решить: как запустить тесты в продакшене такими образом, чтобы это не повлияло на работу клиентов?
Настройка ручного тестирования
Для начала необходимо было понять, какие результаты мы получим, если настроим простое ручное тестирование 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. Он позволяет пользователям и админам выдавать доступы к ресурсам внутри определенного проекта. Таким образом, мы создали сеть видимой лишь для тестовых проектов и добились изоляции.
Создание сети с помощью 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 они запускаются.
Супер — все готово к запуску тестов и можно выбрать необходимую джобу для старта.
Доступные джобы для старта:
→ 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. Так получилось удобнее хранить их для дальнейшего анализа.
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, который умеет мониторить тестовые проекты и подчищать все то, что осталось после тестирования. Но это уже тема следующей статьи. Следите за публикациями в нашем блоге на Хабре!
А как тестируете бэкенд-сервисы вы? Поделитесь своим опытом в комментариях.
Автор: Валентина
