Comments 13
А в вашем получившемся образе, смотрю, отсутствуют даже самые базовые диагностические утилиты вроде
jstack и jmap. Или вы не мониторите и не профилируете приложения в продакшне?
Касательно мониторинга (предполагая что все это запущено в kubernetes): для метрик приложения (память, CPU) я бы вытаскивал их из подов при помощи heapster/grafana/influxdb, для бизнес метрик я бы строил дашборды на кибане используя elastic-stack. Оба подхода можно подключить используя daemonsets что позволит избежать изменений в самих сервисах и приложениях. Как вы верно заметили, ограничение этих подходов в том что JVM метрики мы не собираем.
Во многих случаях аномольно большое использование CPU либо памяти привлечет внимание, но вы правы, может понадобится больше диагностической информации, в часности о JVM.
подскажите, как у него с поддержкой и обновлениямиЛучше, чем у кого-либо, насколько мне известно. Впрочем, не хочу заниматься рекламой, пусть лучше alexbel сам обо всём расскажет :)
Я инжектил в jvm jmx exporter, дальше вытащить инфу на уровень кластера и в прометеус не проблема.
Я использую этот как базовый: https://hub.docker.com/r/bellsoft/liberica-openjdk-alpine-musl
Ту версию, что по умолчанию (лайт, 100 мб). Spring boot 2, постгря/оракл, полёт нормальный.
Просто тут я наблюдаю ту же историю, что и с Python — чем больше модулей использует приложение — тем меньше выигрыш от кастомного образа. Насколько действительно образ 422МБ хуже, чем 144МБ? Может проблема в голове разработчика? Потому что снижая размер образа он усложняет процесс сборки и поддержки (нужно внимательно следить за тем, какие зависимости нужно в образ докинуть, чтобы приложение запустилось). Т.е. все-таки каков экономический эффект от уменьшения размера? Кто сможет объяснить?
- запустить приложение: решают одинаково, при условии что мы протестировали и приложение запускается
- простота сборки: меньший образ хуже так как его сложнее приготовить
- колличество денег что компания заработает: вероятно тоже не влияет
- security: возможно лучше иметь только то что необходимо и изолировать себя опасности от того что не нужно, но есть в образе
- скорость запуска на новой ноде k8s которая была только что создана на aws spot instance: меньший образ, вероятно, загрузится быстрее
Я только с последним пунктом согласен. Но и то не факт, т.к. общие слои уже почти наверняка лежат в кэше на ноде кубера. Если, конечно, базовый образ не поменялся. И это не зависит от политики скачивания (Always Pull Policy — оно ес-но кэш не отключает).
По безопасности — тоже как бы не сильно видно профита. Ну, будет не 20 компонентов в образе, а 10. Все равно строить пайплайн проверки образов на уязвимости. Да, конечно, в случае, если в 20-м модуле, который не используется найдена уязвимость, то мелкий образ (который на 10 нужных) без него пересобирать не придется. Но это спорное преимущество.
Не уверен насчет JDK custom runtime, но у него много других преимуществ. Например он складывает внешние библиотеки, код приложения и ресурсы приложения в разные слои. Поэтому размер обновления, т.е. слоя который по факту нужно скачать на сервере, обычно равен размеру вашего кода.
Уменьшение размера docker образа с spring boot приложением