WRex — проектная работа выпускника курса «Разработчик Python»

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

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

Мы используем для этого Cisco TRex, потому что: — это открытый продукт; — Cisco — это крупнейший, один из старейших и, наверное, самый известный в мире вендор, который точно разбирается в сетях; — в основе своей использует DPDK, что позволяет получать хорошую сетевую производительность на весьма скромном железе; — там есть python API.

Так что же такое wrex и зачем я его написал?

Собственно, wrex — это обёртка над API TRex, которая нужна для того, чтобы избежать некоторых проблем в эксплуатации и получить то, что нам нужно. Как и любой другой продукт, TRex не идеален: я писал багрепорты, делал пулреквесты, потому что были определенные проблемы.

К тому же, всё, что API умеет — это просто запустить тест с некоторыми характеристиками и получить оттуда данные по запросу. Помимо того, TRex API имеет 2 разных синтаксиса для его разных режимов работы, что неудобно, не говоря уже о порой невнятных сообщениях об ошибках.

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

Всем вышеперечисленным обёртка wrex и занимается. Она предоставляет единый интерфейс для режимов оригинального TRex, имеет какие-то генерик солверы и позволяет использовать внешние солверы, написанные на python, благодаря которым тесты могут иметь специфические параметры, основанные на некоторой внешней логике, и вместо того, чтобы писать всё вручную, система позволяет получать итоговый результат автоматически.

Как это работает?

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

Ознакомиться с исходным кодом обёртки wrex можно по ссылке на репозиторий в GitHub. Свои вопросы по работе Wrex оставляйте в комментариях.