Comments 14
На новом месте работы, ребята завезли Docker для разработки.
Честно, сбежал через 3 недели из Docker`а, развернул БД и прочие сервисы на совсем сервере, и запускаю как обычное App приложение, и бед не знаю.
Решарпер почему-то очень сильно начинает тормозить приложение при дебагге, а так же неадекватно работает hotreload.
Так что, по старинке лучше
ИМХО
Да, к сожалению ребятам из jetbrains еще работать и работать над поддержкой девконтейнеров. Сижу на Clion и девконтейнеры это боль, приходится вместо них использовать docker тулчейны (это похоже на девконтейнеры, но отличие в том что контейнер запускается на каждый бинарь, запускаемый IDE и живет пока бинарь не завершит работу).
А зачем дебажить приложение запущенное в Docker-е? Нельзя запустить локально инстанс и натравить конфу остальных контейнеров на него? Конечно если пытаться впихать невпихуемое, то будут сложности.
Можно сидеть на табуретке с 4-мя ножками, одна из которых сломана, и вместо сломанной подставить собственную коленку.
Однако будет очень неудобно.
Попробуйте немного в разработку реального софта и выяснится, что там есть какая-никакая инфраструктура, а ваш кейс должны на 146% закрывать автотесты, модный TDD во все места... в теории)... на практике, ну миленько, но про всякий remote debug (который в MSVS ещё со времён классического фреймворака), всякие XDebug и прочий дебаг через SSH-туннели придумали серьёзные чуваки не потому что всё так розово и пушисто.
По статье же... ну, клёво, но на дворе уже давно .NET Core 8, который даже штатно завезли репы бубунты, который умеет в chiseled containers. `version: '3.8'` для docker compose уже не требуется. Почему контейнерам дают имена с _image - не понятненько.
С Rider и дебагом в винде компоузов немного грустно, он стабильно падает с ошибкой
и при нажатии на "Install tools to the container" валится с
Поэтому приходится отключать всякие улучшайзеры (Don't use Docker fast mode) и добавлять в Environment variables
BUILD_CONFIGURATION=Debug;ASPNETCORE_ENVIRONMENT=Developmentи тогда на хосте разработчика можно зацепиться за процесс дебаггером, а на проде через CI/CD раскатанные образы будут честно релизные, без дебага
Попробуйте немного в разработку реального софта и выяснится,
Хех, вот вы попробовали, и что, у вас получается дебажить контейнеры в Райдере? Если у вас действительно есть какой-то опыт разработки реального софта, то уже давно бы поняли, что если при решении задачи возникает техническая проблема толщиной в несколько бетонных стен, то не стоит разбегаться и биться головой об них (даже если вы супермен), и по пробитии кричать во всю глотку "Я это сделал!"; а стоит просто спокойно обойти, ибо эстимейты уже проставлены. А за использование всего подряд, что есть под рукой обычно голосят еще зеленые в индустрии люди (мидл минус и ниже).
Отладка с аттачем к процессу это необходимость лишь тогда, когда реализованная фича достаточно сложна и тонка, что разраб, где-то что-то не формализовал и конкретно зафакапил; при этом совершенно ничего не логируется (что в наши дни моветон).
Нельзя запустить локально инстанс и натравить конфу остальных контейнеров на него
Вы предлагаете "долбиться об стену" чтобы настроить конфу остальных контейнеров для каждого частного случая, а их десятки. И приседать так каждый раз, с каждым новым микросервисом. И когда роуты отличаются от того что на проде - немного такое себе. Может в вашей простой реальности норм даже половину прода с юзер-специфичными данными в т.ч. приватными завернуть на локальный хост в контейнер с дебагом, попутно роняя с таймаутом всех остальных пользователей, но вообще это не ок.
Контейнеры в райдере у меня получается дебажить. Сложности начинаются когда нужно дебажить не один отдельный контейнер, а целый скоуп поднятый именно компоузом. В MSVS дебажу. В райдере "километры ржавых стен" фиксятся за 2 минуты при условии, что разработчик знает как на самом деле билдятся сборки с отладкой или знает как это погуглить. Вы навоображали стен больше, чем их есть на самом деле там, где и проблемы то всё ещё нет. А вашу зеленость в индустрии выдаёт вот эта святая вера в существование каких-то идеальных IDE которые никогда не содержат проблем и закроют всем разработчикам весь скоуп задач без хоть какого-то включения мозга.
Отладка с аттачем к процессу это необходимость
можно этот тезис написанный вами же просто пометить как состоявшийся факт и на этом прекратить воображариум. Когда фича недостаточно сложна - отладка и локальная то не очень нужна, нужны нормальные автотесты (и, на худой конец, отладка делается прямо в них).
Логирование, даже с трейсами и трекингом - всё ещё не является серебряной пулей, но уже создаёт отличную нагрузку, потому что там ежедневно десятки гигабайт от десятков инстансов написанных в разное время, на разных стеках, разными людьми, которые всё ещё больно разгребать даже в модных ёлках, нюреликах... Ну и логировать каждый шаг - это безумие и загрязнение кода.
И ничто из всего перечисленного не является серебрянной пулей, а является лишь инструментом, который чаще всего не применяется в одиночку. Почитать логи, воспроизвести, раздебажить как именно мысли разраба двухгодичной давности не сошлись с сегодняшней реальностью, дописать автотест - это нормальный и естественный флоу для багов.
А для того чтобы собрать новый образ интернет соединение обязательно? Можно ли работать с докер контейнерами и отлаживать офлайн?
rabbitmq_image, mongo_image, postgres_image - это не image, это container
А при чём тут C#?!
Docker для разработки C#