|
Разработка в Docker
|
|||
---|---|---|---|
#18+
Вот встал вопрос. Всегда запускал проект на хосте и обходился отдельным профилем для локального запуска (нежели на проде). Например вместо posgres - h2 и т.п. При этом на PHP давно уже имею практику разработки в контейнере докера (туда пробрасывается код IDE и все без проблем работает, ну там проще - язык скриптовый). Решил эту практику попробовать на Kotlin + Spring Boot и всё оказалось не так-то просто. Есть некоторые манулы в интернете по настройке работы IDEA с окружением внутри контейнера докера, но ничего из этого нормально не работает. Один из вариантов это просто включение удаленной отладки в JVM в контейнере, ну такое себе на самом деле. Каждый раз пересобирать контейнер не удобно, да и IDE не трекает его состояние, надо в отдельное меню лазить. Стало интересно, на сколько вообще распространенная практика. Например хочу чтобы проект работал с настоящей PG, разворачивать на хосте? ... |
|||
:
Нравится:
Не нравится:
|
|||
12.11.2021, 16:18 |
|
Разработка в Docker
|
|||
---|---|---|---|
#18+
Hett Стало интересно, на сколько вообще распространенная практика. Например хочу чтобы проект работал с настоящей PG, разворачивать на хосте? ... |
|||
:
Нравится:
Не нравится:
|
|||
12.11.2021, 16:32 |
|
Разработка в Docker
|
|||
---|---|---|---|
#18+
Hett, В чем разница прода? Если постгри, то сейчас вполне можно его ставить везде где надо и не надо. ... |
|||
:
Нравится:
Не нравится:
|
|||
12.11.2021, 16:58 |
|
Разработка в Docker
|
|||
---|---|---|---|
#18+
chpasha Hett Стало интересно, на сколько вообще распространенная практика. Например хочу чтобы проект работал с настоящей PG, разворачивать на хосте? Можно. Но нужно тогда заморачиваться ручной настройкой сети. Хост не видит контейнеры по именам да и доступа к ним не имеет если порты не пробрасывать. ... |
|||
:
Нравится:
Не нравится:
|
|||
12.11.2021, 17:28 |
|
Разработка в Docker
|
|||
---|---|---|---|
#18+
PetroNotC Sharp Hett, В чем разница прода? Если постгри, то сейчас вполне можно его ставить везде где надо и не надо. Не удобно, особенно в случае микросервисной архитектуры. Все разработчики должны развернуть пачку сервисов, это может занять не один день, особенно если в них не ориентироваться. В этом плане контейнеризация удобнее. И если понадобилось работать над каким-то сервисом, то удобнее это делать в докере, чтобы меньше заниматься перенастройками всего окружения. ... |
|||
:
Нравится:
Не нравится:
|
|||
12.11.2021, 17:31 |
|
Разработка в Docker
|
|||
---|---|---|---|
#18+
Hett, Если микросервисы то есть менеджеры для работы с ними. Причем пачками. ... |
|||
:
Нравится:
Не нравится:
|
|||
12.11.2021, 17:40 |
|
Разработка в Docker
|
|||
---|---|---|---|
#18+
5ый топик с проблемами микросервисов... ... |
|||
:
Нравится:
Не нравится:
|
|||
12.11.2021, 17:41 |
|
Разработка в Docker
|
|||
---|---|---|---|
#18+
PetroNotC Sharp Hett, Если микросервисы то есть менеджеры для работы с ними. Причем пачками. Что за менеджеры? ... |
|||
:
Нравится:
Не нравится:
|
|||
12.11.2021, 18:20 |
|
Разработка в Docker
|
|||
---|---|---|---|
#18+
Hett Есть некоторые манулы в интернете по настройке работы IDEA с окружением внутри контейнера докера, но ничего из этого нормально не работает. Один из вариантов это просто включение удаленной отладки в JVM в контейнере, ну такое себе на самом деле. Каждый раз пересобирать контейнер не удобно, да и IDE не трекает его состояние, надо в отдельное меню лазить. Докер для разработки ничего толком не дает. Тоесть разработчику должно быть глубоко наплевать на докерность или не-докерность системы. Он ведь учился на разработку Java/JVM. И собеседовали его по этому-же профилю. Поэтому и отладку можно делать локально. Нет коечно могут спрашивать про техники виртуализации но КМК это ближе к собесу на девопса. Тоесть это такие себе вопросы... из серии "неплохо было-бы знать" но не критично. Ситуации когда нужно именно отладчиком прицепится на прод - это архи-критичные ситуации. И часто это рассматрвиается как security-инцедент. Во многих банках PROD например отделен от окружения Dev и по дизайну не предполагается вообще никакого доступа кроме логов которые можно просто в режиме R/O просмотреть или заказать. А если нужно поднимать Postgres+Application то можно попробовать docker-compose. И если уж не хватит возможностей - то тогда посмотреть в Кубер и прочие штуки. ... |
|||
:
Нравится:
Не нравится:
|
|||
12.11.2021, 19:01 |
|
Разработка в Docker
|
|||
---|---|---|---|
#18+
PetroNotC Sharp Да знаю я про кубик. Как это на мой вопрос отвечает? В нем все те же образы крутятся. И сервис локатор внутреннюю сеть использует и все те же проблемы что с docker-compose при попытке вынести один сервис на хост-машину. ... |
|||
:
Нравится:
Не нравится:
|
|||
12.11.2021, 19:35 |
|
Разработка в Docker
|
|||
---|---|---|---|
#18+
mayton Ситуации когда нужно именно отладчиком прицепится на прод - это архи-критичные ситуации. И часто это рассматрвиается как security-инцедент. Согласен По хорошему, стандарты Oracle требуют минимимум 3-х ОДИНАКОВЫХ конфигураций. DEV - TEST - PROD. И если DEV ище может отличаться по конфигурации железа/баз/софта отличаться от PROD, то TEST, по логике, должен быть точной копией один в один. Одинаковое железо, одинаковые базы и так далее. На практике, часто на TEST кладут больший или меньший болт, из-за сложности и стоимости точно точно такойже конфигурации как и на PROD. В результате, в относительно редких случаях, кроме как на самом PROD проблему и не воспроизвести (например "особенности" работы NIO на много-много-ядерном сервере с NUMA) Самому приходилось отлаживать на PROD и аж давали рутовые пароли. При этом подвисание машины и сотни тысячь (!) клиентов по всему миру тупо подвисли бы. PROD находился на Лондонской биржы и для него была куплена подписка на данные с биржи (все настроено). Можно или нет было получать купленные данные с другого компа (полноценно запустить приложение/сервис) - то вообще никто не знал ))). Ну и проблема на другой конфигурации железа просто не воспроизводилась. mayton Во многих банках PROD например отделен от окружения Dev и по дизайну не предполагается вообще никакого доступа кроме логов которые можно просто в режиме R/O просмотреть или заказать. Тогда в контуре банка должен быть TEST один в один с PROD конфигурации. ... |
|||
:
Нравится:
Не нравится:
|
|||
12.11.2021, 20:04 |
|
Разработка в Docker
|
|||
---|---|---|---|
#18+
Проблему ТС и понимаю и не понимаю одновременно 1. Чем доккер настолько сильно отличается от отдельной машины-сервера? 2. Понятно, что для удаленной отладки (как и для удаленного доступа к PostgreSQL и прочим сервисам) нужно пробрасывать порты 3. В связи с пунктом 2, не очень понятна, чем удаленная разработка/отладка в докере будет сильно проще нормальной "настройкой сети", что бы компьютеры разработчика имели доступ к сервисам из полноценного TEST окружения (базы и прочее). 4. Зачем пересобирать докер контейнер при деплое - так же не понятно. Деплой при DEV это все же в большей части просто файлы .class, .jar, .war. Зачем для компиляции деплоя пересобирать докер и чем Java принципиально отличается от PHP - мне не понятно etc. etc... В общем: 5. Нормально настраивать сеть (резолвинг имен, проброс портов) все равно придется и в том и в другом случае. 6. Нормально настраивать DEV - TEST - PROD окружения желательно все равно. p.s. в сообщении выше, как раз отлаживался/профелировал в докере. Но докер или нет меня мало интересовало. Мне просто дали команды на вход в нужную машину-образ, каким образом подключаться к порту для удаленной отладки, куда выкладывать подправленный мною Jar'ник и как перезапускать нужный мне сервис. Все. Докер или нет, с точки зрения разработки/отладки/профилирования, в целом-то пофиг. ... |
|||
:
Нравится:
Не нравится:
|
|||
12.11.2021, 20:13 |
|
Разработка в Docker
|
|||
---|---|---|---|
#18+
Hett , я как-то пробовал так же просто с PG работать из контейнера. В итоге плюнул, правда больше из-за того что Docker под Mac очень тормозит. Но в общем и целом установить раз все это дело локально не сложно и работать так тоже проще. По поводу огромного кол-ва микросервисов, я бы предложил такие решения: 1. Использовать моки. У меня к примеру в проекте около 10 интеграций, на все их написаны моки. И по сути все моки поднимаются как одно маленькое приложение. Все работает быстро и позволяет мне сконцентрироваться на своем проекте. 2. Плюс нужно какое-то окружение где задеплоены все сервисы и мы могли бы с локальных машин подключать их. В таком случае локально не надо будет разворачивать ничего кроме своего. Архитектура конечно должна поддерживать такое. Это все к тому же обсуждению pull vs push архитектуры - pull здесь сильно помогает. 3. И если все-таки понадобилось развернуть что-то локально - то что надо, то и разворачиваем. Т.е. к примеру используем N сервисов удаленных и 1 локальный. Ну а если все-таки много сервисов нужно запустить (это должно быть редкостью), то да - тут Docker лучше всего подойдет. Но нам же разрабатывать прям в контейнере все равно не надо? Наш сервис на хосте может работать и общаться с теми кто в контейнерах. Т.е.: HettМожно. Но нужно тогда заморачиваться ручной настройкой сети. Хост не видит контейнеры по именам да и доступа к ним не имеет если порты не пробрасывать.Да, это обязательно нужно сделать и это очень быстро оправдает себя. ... |
|||
:
Нравится:
Не нравится:
|
|||
13.11.2021, 10:34 |
|
Разработка в Docker
|
|||
---|---|---|---|
#18+
Stanislav Bashkyrtsev, Вот в том же PHP проще код в контейнер прокинуть и вообще не заморачиваться с хостами и вообще настройкой какого-либо окружения. Причем как правило в докер-композ просто мапят текущий каталог с кодом внутрь контейнера и это удобно. Но там нет живущего постоянно приложения, поэтому нет проблемы сделать так. Если мы выносим разработку из контейнера на хост, то сразу возникает проблема - а как другие контейнеры будут обращаться к этому сервису? А как сервис будет к контейнерам обращаться. Всё это настраиваемо, но придется делать индивидуально на каждой машине, ну... конечно можно все это сделать, но я думал есть способ по проще. На счет моков - их тоже поддерживать надо, не разу не пробовал такое, но имхо там больше шансов, что локально всё ок, а в реальной среде - нет. ... |
|||
:
Нравится:
Не нравится:
|
|||
13.11.2021, 14:50 |
|
Разработка в Docker
|
|||
---|---|---|---|
#18+
Hett, чет мне показалось что вы не совсем понимаете как оно работает... из контейнеров доступ к хосту есть по адресу host.docker.internal (хз что там в wsl2, но в docker desktop есть), хотите чтобы и в обратную сторону работало - ставьте linux, запускайте идею с nsenter. ... |
|||
:
Нравится:
Не нравится:
|
|||
13.11.2021, 15:13 |
|
Разработка в Docker
|
|||
---|---|---|---|
#18+
Андрей Панфилов Hett, чет мне показалось что вы не совсем понимаете как оно работает... из контейнеров доступ к хосту есть по адресу host.docker.internal (хз что там в wsl2, но в docker desktop есть), хотите чтобы и в обратную сторону работало - ставьте linux, запускайте идею с nsenter. у господ mac. А так у меня нормально так и не завелось с host.docker.internal (линукс). Проверил сейчас еще раз ничего не поменялось. насколько я помню это host.docker.internal для винды и под мак, под линукс ничего еще нет. по итогу сейчас все в наружу порты мапятся. (если больше одного проекта в работе то геморно). в каждый проект по docker-compose ... |
|||
:
Нравится:
Не нравится:
|
|||
13.11.2021, 16:53 |
|
Разработка в Docker
|
|||
---|---|---|---|
#18+
Если с postgres ну еще частенько можно не выходя из IDE открыть терминальную сессию прям в IntelljIDeaa а там дальше по накатанной psql -U -W :) ... |
|||
:
Нравится:
Не нравится:
|
|||
13.11.2021, 17:02 |
|
Разработка в Docker
|
|||
---|---|---|---|
#18+
lleming насколько я помню это host.docker.internal для винды и под мак, под линукс ничего еще нет ... |
|||
:
Нравится:
Не нравится:
|
|||
13.11.2021, 17:17 |
|
Разработка в Docker
|
|||
---|---|---|---|
#18+
Андрей Панфилов Hett, чет мне показалось что вы не совсем понимаете как оно работает... из контейнеров доступ к хосту есть по адресу host.docker.internal (хз что там в wsl2, но в docker desktop есть), хотите чтобы и в обратную сторону работало - ставьте linux, запускайте идею с nsenter. Если сервис локатора на уровне приложений нет, то это все равно гемор. Вот развернул с десяток серивисов и нам нужно на одном поработать. Для этого нужно всем остальным сервисам как-то сказать, что один сервис теперь имеет другой хост - `host.docker.internal`. Понятно, что это сведется к обновлению конфигов и перезапуску сервисов. А если два сервиса сразу дорабатываем, то еще и конфликт портов будет, но опять же все решаемо, я уже это все проходил. В моем идеальном мире IDE должна уметь запускать приложение в контейнере с сконфигурированной средой (кстати IDEA умеет, но пока не понял, умеет ли все, что я хочу или нет, пока не разобрался до конца) ... |
|||
:
Нравится:
Не нравится:
|
|||
13.11.2021, 18:53 |
|
Разработка в Docker
|
|||
---|---|---|---|
#18+
Hett PetroNotC Sharp Да знаю я про кубик. Как это на мой вопрос отвечает? В нем все те же образы крутятся. И сервис локатор внутреннюю сеть использует и все те же проблемы что с docker-compose при попытке вынести один сервис на хост-машину. Kubernetes поддерживает DNS. Значит в файле лежит перечень всех сервисов по их именам. Значит у тебя что на проде, что на стенде дома будет автоматический поиск сервисов. Не? ... |
|||
:
Нравится:
Не нравится:
|
|||
13.11.2021, 19:34 |
|
Разработка в Docker
|
|||
---|---|---|---|
#18+
PetroNotC Sharp Hett пропущено... Да знаю я про кубик. Как это на мой вопрос отвечает? В нем все те же образы крутятся. И сервис локатор внутреннюю сеть использует и все те же проблемы что с docker-compose при попытке вынести один сервис на хост-машину. Kubernetes поддерживает DNS. Значит в файле лежит перечень всех сервисов по их именам. Значит у тебя что на проде, что на стенде дома будет автоматический поиск сервисов. Не? В том то и дело, что будет, пока мы что-то из контейнеров на хост не выносим. ... |
|||
:
Нравится:
Не нравится:
|
|||
13.11.2021, 20:53 |
|
Разработка в Docker
|
|||
---|---|---|---|
#18+
На текущий момент картина такая (и не факт что правильная): - В проде все крутится в кубике, образы собираются отдельными Dockerfile, которые лежат в отдельном репозитории с чартами, триггерятся при обновлении мастера и деплоятся в куб в прод. - Локально разработчики поднимают каждый сервис при помощи docker-compose и сопутствующего в репозитории сервиса Dockerfile_dev. Большинство разработчиков могут даже не разбираться в тонкостях конкретного сервиса, они просто делают `docker-compose up -d` и имеют работающий сервер со своей базой данных и прочими сопутствующими сервисами. Это могут быть фронтэндеры, которым нужна работающая инфраструктура для написания фронта. А могут быть и разработчики какого-то отдельного сервиса, над которым им нужно работать и тут то и начинаются "пляски с бубном". ... |
|||
:
Нравится:
Не нравится:
|
|||
13.11.2021, 21:01 |
|
Разработка в Docker
|
|||
---|---|---|---|
#18+
Больше проблем у тех, кто работает над отдельными сервисами, когда их выносишь на хост, вся инфраструктура ломается и надо лазить по сервисам и "переводить стрелки", что какой-то конкретный сервис больше не в инфраструктуре докера начинает работать, а на хосте. ... |
|||
:
Нравится:
Не нравится:
|
|||
13.11.2021, 21:04 |
|
|
start [/forum/topic.php?fid=59&msg=40111444&tid=2120299]: |
0ms |
get settings: |
22ms |
get forum list: |
13ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
46ms |
get topic data: |
10ms |
get forum data: |
3ms |
get page messages: |
511ms |
get tp. blocked users: |
1ms |
others: | 2624ms |
total: | 3238ms |
0 / 0 |