На самом деле линуксом, без пачки денег можно было бы и обойтись)
это не решит проблему, тормозит в основном не на зависимостях, а на инкрементальной компиляции
кстати, я не очень понимаю, как с вендорами в нативном volume их должен видеть phpstorm.
-
Юбилейный DevConfX пройдет 21-22 июня в Москве. Как всегда — Вы решаете, кто попадет в программу секции Backend — голосуйте за интересные доклады
кстати, я не очень понимаю, как с вендорами в нативном volume их должен видеть phpstorm.
ну, настроить мапинг папок
для автокомплита в IDE можно отдельно поставить вендоров как справочник - исполняться они не будут, редактировать их не надо, а прыгать в дебагере по ним можно
только не надо про уникальные либы с отдельными виндовыми версиями, дебажить по ним не надо
что такое инкрементальная компиляция и почему она тормозит - я не знаю
для автокомплита в IDE можно отдельно поставить вендоров как справочник - исполняться они не будут, редактировать их не надо, а прыгать в дебагере по ним можно
только не надо про уникальные либы с отдельными виндовыми версиями, дебажить по ним не надо
что такое инкрементальная компиляция и почему она тормозит - я не знаю
С монорепой еще можно себе такое представить, а настраивать таким образом кучу микросервисов довольно утомительно, особенно когда в вендорах еще пачка своих собственных библиотек, которые меняются относительно часто.
Я не разбирался, но подозреваю, что всякие inotify нормально не пробрасываются, и все сваливается в рекурсивное сканирование.что такое инкрементальная компиляция и почему она тормозит - я не знаю
Нет, нет, нет.
Да если бы был описываемый тобой бардак, было бы проще в этом смысле:
Затрахаешься их отдельно ставить для каждого микросервиса.
Я как-то уже привык, что склонил репы, запустил docker-compose up и готово, можно работать. Всякую подготовительную шелуху, когда надо потратить часы на подготовку среды разработки, вспоминаю с ужасом.
А какая разница, сколько там зависимостей в сумме у всех сервисов? Каждый микросервис - это самостоятельное приложение, в нем ничего не растет.
Понятное дело, что постепенно все везде обновляется. Но всегда есть подмножество, где еще не. Предлагаешь при каждом обновлении зависимости в одном из микросервисов сразу же, немедленно, обновлять во всех остальных? Не, спасибо, у меня в бэклоге поважнее задачи есть.
Понятное дело, что постепенно все везде обновляется. Но всегда есть подмножество, где еще не. Предлагаешь при каждом обновлении зависимости в одном из микросервисов сразу же, немедленно, обновлять во всех остальных? Не, спасибо, у меня в бэклоге поважнее задачи есть.
Каждая версия завязана на свой runtime и системные либы, а на системные либы завязана версия OS в образах.
Когда в проекте, например, 50 сервисов - каждый на своем runtime, своей OS, за несколько лет авторы уходят, и зависимостей уже никто не знает.
Часть проекта собирается gulp2, часть - gulp3, часть - gulp4, каждому нужна своя версия ноды, формат конфигов несовместим, еще будет 3 версии php, несколько версий openssl и libxml.
Я помню подобный проект - это авгиевы конюшни, директор разработки регулярно ночевал в офисе на коллах из-за внезапных падений в неожданных местах. Ловить баги было довольно интересно! Однажды встретилась довольно серьезная проблема в неподдерживаемой версии runtime, пришлось останавливать разработку и срочно обновлять кучу кода.
Нормально - это когда есть корпоративный baseline с определенной версией OS и runtinme, у каждого сервиса есть owner, который обязан обеспечить совместимость всех сервисов с общим набором библиотек, и общие библиотеки BC не ломают. А если надо поломать - например, для обновления PHP с 5 до 7, то вместе со всеми сервисами, которые их используют. Это работает, на крупных проектах большинство людей занимается именно обновлением сервисов под новые версии и рефакторингом .
Когда в проекте, например, 50 сервисов - каждый на своем runtime, своей OS, за несколько лет авторы уходят, и зависимостей уже никто не знает.
Часть проекта собирается gulp2, часть - gulp3, часть - gulp4, каждому нужна своя версия ноды, формат конфигов несовместим, еще будет 3 версии php, несколько версий openssl и libxml.
Я помню подобный проект - это авгиевы конюшни, директор разработки регулярно ночевал в офисе на коллах из-за внезапных падений в неожданных местах. Ловить баги было довольно интересно! Однажды встретилась довольно серьезная проблема в неподдерживаемой версии runtime, пришлось останавливать разработку и срочно обновлять кучу кода.
Нормально - это когда есть корпоративный baseline с определенной версией OS и runtinme, у каждого сервиса есть owner, который обязан обеспечить совместимость всех сервисов с общим набором библиотек, и общие библиотеки BC не ломают. А если надо поломать - например, для обновления PHP с 5 до 7, то вместе со всеми сервисами, которые их используют. Это работает, на крупных проектах большинство людей занимается именно обновлением сервисов под новые версии и рефакторингом .
Последнее редактирование:
Вот гигабайтные образы, в которых запихана куча всего - это точно сделано плохо =)
Бейзлайны это подход для крупного бизнеса, которым надо менеджить огромную сложность. Там оверхед на его поддержку и на проблемы вида "чтобы перейти с node 10 на node 12, надо пройти 100 кругов бюрократического ада" так или иначе окупается.
В малом бизнесе же эта вся бюрократия не имеет никакого смысла, поскольку будет стоить времени (=денег) не давая ничего взамен, достаточно поддерживать все в разумных рамках. Задача то не бюрократию развести, а оптимизировать TCO. Тут примерно как с техдолгом (а в твоем случае с образами по 14 гб это и есть техдолг):
Бейзлайны это подход для крупного бизнеса, которым надо менеджить огромную сложность. Там оверхед на его поддержку и на проблемы вида "чтобы перейти с node 10 на node 12, надо пройти 100 кругов бюрократического ада" так или иначе окупается.
В малом бизнесе же эта вся бюрократия не имеет никакого смысла, поскольку будет стоить времени (=денег) не давая ничего взамен, достаточно поддерживать все в разумных рамках. Задача то не бюрократию развести, а оптимизировать TCO. Тут примерно как с техдолгом (а в твоем случае с образами по 14 гб это и есть техдолг):
"какой смысл обновлять, если у меня на линуксе все работает" = техдолг
в офисе ж сеть нормальная - пофиг размер образов, на линуксе шары не очень тормозят - десктопы с линуксом, зачем решать задачу, если можно купить железо?
а тут по vpn это качается весь рабочий день, не все хотят домой линукс, и "какой смысл" внезапно стал дорогим техдолгом!
никогда такого не было - и вот, опять
ты считаешь, что ты не такой, как все, и у тебя этого не будет? я сегодня целый день смотрел на таких, как ты, через несколько лет )))
в офисе ж сеть нормальная - пофиг размер образов, на линуксе шары не очень тормозят - десктопы с линуксом, зачем решать задачу, если можно купить железо?
а тут по vpn это качается весь рабочий день, не все хотят домой линукс, и "какой смысл" внезапно стал дорогим техдолгом!
никогда такого не было - и вот, опять
ты считаешь, что ты не такой, как все, и у тебя этого не будет? я сегодня целый день смотрел на таких, как ты, через несколько лет )))
Последнее редактирование:
Образы у меня все маленькие, с чего ты взял? Я вообще не понимаю, как они могут быть большими. Ты вендоров в образ что ли кладешь? Это примерно то же, что их коммитить в репоз, если чо.
А проблема с I/O - это проблема реализации docker-desktop. Решать ее костылями типа "установить вендоров в volume и держать их копию для IDE" и подводить под это теорию, что так и надо? Нет, спасибо.
Есть docker-sync тот же, который проблему вполне себе решает. Десктоп с линуксом я себе купил не только по этой причине, если что
А проблема с I/O - это проблема реализации docker-desktop. Решать ее костылями типа "установить вендоров в volume и держать их копию для IDE" и подводить под это теорию, что так и надо? Нет, спасибо.
Есть docker-sync тот же, который проблему вполне себе решает. Десктоп с линуксом я себе купил не только по этой причине, если что
Настраивать его и мейнтенить оверлей компоуза довольно муторно. А так проблему решает. Заодно решает и проблему UID mapping-а, которая в основном актуальна таки для линукса, хех.