сезонаторspringyПодскажите куда можно посмотреть?docker-composeесть мнение, что докером нужно пользоваться только когда уже совсем невмоготу (на например в CI запускать пару десятков сборок одновременно), а изначально сам ЖЦ мэйвена должен работать прозрачно без каких-либо костылей в виде докера, в противном случае поддерживать комбайны крайне затруднительно (накрапать нетленку-то не сложно, а вот когда другому разработчику придется отладиться у себя, вот тогда наступает грусть и печаль). В целом для генерации конфигов и рассовывания их куда нужно вполне достаточно двух плагинов: maven resources и maven dependency.

andreykaTу тебя с десяток микросервисов. как их адекватно развернуть без докера? ну.. можно не спорю. но несколько неудобно.Вообще проблемы нет никакой, и не нужно преклоняться перед докером, единственный его профит в обсуждаемом вопросе - это то, что в сервисе мы можем захардкодить эндпойнты как service_name:default_port, а изоляцию портов и разрешение имен отдать на откуп докеру (пусть контейнеры с --link запускает), однако:
никто не мешает генерировать конфиги сервисов через maven resources plugin и раскидывать конфиги через maven dependency plugin

это может быть конечно сюрпризом, но tcp-портов с одним и тем же номером на машине аж 16 миллионов, так что даже здесь мудрить особо-то и не нужно:

andreykaT,

мне откровенно не нравится базовая концепция того, что контейнер нужно настоятельно рекомендуется запускать с --rm и, соответственно, никакие данные в нем не держать, как только начинаешь нарушать эту концепцию ("там всякие разные конфигурации стандартных инструментов"), то сразу всплывают всякого рода грабли, а именно:
- среда в контейнере не особо полноценная: помимо того что туда инструментарий нужный не ставят еще умудряются запихивать порезанный alpine linux - так что в большинстве случаев приходится самому все собирать, последний трешак, который наблюдал: в официальным образе Oracle EE не включена partitioning option - хотите включить? собирайте образ сами, ибо $ORACLE_HOME тоже порезанный
- тема про volumes понятна, но выглядит несколько неэстетично: контейнеры где-то сами по себе, данные сами по себе, а потом пойди и угадай что от чего и нужно оно вообще или нет - с виртуальными машинами порядка больше (ровно как и в первой претензии)
- сетевой стэк сделан неудобно для рядового пользователя (хотите чтобы контейнеры были доступны по сети без порт маппинга? добро пожаловать в ад), а где-то даже и глючно (вот оно вставляет в iptables правила, основанные на connection tracking, а потом удивляешься почему долгоживущие коннекты начинают рваться)
- управление ресурсами тоже так себе, т.е. контейнер-то мы можем ограничить по памяти и CPU, однако софтина, которая в нем крутится видит все ресурсы хоста, из-за чего принимает неверные решения для себя, ну самый простой пример - java, там умолчательный размер кучи и количество потоков GC определяются на основе хоста, поэтому приходится перенастраивать всегда
- что еще удивляет: оно почему-то внутри себя overlayfs умеет, а снаружи нет, вот условно хочу в докере mvn запускать и чтобы оно не тупило постоянно на скачивании артефактов, что делать? нужно хостовый ~/.m2 подключать, а что делать если я еще не хочу чтобы оно в хостовый ~/.m2 гадило? контейнер переделывать и постоянно в нем ~/.m2 обновлять.

По вполне объективным причинам оказалось гораздо удобнее купить нормальный десктоп и гонять в нем vmware, чем постоянно бороться с неудобствами докера. Меж тем:
- существование докера в продакшене - вполне нормальная концепция, однако при условии что для этого продакшена мы в итоге собираем готовые образы, а не так, что сборка и тестирование живет само по себе без докера, а в продакшн какие-то умельцы что-то там закатывают в докер
- использование докера в CI/CD тоже нормальная концепция (особенно если мы хотит чтобы злодеи нам какой-нить rm -rf / не закоммитили), но это не значит что вот нужно все бросать и начинать делать сборки в докере: сборка должна и без докера правильно работать