Http-stubs поиск идеального инструмента

Всем хорошего дня, я backend-разработчик компании Uma.Tech. Сегодня я хочу рассказать, как однажды нашему отделу разработки поступила задача от отдела тестирования: локально развернуть сервис создания заглушек для http-запросов. Если интересно, как проходил поиск, сравнение разных opensource и не только инструментов, до чего мы в итоге докатились и причём тут попугай на картинке прошу под кат.

Оговоримся сразу: мы не рекламируем ни один из приведенных ниже инструментов, а просто делимся своим опытом.

TLDR: Если нет желания читать много букв, в конце общая сводная таблица по всем инструментам.

Начало

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

В нашем подразделении Uma.Tech мы занимается всем, что связано с видеоконтентом. На нашей платформе работают проекты холдинга Газпром-Медиа. Если вы используете приложение PREMIER, смотрите на сайте телеканал 2x2 или, предположим, предпочитаете онлайн-трансляции дерби Спартак-ЦСКА с сайта или в приложении Матч ТВ значит, вы тоже пользователь нашей видеоплатформы.

Платформа в нашем понимании это набор сервисов. Каждый сервис имеет свою архитектуру и охватывает определенный сектор работы с контентом, например, видеоотдача, работа с покупками и метаинформацией видео, конвертация, и т.д.

Подробнее, если интересно, расскажем в отдельных статьях.

Основной язык разработки для нашей команды Python разных версий. Все сервисы общаются между собой по разным каналам передачи информации, как синхронным, так и асинхронным. Для взаимодействия в числе прочих используются webhook'и и обычные REST API.

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

Исторически тестировщики пользовались бесплатным публичным сервисом webhook.site. Однако, он имеет некоторые ограничения, кроме того, он находится вне контура компании, поэтому его использование небезопасно, так как существует вероятность утечки данных во время тестирования. Поэтому нам нужен инструмент, развернутый внутри контура, причем достаточно функциональный по возможностям приближенный к webhook.site и гибкий, с возможность создания кастомных путей.

В поисках идеала

Оговорюсь сразу, я тут перечислю не все инструменты, из которых мы выбирали, наверняка, какие-то просто не попались на глаза. Буду благодарен, если в комментариях вы поделитесь другими подобными сервисами. Я обязательно их проверю и добавлю интересные в статью.

Наличие необходимых функций было далеко не последним требованием. При выборе приходилось учитывать много факторов:

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

Напомню, наша команда пишет преимущественно на Python. Это основной язык, в котором у нас больше всего экспертизы. Поэтому удобный для разработки язык тоже является большим преимуществом для искомого нами инструмента.

webhook.site

Начнем с того, что использовали исторически webhook.site

Ссылка: https://github.com/fredsted/webhook.site

Это хороший и продуманный сервис, имеет достаточно функций для тестирования: здесь http-заглушки, фейковые email адреса и т.д.

У сервиса есть платная версия, расширяющая и без того небедный набор возможностей, которые легко можно найти в документации. Важный фактор в плюс: у webhook.site открыт исходный код на GitHub и распространяется он по лицензии MIT.

Основная страница webhook.site выглядит так:

Из минусов, которые оказались значимыми для нас: непрофильные языки для нашей команды PHP для backend и javascript для frontend.

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

postbin

Следующим вариантом, который мы рассмотрели под текущую задачу стал достаточно простой сервис postbin, находящийся в публичном доступе.

Ссылка: https://github.com/ashishbista/postbin

Его страничка выглядит примерно так:

Распространение по лицензии ISC, ныне не очень популярной, но почти эквивалентной MIT.
У postbin доступна публично развёрнутая версия, а вот с функционалом совсем скудно есть только http-заглушки.
Стек чистый javascript, для frontend и backend. В общем смотрим дальше.

httplive

Ещё один инструмент, попавший в обзор это httplive.

Ссылка: https://github.com/gencebay/httplive

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

Скриншот интерфейса httplive мы брали из документации:

В репозитории есть видео, где можно посмотреть на основные функции.
Лицензия здесь MIT, что тоже является плюсом.
Порадовала возможность создавать свои кастомные эндпоинты и простой интерфейс. Из приятного: backend на golang, этот язык мы используем в разработках для платформы.

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

irontest

Следующий продукт irontest.

Ссылка: https://github.com/zheng-wang/irontest

Целый комбайн написанный на java с множеством функций: от тестирования ftp до IBM Integration Bus.
Скриншот интерфейса предоставлять не буду, потому что страниц и настроек там множество, все это есть подробно в документации.
Распространение по лицензии Apache 2.

Инструмент интересный, но всё же слишком нагруженный для нашей задачи. Кроме того, java язык совсем не из нашего стека.
Вероятно, когда понадобится тестировать что-то кроме http, мы повторно вернёмся к irontest.

duckrails

В наших поисках дошли и до инструмента, написанного на Ruby duckrails.

Ссылка: https://github.com/iridakos/duckrails

Распространяется по лицензии MIT.
Скриншотов также не будет, так как их много в readme-проекта.
По функциональности есть нужное нам: инструмент позволяет создавать http-заглушки со всем необходим. Есть и важная для нас киллер фича создание своих кастомных скриптов, но либо на Ruby, либо JavaScript.

Отметим приятный и не перегруженный интерфейс, наличие свободной лицензии и, что важно, наличие тестов.

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

Наш выбор

На этом было решено заканчивать поиски и попробовать дополнить этот богатый мир еще одним инструментом. Мы перешли к разработке велосипеда собственного производства.

В качестве стека были выбраны максимально простые и знакомые технологии: Python и web-фреймворк Django. С фронтом возиться не хотелось, так как наша команда это backend-разработка, поэтому был найден визуально очень хороший плагин на административную панель simpleui.

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

И теперь, ко всеобщему вниманию, ещё один инструмент в сфере интеграционного тестирования Parrot!

Parrot

Мы решили, что наш сервис должен быть похож на попугая: быть милым, симпатичным, ручным, домашним и четко повторять ответы, которым его обучили.

Ссылка: https://github.com/Uma-Tech/parrot

Проект распространяется по лицензии Apache 2.
Свободен для коммерческого использования, имеет репозиторий на GitHub со множеством автопроверок кода: автотестами, статическими анализаторами, линтингом и дружелюбен для контрибьютинга.

Написан на языке Python третьей версии.
Запакован в docker для простого развертывания на сервере.
Основной функционал это создание http-заглушек, вечное хранение лога (в дальнейшем сделаем настройки автоочистки), возможность использования любых путей для заглушек.

Вот так, на данный момент, выглядит наш маленький попугай:

Интерфейс хоть и изменён визуально, но не сильно отличается от стандартного интерфейса Django.
В разделе Authentication and Authorization можно управлять пользователями, группами и правами для них.

Основной раздел HTTP Stubs, в нём можно создавать заглушки и просматривать логи запросов. Из интересного: для URL можно использовать regex-выражение, остальное плюс-минус стандартно, как в прочих инструментах.

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

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

Общее сравнение

Что в итоге

Приложением стали активно пользоваться наши тестировщики, а после его презентации на внутреннем демо, Parrot заинтересовал и другие команды из компании Uma.Tech.
Увидев, что инструмент удобен нам и интересен другим, мы решили поделиться им со всем сообществом. Будем очень рады обратной связи и вашим pull requests.
Нам эта история показала, что иногда лучше изобрести свой велосипед, чем ехать на чужом.

Мы запускали новые сервисы, трафик рос, заменяли сервера, подключали новые площадки и переделывали ЦОДы а сейчас расскажем эту историю, с началом которой знакомили вас пять лет назад.

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

Мы обеспечиваем работу сложнейших проектов с жесточайшими требованиями к надежности, и к нагрузкам, среди которых PREMIER и Матч ТВ. На спортивных трансляциях и на премьере популярных сериалов требуется отдача трафика в терабиты/с, мы это легко реализуем, причем так часто, что работа с такими скоростями давно стала для нас обыденностью. А пять лет назад самым тяжелым проектом, работающим на наших системах, был Rutube, который с тех пор развивался, наращивал объемы и трафик, что нужно было учитывать при планировании нагрузок.

Мы рассказывали о том, как развивали железо нашей инфраструктуры (Rutube 2009-2015: история нашего железа) и развивали систему, ответственную за отгрузку видео (С нуля до 700 гигабит в секунду как отгружает видео один из крупнейших видеохостингов России), но с момента написания этих текстов прошло много времени, создано и внедрено множество других решений, результаты которых позволяют нам отвечать современным требованиям и быть достаточно эластичными, чтобы перестраиваться для новых задач.

Сетевое ядро постоянно развиваем. Мы перешли на оборудование Cisco в 2015 году, о чем упоминали еще в прошлой статье. Тогда это были всё те же 10/40G, но по понятной причине уже через несколько лет модернизировали существующие шасси, и теперь активно используем ещё и 25/100G.



Линки 100G уже давно не являются ни роскошью (скорее, это настоятельное требование времени в нашем сегменте), ни редкостью (всё больше операторов предоставляют подключение на таких скоростях). Однако, 10/40G сохраняет актуальность: через эти линки мы продолжаем подключать операторов с небольшим объёмом трафика, по которым на данный момент нецелесообразно задействовать более ёмкий порт.

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

Серверы отдачи видео эволюционируют быстро, для чего мы предлагаем немало усилий. Если раньше мы использовали преимущественно 2U серверы с 4-5 сетевыми картами по два 10G-порта у каждой, то теперь большая часть трафика отдаётся с 1U серверов, в которых 2-3 карточки по два 25G-порта у каждой. Карты с 10G и с 25G практически сравнялись в стоимости, а более скоростные решения позволяют отдавать как по 10G, так и по 25G. Результатом стала очевидная экономия: меньше компонентов сервера и кабелей для подключения меньше стоимость (и выше надежность), компоненты занимают меньше места в стойке стало возможным размещение большего числа серверов на единицу площади и, следовательно, стала ниже стоимость аренды.

Но важнее выигрыш в скорости! Теперь мы с 1U можем отдавать более 100G! И это на фоне ситуации, когда некоторые крупные российские проекты называют достижением отдачу 40G с 2U. Нам бы их проблемы!

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

Системы хранения данных тоже растут. За прошедшую пятилетку они из двенадцатидисковых (12x HDD 2U) стали тридцатишестидисковыми (36х HDD 4U). Такие емкие тушки некоторые боятся использовать, так как в случае выхода из строя одного такого шасси может возникнуть угроза для производительности а то и работоспособности! для всей системы. Но у нас такого не случится: мы обеспечили резервирование на уровне геораспределенных копий данных. Мы разнесли шасси по разным дата-центрам всего мы используем три и это исключает возникновение проблем как при сбоях в шасси, так и при падении площадки.



Разумеется, такой подход сделал избыточным аппаратный RAID, от которого мы отказались. Избавившись от избыточности, мы одновременно повысили надежность системы, упростив решение и убрав одну из потенциальных точек отказа. Напомним, что СХД у нас самодельные. На это мы пошли совершенно сознательно и результат нас полностью устроил.

ЦОДы за прошедшие пять лет мы меняли несколько раз. Со времени написания предыдущей статьи мы не меняли только один ЦОД DataLine остальные потребовали замены по мере развития нашей инфраструктуры. Все переезды между площадками были плановые.

Два года назад мы мигрировали внутри ММТС-9, перейдя на площадки с качественным ремонтом, хорошими системами охлаждения, стабильным электропитанием и без пыли, которая раньше лежала толстыми слоями на всех поверхностях, а также обильно забивала внутренности нашего оборудования. Выбор в пользу качества услуг и отсутствия пыли! стал причиной для нашего переезда.

Почти всегда один переезд равен двум пожарам, но проблемы при миграции каждый раз разные. На этот раз основная сложность переезда внутри одного ЦОДа обеспечили оптические кроссировки их межэтажное обилие без сведения в единую кроссовую со стороны операторов связи. Процесс актуализации и перепрокладки кроссировок (в чем нам помогли инженеры ММТС-9), был, пожалуй, самым сложным этапом миграции.

Вторая миграция состоялась год назад, в 2019 году переезжали мы из М77 в O2xygen. Причины переезда были схожие с рассмотренными выше, но к ним добавилась проблема с непривлекательностью исходного ЦОДа для операторов связи многих провайдеров приходилось догонять до этой точки своими силами.

Миграция 13 стоек на качественную площадку в ММТС-9 позволило развивать эту локацию не только как операторскую (пара-тройка стоек и пробросы операторов), но и задействовать в качестве одной из основных. Это несколько упростило миграцию из М77 большинство оборудования из этого ЦОД мы перевезли на другую площадку, а O2xygen отвели роль развивающегося, отправив и туда 5 стоек с оборудованием.

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

Основную фазу переезда мы обязательно проводим за одну ночь, и при миграции внутри ММТС-9 и на O2xygen придерживались этого правила. Подчеркнем, что правило переезд за ночь мы строго выполняем независимо от количества стоек! Был даже прецедент, когда мы перемещали 20 стоек и выполнили это тоже за одну ночь. Миграция достаточно нехитрый процесс, требующий аккуратности и последовательности, но и тут есть некоторые хитрости как в процессе подготовки, так и при переезде, и при развертывании на новой локации. О миграции в деталях мы готовы подробно рассказать, если у вас будет заинтересованность.

Результаты пятилетки развития нам нравятся. Мы завершили построение новой отказоустойчивой инфраструктуры, распределенной по трем центрам обработки данных. Резко повысили плотность отдачи трафика если недавно радовались 40-80G с 2U, то сейчас для нас норма отдавать 100G с 1U. Теперь и терабит трафика воспринимается нами как обыденность. Мы готовы и дальше развивать нашу инфраструктуру, которая получилась гибкой масштабируемой.

Вопрос: о чем рассказать вам в следующих текстах, уважаемые читатели? О том, почему мы стали создавать самодельные системы хранения данных? Про сетевое ядро и его особенности? О хитростях и тонкостях миграции между дата-центрами? Об оптимизации решений по выдаче путем подбора компонент и тонкой настройки параметров? Про создание устойчивых решений благодаря многократному резервированию и горизонтальным возможностям масштабирования внутри дата-центра, которые реализованы в структуре из трех ЦОДов?

Автор: Петр Виноградов