Задать вопрос
@evgeniykhist
Java Solution Architect

Возможно ли простое обновление зависимостей в множестве микросервисов?

Использование общих (shared) библиотек в микросервисах - плохая практика. Но каждый микросервис в любом случае имеет зависимости на фреймворки и библиотеки.  Например, Spring Boot, Kafka Java Client и т.д.

Если система состоит из 30 микросервисов, основанных на Spring Boot и использующих Gradle или Maven в качестве инструмента для сборки и распространяемых в виде Docker образов, существует ли простой способ обновить версию Spring Boot во всех микросервисах? Обновление всех микросервисов одного за другим занимает много усилий. И чем больше микросервисов в системе, тем больше усилий требуется.

Причиной для обновления может быть уязвимость в зависимостях.
Например, Spring Boot 2.2.0.RELEASE зависит от Tomcat 9.0.27, который имеет уязвимость CVE-2020-1938 (уязвимость взята просто в качестве примера). Уязвимость была исправлена ​​в Tomcat 9.0.31, поэтому обновление до Spring Boot 2.2.4.RELEASE решает проблему.

Есть вариант объявить версию Spring Boot в build.gradle как 2.2.+. Но это вносит неопределенность относительно используемых версий, и кто-то все еще должен пересобрать все микросервисы.

Если уязвимость критична, нет времени ждать новой версии Spring Boot с исправлением, и Tomcat должен быть явно обновлен в build.gradle. Или даже заменить на Undertow, что также требует изменений в build.gradle.

Использование  standalone Tomcat вместо встроенного (embdedde) также не очень помогает, поскольку микросервисы распространяются как Docker образы, а не как файлы WAR, которые разворачиваются в Servlet контейнере.

В Java EE обновления безопасности в теории были очень просты. Вы обновляете сервер приложений (например, WildFly) или устанавливаете security patch, и если приложение использует только Java EE API, никаких изменений больше не требуется. Существует ли аналогичная концепция простых обновлений зависимостей для микросервисов (по крайней мере, в теории)?
  • Вопрос задан
  • 424 просмотра
Подписаться 1 Средний Комментировать
Пригласить эксперта
Ответы на вопрос 2
inoise
@inoise
Solution Architect, AWS Certified, Serverless
Добро пожаловать в реальный мир. На самом деле эта проблема совсем не нова. Да, зависимости это удобно, но болезненно и именно поэтому необходимо тестирование, а некоторые организации даже применяют тестирование сторонних компонент на безопасность.

Начинать лечить вашу проблему стоит с того чтобы внедрить CI/CD и получать отчеты об успешных сборках. Тестирование добавите позже. После этого вы поймете что необходимо довольно жестко фиксировать зависимости в проектах, делать форки сторонних библиотек, версионировать свой код в репозитории. Даже API придется со временем версионировать и учиться писать контракты, документацию) Много дополнительной работы, но при этом это все - единственное что держит на плаву проекты, выходящие из песочницы
Ответ написан
@nApoBo3
Собственно говоря изоляция зависимостей одна из причин упаковки приложений в образ.
Если вам это мешает, значит просто вам не следует использовать докер.
Ответ написан
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Похожие вопросы