У образа около 5к загрузок, подскажите, как у него с поддержкой и обновлениями? Потенциально может быть хорошей альтернативой скажем adoptopenjdk/openjdk11:alpine-jre.
Касательно мониторинга (предполагая что все это запущено в kubernetes): для метрик приложения (память, CPU) я бы вытаскивал их из подов при помощи heapster/grafana/influxdb, для бизнес метрик я бы строил дашборды на кибане используя elastic-stack. Оба подхода можно подключить используя daemonsets что позволит избежать изменений в самих сервисах и приложениях. Как вы верно заметили, ограничение этих подходов в том что JVM метрики мы не собираем.
Во многих случаях аномольно большое использование CPU либо памяти привлечет внимание, но вы правы, может понадобится больше диагностической информации, в часности о JVM.
Если я верно понимаю ваш вопрос, то k8s jobs хорошой подойдут для переодически запускаемых задач с фиксированным интервалом. Jenkins позволит создавать slave только когда обнаружено изменение в VCS либо сборка запущена вручную. Основным преймуществом этого подхода является то что slaves существуют только во время сборки, а не все время ожидая начало новой задачи.
Вы правы, но тогда необходимо каждый раз перед коммитом менять версию вручную (либо автоматизировать) иначе потеряется CD составляющая и не каждый коммит будет попадать на staging.
Если же CD часть не важна, то можно настроить пайплайн на создание образа если комит помечен git тегом с паттерном соответствующим semver. В таком случае не понадобится проверка на перезапись, не нужно менять что-то в коде перед релизом, а так же можно релизить любой коммит из прошлого.
Касательно мониторинга (предполагая что все это запущено в kubernetes): для метрик приложения (память, CPU) я бы вытаскивал их из подов при помощи heapster/grafana/influxdb, для бизнес метрик я бы строил дашборды на кибане используя elastic-stack. Оба подхода можно подключить используя daemonsets что позволит избежать изменений в самих сервисах и приложениях. Как вы верно заметили, ограничение этих подходов в том что JVM метрики мы не собираем.
Во многих случаях аномольно большое использование CPU либо памяти привлечет внимание, но вы правы, может понадобится больше диагностической информации, в часности о JVM.
Эта функциональность реализована в kubernetes-plugin.
Если я верно понимаю ваш вопрос, то k8s jobs хорошой подойдут для переодически запускаемых задач с фиксированным интервалом. Jenkins позволит создавать slave только когда обнаружено изменение в VCS либо сборка запущена вручную. Основным преймуществом этого подхода является то что slaves существуют только во время сборки, а не все время ожидая начало новой задачи.
Если же CD часть не важна, то можно настроить пайплайн на создание образа если комит помечен git тегом с паттерном соответствующим semver. В таком случае не понадобится проверка на перезапись, не нужно менять что-то в коде перед релизом, а так же можно релизить любой коммит из прошлого.