Первоначально опубликовано в блоге MetalBear.
Петля разработчика (или: знай своего врага)
Представьте, что вы бэкенд-разработчик в SaaS-компании soonicorn серии B. Вы потратили половину спринта на добавление новой функции в свой микросервис. Вы тщательно изучили возможные входы и состояния базы данных и создали сложный набор тестов. Ваш код был безжалостно отрецензирован двумя вашими коллегами по команде. Наконец, тесты пройдены, запрос на исправление одобрен, и в качестве последней проверки вы развертываете свой новый код в среду постановки…
Где он почти сразу же падает. Оказывается, вы забыли протестировать какую-то непонятную конфигурацию или сложное состояние базы данных, которое может возникнуть только в зрелой, сложной среде – такой, как staging, в отличие от вашей локальной машины.
Поэтому вы возвращаете сервис на staging, исправляете ошибку, пишете еще несколько тестов, снова получаете рецензию, собираете код, развертываете его на staging… и он снова падает. Пока вы исправляли ошибку, ваш коллега по команде развернул новую версию какого-то другого микросервиса – только он не такой тщательный тестировщик, как вы, и новая версия сломана, поэтому вы не можете протестировать свой собственный сервис. Вы ждете, пока они откатают свой сервис до рабочей версии, спринт давно закончился, а вы начали работу над следующей функцией во время простоя, так что теперь вы делите свое внимание между двумя вещами.
Хуже всего то, что вы знаете, что это повторится в следующем спринте.
Зеркало (или: как победить)
Я сталкивался с той или иной вариацией “петли разработчика” в каждом стартапе, в котором я когда-либо работал, и именно эту проблему мы пытаемся решить с помощью mirrord. mirrord работает в двух местах – на вашей локальной машине для разработки и в вашей среде постановки. Обернув ваш локальный процесс и подключив системные вызовы, он позволяет вам подключить ваш процесс неинвазивно к экземпляру сервиса в среде постановки.
Проще говоря, mirrord позволяет запускать локальный процесс в контексте облачного сервиса. Это означает, что вы можете тестировать свой код на staging, не развертывая его там. Это не только избавляет вас от необходимости развертывать код каждый раз, когда вы вносите изменения, но и сохраняет среду тестирования свободной от непроверенных версий и постоянно пригодной для использования всеми остальными сотрудниками организации.
Начало работы (и: другая практическая информация)
Сегодня мы выпускаем mirrord 2.0, который поддерживает входящий трафик. Это означает, что любой трафик, поступающий на ваш сервис в staging, дублируется mirrord и отправляется в ваш локальный процесс. Вскоре мы добавим поддержку исходящего трафика, доступа к файлам и переменным окружения – все, что необходимо для того, чтобы ваш локальный процесс “думал”, что он работает в среде staging.
Все, что вам нужно для запуска mirrord, – это доступ kubectl к вашей staging-среде1. Вы можете использовать его как CLI-инструмент или расширение для VS Code (поддержка IntelliJ уже на подходе). Попробуйте его здесь, и дайте нам знать, что вы думаете по адресу hi@metalbear.co или в нашем репозитории!
-
Обратите внимание, что mirrord не устанавливает ничего постоянного в вашем кластере Kubernetes. Он запускает задание, которое самоудаляется при завершении работы mirrord.