Как быстро и эффективно отлаживать микросервисы с помощью KubeOrbit

Статус-кво отладки тестовой среды

Часто можно услышать такие жалобы, как «плохая тестовая среда влияет на эффективность разработки». Считается, что из-за разницы между средами развертывания многие разработчики сталкиваются с различными проблемами в тестовой среде, несмотря на то, что при локальном тестировании код работал без сбоев.

Мы можем начать задаваться вопросом: а что, если отладка доступна в тестовой среде?

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

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

В идеальной ситуации вам достаточно повезло, что вывод журнала и проблема анализируются из контекстных данных одновременно. Но реальность может быть намного суровее — журналы могут не отражать проблему, и мы можем даже пропустить их запись. Нам придется изменить код, добавив журнал, развернуть, выполнить, вывести и, наконец, просмотреть его. Шаги повторяются несколько раз, чтобы можно было воспроизвести ошибки.

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

Отладка с помощью KubeOrbit

Ваши коллеги, возможно, отлаживали локальные точки прерывания, когда вы все еще боролись с контекстными данными построчно. Отладка тестовой среды еще никогда не была такой простой благодаря использованию KubeOrbit. Вы можете перенаправить целевую службу на свои локальные точки прерывания для отладки, когда захотите, и проверить контекстные данные. Забудьте обо всем этом беспорядке в предыдущих тестовых средах, в KubeOrbit нет проблем.

Использование KubeOrbit выглядит элегантно. После запуска локальной службы есть только одна команда:

./orbitctl forward --deployment portal-service-deployment --namespace apps --containerPort 9000 --localPort 9000

После запуска вы увидите подсказку ниже:

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

Когда вы решите прекратить локальную отладку, просто введите следующую команду:

./orbitctl uninstall --deployment portal-service-deployment --namespace namespace-a

Весь процесс был простым и гибким.

Пользовательский опыт и личные предложения

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

Тем не менее, это все же лучше, чем традиционный способ — проверка журналов на наличие контекстных данных для решения проблемы. Мы надеемся, что в будущем KubeOrbit позволит проводить параллельные тесты и множественное локальное использование внутри службы. Было бы лучше, если бы была визуализированная панель управления для управления статусом службы.

Также опубликовано здесь