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

Question

[Евгений]

Использование общих (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, никаких изменений больше не требуется. Существует ли аналогичная концепция простых обновлений зависимостей для микросервисов (по крайней мере, в теории)?

Answer 1

[Иван Шумов]

Добро пожаловать в реальный мир. На самом деле эта проблема совсем не нова. Да, зависимости это удобно, но болезненно и именно поэтому необходимо тестирование, а некоторые организации даже применяют тестирование сторонних компонент на безопасность.

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

Comments

[Евгений]

Ответ хороший, мудрый, но вообще не имеет отношения к вопросу. Есть 30, 50, 100 микросервисов. Все на основе Spring Boot. Надо обновить версию Spring Boot во всех сервисах по какой-то причине. Существует подход, позволяющий сэкономить усилия по сравнению с обновлением всех микросервисов одного за другим?

[Иван Шумов]

Евгений, если это мажорное обновление с нарушением обратной совместимости, то нет. Если без нарушений обратно совместимости то это должно происходить автоматически в ci/cd на моменте сборки

[Евгений]

Как и указано в примере в вопросе: с версии 2.2.0.RELEASE на 2.2.4.RELEASE. "Должно происходить автоматически". Как и указано в вопросе, этого можно добиться используя Gradle и указывая версию как 2.2.+. Ответ или комментарий будет ценным, если рассказать как еще это может происходить автоматически.

[Иван Шумов]

Евгений, что мешает делать 2.+?

[Евгений]

Для обновления с 2.2.0.RELEASE на 2.2.4.RELEASE нет смысла указывать как 2.+. Достаточно 2.2.+.

[Иван Шумов]

Евгений, каюсь, был не внимателен. Теперь вернемся к вопросу основательно. Если в gradle установлено верно то поставит он самую свежую версию из возможных, поэтому вопрос с чем связан? перебрать все образы? затеплоить их заново?

[Евгений]

Такой подход рабочий. Но то, что не контролируешь версии, а отдаешь это Gradle, немного смущает. Интересно услышать мнение и опыт других людей. Из альтернативных идей - передавать версию через gradle.properties (spring.version=2.2.4.RELEASE), который будет как-то монтироваться на Jenkins.

[Иван Шумов]

Евгений, идея одновременно хорошая и ужасная. Если хочется контроля то прибиваем версии гвоздями, но этот подход на масштабе обречен на провал. Пишите тесты чтобы спать спокойно что новый бил на новой версии рабочий

Answer 2

[nApoBo3]

Собственно говоря изоляция зависимостей одна из причин упаковки приложений в образ.
Если вам это мешает, значит просто вам не следует использовать докер.

Comments

[Евгений]

Думаю, я не единственный, кто строит микросервисы на базе Spring Boot. И время от времени хочет обновить версию Spring Boot. Без Docker проблематично деплоить микросервисы в Kubernetes кластер.

[Иван Шумов]

Евгений, Докер это хороший подход, жаль только что k8s ужасен