@Chickencreed

Какие используются практики для отладки кода в проекте, построенном на микросервисах в Docker контейнерах?

Получил свою первую работу php backend разработчика и поплыл при первой же задаче, чувствую себя в полном смятении.
Банально не понимаю как мне отлаживать код. Никогда не работал с Docker и Docker Compose.
Когда учился и проходил стажировку, разрабатывал всегда локально, с дебагом проблем не было. Либо выводил дампы в шаблонах либо пользовался DebugBar или пошаговой отладкой в IDE, через xDebug.
Понимаю, что вопрос до невозможности глупый, но как обычно делают отладку при запуске web-api приложений в Docker? Где делать дампы? Ведь все микросервисы это web API без фронта.
На проекте используется Lumen Framework
  • Вопрос задан
  • 200 просмотров
Решения вопроса 1
gzhegow
@gzhegow
aka "ОбнимиБизнесмена"
Если вас интересует неверная работа одного микросервиса, то точно так же как вы делали. Контейнеры так или иначе содержат веб-проект и умеют отвечать на запросы с морды/браузера/курла.

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

Если вас интересует именно целиком микросервисная архитектура, которая на поверку работает верно (ошибок нету), а косяк именно в логике работы - то во первых у вас есть несколько баз данных (лучше конечно общая, но бывает разное) в ваших локальных контейнерах, где можно подключаться навикатом и смотреть что косячит, но вообще правильная организация микросервисной архитектуры идет из организации того, как работает компьютер на железном уровне.

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

Таким образом дебажится лог запросов и ответов с "шины" (эта шина пишется хорошим сеньором, либо ставится и долго настраивается хорошим сеньором), чтобы понять кто когда кому чего спрашивал.

Если в вашем проекте сервисы друг другу запросы шлют как хотят, что вы не можете это проследить и некому рассказать - трехмесячный отсчет до того момента, пока "вас тоже выгоняют на рынок" уже пошел. Это проект убийца. Владельцы его у кого-то купили, или им архитекторы насоветовали наставить полторы тысячи технологий потому что они "новые", а теперь никто не знает как это вообще включать. И они рандомом подбирают разрабов до тех пор пока кто-то не воскрикнет Эврика и всё сделает, тогда ему кинут купюрку и тоже выгонят. Как сказал Ротенберг - "у нас в стране много кулибиных, дайте бизнесу волю и они сами ЧТО-ТО-ТАМ сделают" (цитата).

Если вы все же очень хотите сохранить это рабочее место (но дальше - только хуже) - вы можете либо дампать в браузере, делая прямые запросы, логику смотреть в бд, а если логика прям жесткая - подключите пакет Monolog\Logger в dev-dependencies ко всем проектам, и включите Handler который складывает все логи в канал с одним и тем же местом хранения, и потом смотрите в каком порядке логи идут (у вас как раз и получится логгер вместо шины, только он не дает никому комманд, а только пишет что за чем произошло, это тоже задача шины и её мощь)

Берегите себя. Бизнес о вас не будет заботится. А в текущей обстановке с чрезвычайными мерами, когда даже священников просят втирать дичь - тем более.
Ответ написан
Пригласить эксперта
Ответы на вопрос 2
coderisimo
@coderisimo
1) Почитайте про POSTMAN. Он, как раз шлет запросы прямиком на API и получает ответ от сервера. В ответах может быть и отладочная информация и подробности ошибок и прочее.

2) Можно настроить xdebug для phpstorm и docker. Просто погуглите, хотя мне всегда было достаточно п.1
Ответ написан
Комментировать
Для изолированной отладки микросервисов можно использовать тесты.

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

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

Недостатки - трудно стартануть, необходимо продумать и подготовить заглушки для окружения (касается в первую очередь функциональных тестов, Unit-тесты лишены таких недостатков, но и для отладки они не всегда подходят)
Ответ написан
Комментировать
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Войти через центр авторизации
Похожие вопросы
YCLIENTS Москва
от 200 000 до 350 000 ₽
Ведисофт Екатеринбург
от 25 000 ₽
Бюро Цифровых Технологий Санкт-Петербург
от 120 000 до 180 000 ₽
02 мая 2024, в 23:29
1500 руб./в час
02 мая 2024, в 23:16
7500 руб./за проект
15 апр. 2024, в 22:14
30000 руб./за проект