Комментарии 38
А можно сделать jvm образ без OS?
В смысле образ jvm для OS Linux, без привязки к какому-то дистрибутиву
Не получится работать образу без дистрибутива ОС
Это не совсем так. Go приложения могут работать на scratch (нулевом) образе, то есть без дистрибутива совсем. Однако, JVM, в отличие от Go, требует libc, так что совсем без "системных файлов" не выйдет и, опять-таки, собрать образ с минимально необходимым списком файлов тоже можно, но в итоге это получается достаточно муторная работа, которая в случае с рассматриваемым вариантом базирования на Alpine Linux даст выигрыш в < 5МБ при том, что урезанная Oracle JDK весит ~160МБ, а полная — ~340МБ.
она и не привязана к ОС — использует минимальный docker-образ
например так — выбрана конкретная версия JVM и указана в качестве ОС Debian Jessie
Отличная статья для начинающих.
Не могли бы Вы еще осветить момент с открытием доступа извне по JMX к JVM внутри контейнера при условии что на хосте может быть запущено много таких контейнеров и хардкодить порты (com.sun.management.jmxremote.port + expose + маппинг через -p) для каждого контейнера не вариант (т.к. запускаются динамически из orchestration tool)
а JMX/RMI реализация требует чтобы порт в контейнере и на хосте совпадали
Не могли бы Вы еще осветить момент с открытием доступа извне по JMX к JVM внутри контейнера при условии что на хосте может быть запущено много таких контейнеров и хардкодить порты (com.sun.management.jmxremote.port + expose + маппинг через -p) для каждого контейнера не вариант (т.к. запускаются динамически из orchestration tool)
а JMX/RMI реализация требует чтобы порт в контейнере и на хосте совпадали
Контейнеры сами могут отправлять например в Elasticsearch.
Кстати, как самое простое решение — парсинг вывода docker ps для каждого контейнера с динамическими портами (-P) и определение мэпинга заранее известного jmx порта контейнера на динамический порта хост-машины.
такой вариант не работает из-за особенностей реализации JMX/RMI протокола. Именно поэтому я просил осветить данній момент. Реализация требует чтобы порт переданный на старте JVM (Dcom.sun.management.jmxremote.port), порт внутри контейнера и порт снаружи на хосте имели одно и то же значение. Иначе не работает. И получается что либо
— порт надо статически хардкодить при каждом запуске контейнера — что есть проблема при запуске контейнера динамически в облаке
— порт снаружи хоста нужно знать до старта JVM в контейнере и передавать его в контейнер как параметр, чтобы сделать expose и передать в Dcom.sun.management.jmxremote.port
оба варианта не очень…
я не силен в джаве, может есть возможность запуска в контейнере промежуточного компонента который бы работал внутри контейнера с JVM по одному порту а наружу отдавал по другому.
— порт надо статически хардкодить при каждом запуске контейнера — что есть проблема при запуске контейнера динамически в облаке
— порт снаружи хоста нужно знать до старта JVM в контейнере и передавать его в контейнер как параметр, чтобы сделать expose и передать в Dcom.sun.management.jmxremote.port
оба варианта не очень…
я не силен в джаве, может есть возможность запуска в контейнере промежуточного компонента который бы работал внутри контейнера с JVM по одному порту а наружу отдавал по другому.
Честно — не сталкивался с такой потребностью и такой проблемой. Раз не устраивает агент+приложение в контейнере, который дампит стектрейсы/кучу на VOLUME.
Что если VPN между контейнерами и тем хостом откуда пытаетесь все профилировать?
Что если VPN между контейнерами и тем хостом откуда пытаетесь все профилировать?
VPN как вариант, спасибо за подсказку. Попробую сегодня.
Не подскажите ключевые слова для гугления по теме «агент+приложение в контейнере, который дампит стектрейсы/кучу на VOLUME»?
Не подскажите ключевые слова для гугления по теме «агент+приложение в контейнере, который дампит стектрейсы/кучу на VOLUME»?
Если можете профилировать все без контейнеров и локально, то лучше делайте так!
Но если хотите сложностей, то я бы сделал так:
Например, используя jvm-tools -> stcap — семплирующий профайлер, с компактным форматом дампов стектрейсов.
Heap dump элементарно получаем через JMX в том же контейнере. Даже без JMX можно сделать то же самое, если запустить команду jcmd в том же контейнере от того же пользователя что и jvm.
И в том и в другом случае вам нужно указать путь в локальной файловой системе контейнера, куда будут записываться семплы и хипдамп. Этот же путь, вы должны указать в секции VOLUME, при создании контейнера.
А при запуске контейнера указать какой директории контейнера соответствует директория хост-машины.
Но если хотите сложностей, то я бы сделал так:
Например, используя jvm-tools -> stcap — семплирующий профайлер, с компактным форматом дампов стектрейсов.
Heap dump элементарно получаем через JMX в том же контейнере. Даже без JMX можно сделать то же самое, если запустить команду jcmd в том же контейнере от того же пользователя что и jvm.
И в том и в другом случае вам нужно указать путь в локальной файловой системе контейнера, куда будут записываться семплы и хипдамп. Этот же путь, вы должны указать в секции VOLUME, при создании контейнера.
А при запуске контейнера указать какой директории контейнера соответствует директория хост-машины.
я сложности не люблю :)) но у нас так построен процесс разработки. Все JVM микросервисы работают в контейнере которые живут в облаке. Код пишут и не тестируют на производительность одни, а troubleshoot на продакшене делают другие (в данном случае я). И мне приходится брать VisualVM и на живом проде разбираться чего тормозит.
нагуглил такое решение — https://github.com/OlegIlyenko/jmx-firewall-friendly-agent Вроде все работает.
Спасибо за ссылку на https://github.com/aragozin/jvm-tools
очень полезный набор для анализа работающей JVM
нагуглил такое решение — https://github.com/OlegIlyenko/jmx-firewall-friendly-agent Вроде все работает.
Спасибо за ссылку на https://github.com/aragozin/jvm-tools
очень полезный набор для анализа работающей JVM
Ещё как вариант: http://hawt.io/ + https://jolokia.org/agent/jvm.html
Вроде бы lkzcgfvf пытался объяснить для чего требуется JMX/RMI. Вариант про агент в контейнере я предлагал и это не подошло. jolokia — это JMX/HTTP
JMX нужен не метрики или логить снимать, а профайлить приложение, делать дамп
Я имел в виду нечто похожее на agent-bond, (binary)
Ничто не мешает объединить агент профайлера и приложение в одном контейнере и размещать собранную информацию либо по одному из путей VOLUME, либо отдавать ее другому контейнеру по p2p протоколу, например.
Собирать профайлинг семплингом можно, в том числе с помощью jvm-tools -> stcap
Ничто не мешает объединить агент профайлера и приложение в одном контейнере и размещать собранную информацию либо по одному из путей VOLUME, либо отдавать ее другому контейнеру по p2p протоколу, например.
Собирать профайлинг семплингом можно, в том числе с помощью jvm-tools -> stcap
А почему jmx не подходит для снятия метрик?
я наверное неправильно выразил свою мысль. JMX прекрасно подходит для снятия метрик, просто нам он нужен не для этих целей. У нас задача другая — когда на продакшене чтото происходит с производительностью приложения — надо разобраться какая часть тормозит и почему. в 90% случаев хватает подключиться к JVM используя VisualVM и запустить его сэмплер.
Спасибо. Какраз сегодная строили…
Вроде можно на стадии сборки добавить и корпоративный корневой сертификат так как keytool сохранен. Завтра будем пробовать…
Это позволит доверять SSL/ соединениям к серверма подпоисаным корневиком.
Но вот не придумали еще как быть с серверным сертификатом для SSL/TLS.
Ны портируем готовое приложение в облако…
Раньше сертификаты сервера устанавливались на машину а ява приложению просто передавался путь на кейстор, както-так.
А теперь все будет динамичнее, и не хочется вводить привязку к хосту в принципе.
Не совсем еще понятно куда класть сертфикаты сервера, особенно с учетом того что один и тот-же докер-имидж хочется тестировать на дев-энвайроменте и в продекшне…
Один из радикальных вариантов это запекать оба сертификата в Docker image и подставлять в зависимости от конфиги (дев, прод).
Другой вариант куда-то стучаться из стартующего контейнера шелскриптом перед запуском javы что-бы то куда постучались вернуло нужный серверный сертификат и ключ и он был положен в нужно еместо перед запуском апликухи…
Вот такие две версии крутятся. Может у вас есть опыт или идеи?
Вроде можно на стадии сборки добавить и корпоративный корневой сертификат так как keytool сохранен. Завтра будем пробовать…
Это позволит доверять SSL/ соединениям к серверма подпоисаным корневиком.
Но вот не придумали еще как быть с серверным сертификатом для SSL/TLS.
Ны портируем готовое приложение в облако…
Раньше сертификаты сервера устанавливались на машину а ява приложению просто передавался путь на кейстор, както-так.
А теперь все будет динамичнее, и не хочется вводить привязку к хосту в принципе.
Не совсем еще понятно куда класть сертфикаты сервера, особенно с учетом того что один и тот-же докер-имидж хочется тестировать на дев-энвайроменте и в продекшне…
Один из радикальных вариантов это запекать оба сертификата в Docker image и подставлять в зависимости от конфиги (дев, прод).
Другой вариант куда-то стучаться из стартующего контейнера шелскриптом перед запуском javы что-бы то куда постучались вернуло нужный серверный сертификат и ключ и он был положен в нужно еместо перед запуском апликухи…
Вот такие две версии крутятся. Может у вас есть опыт или идеи?
Или поставить перед docker nginx и пусть он только и знает о хостах и сертификатах
Я бы копировал в контейнере сертификат перед стартом приложения из mount point указанной в VOLUMES. Соответственно при старте контейнера в dev окружении передавал бы директорию с dev сертификатом, а при prod с директорию с prod сертификатом.
Это интереснее в определенный сценариях это ок.
Но мы планиеруем на будущее и как можно меньше хочется полагаться на информацию с хостов и провизионировать туда…
Если использовать какой-нибудь kubernetes или у нас в данном случае AWS ECS то размещением контейнеров на хостах занимается scheduler
Поэтому краткосрочно мы решим это с привязкой к хосту или переменной. Но в дальнешем похоже надо будет написать клиент который будет забирать себе сертефикат и прочее откуда-нибудь…
Но мы планиеруем на будущее и как можно меньше хочется полагаться на информацию с хостов и провизионировать туда…
Если использовать какой-нибудь kubernetes или у нас в данном случае AWS ECS то размещением контейнеров на хостах занимается scheduler
Поэтому краткосрочно мы решим это с привязкой к хосту или переменной. Но в дальнешем похоже надо будет написать клиент который будет забирать себе сертефикат и прочее откуда-нибудь…
Еще проще не копировать, а создавать линк. Не думаю что с mount для контейнера в таких инфраструктурах есть проблемы.
Караз есть, если все совать в контенеры, то глупо полагаться на то что контеенер приземлится на определенной машине…
Более того имеет смысл использовать систему абстрагированую в принципе от маунтингда чего либо к одному хосту… в облаках это не делают…
Представьте что у вас 1000 > контейнеров
Но переде тем как переписать всю апплику хотелось найти что-то быстрое по середине как компромис. Пока у нас 3 контейнера, на след. неделе будет 7.
В перспективе >200 в этом году.
Более того имеет смысл использовать систему абстрагированую в принципе от маунтингда чего либо к одному хосту… в облаках это не делают…
Представьте что у вас 1000 > контейнеров
Но переде тем как переписать всю апплику хотелось найти что-то быстрое по середине как компромис. Пока у нас 3 контейнера, на след. неделе будет 7.
В перспективе >200 в этом году.
Я бы предложил использовать что-то из openjdk.
Oracle так просто не разрешает распространять его продукты, если пользователь не принимает лицензию самостоятельно. И в данном случае Oracle предоставляет только openjdk образ, но не свой. Так что могут быть проблемы с лицензией.
Собрать свой образ с java или oracle-xe у себя дома и пользоваться — можно. Распространять — скорее нет (если ответ короткий).
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Упаковка jvm приложения в docker образ