Всем привет!
Ну и еще одна оптимизация времени старта Java приложения. Самые внимательные уже могли ее заметить пройдя по ссылкам из предыдущего поста.
С момента появления Spring Boot упаковка приложения в fat jar - jar содержащий все зависимости и Tomcat в придачу (или другой контейнер сервлетов) - стала неким стандартом.
Но fat jar при исполнении требуется распаковать. А разархивация всегда требовала времени, не зря архиваторы используются как бенчмарки для процессорных тестов.
Соответственно, можно заранее разложить зависимости по отдельным файлам для ускорения старта. Вот как рекомендует это делать Spring https://docs.spring.io/spring-boot/reference/packaging/efficient.html
Судя по данным статьи из вчерашнего поста это даст еще 25% ускорения при старте https://spring.io/blog/2023/12/04/cds-with-spring-framework-6-1
#performance #spring #jvm #java_start_boost
Ну и еще одна оптимизация времени старта Java приложения. Самые внимательные уже могли ее заметить пройдя по ссылкам из предыдущего поста.
С момента появления Spring Boot упаковка приложения в fat jar - jar содержащий все зависимости и Tomcat в придачу (или другой контейнер сервлетов) - стала неким стандартом.
Но fat jar при исполнении требуется распаковать. А разархивация всегда требовала времени, не зря архиваторы используются как бенчмарки для процессорных тестов.
Соответственно, можно заранее разложить зависимости по отдельным файлам для ускорения старта. Вот как рекомендует это делать Spring https://docs.spring.io/spring-boot/reference/packaging/efficient.html
Судя по данным статьи из вчерашнего поста это даст еще 25% ускорения при старте https://spring.io/blog/2023/12/04/cds-with-spring-framework-6-1
#performance #spring #jvm #java_start_boost
Enterprise Craftsmanship
Domain model purity vs. domain model completeness (DDD Trilemma)
I’ve been meaning to write this article for a long time and, finally, here it is: the topic of domain model purity versus domain model completeness.
Всем привет!
Ну и последний вариант ускорения старта Java приложения. Самый радикальный, наверное. Отказ от Spring.
Надо отметить, что чистый hello world Spring сервис в плане старта не так уж плох, плюс минус 4 секунды. Основные проблемы начинаются с ростом числа зависимостей. И Spring можно тюнить, подробнее про это можно почитать здесь: https://www.baeldung.com/spring-boot-startup-speed Единственный момент, который мне не понравился - я бы не отключал C2 компиляцию - скорость старта может и увеличится, а вот выйти на оптимальную производительность не получится. И еще интересное исследование - https://github.com/dsyer/spring-boot-allocations Авторы выключили в Spring Boot все, за что мы его любим - Dependency Injection и быструю автоконфигурацию, повесили все на единственный classloader и ускорили старт в 5(!) раз. Только зачем нужен такой Spring?)
Но вернемся к отказу от Spring. Писать на голой Java я не предлагаю) Есть две альтернативы - Quarkus и Micronaut. Оба при создании основной целью ставили получить более быстрый и легковесный фреймворк, чем Spring.
Вот сравнительный бенчмарк Quarkus https://habr.com/ru/companies/haulmont/articles/443242/ Ускорение старта простейшего приложения в 5 раз, до 0.75 секунд. Я беру цифры без native image (GraalVM ), т.к. в этом случае и Spring будет "летать". Для интереса я сравнил локально, разница получилась не в 5 раз, а примерно в 2, с 2.5 до 1.2 секунды. За счет чего получилось ускориться можно почитать тут https://dev.to/nutrymaco/how-quarkus-use-build-time-to-start-your-application-faster-50n Если вкратце - Dependency Injection происходит во время достаточно сложного процесса компиляции.
А вот сравнение Micronaut со Spring https://www.baeldung.com/micronaut-vs-spring-boot Разница чуть поменьше, в 2,5 раза, но тоже ничего) Вот тут, авторы объясняют, почему они быстрее Spring - https://guides.micronaut.io/latest/building-a-rest-api-spring-boot-vs-micronaut-data-gradle-java.html И снова - внедрение зависимостей на этапе компиляции, нет рефлексии и создаваемых в runtime прокси.
Почему я назвал этот вариант самым тяжелым - оба фреймворка сильно отличаются от Spring - по используемым аннотациям, по API в целом. Кроме того они не такие зрелые, им порядка 5-6 лет, поэтому там просто меньше функционала.
#performance #spring #quarkus #micronaut #java_start_boost
Ну и последний вариант ускорения старта Java приложения. Самый радикальный, наверное. Отказ от Spring.
Надо отметить, что чистый hello world Spring сервис в плане старта не так уж плох, плюс минус 4 секунды. Основные проблемы начинаются с ростом числа зависимостей. И Spring можно тюнить, подробнее про это можно почитать здесь: https://www.baeldung.com/spring-boot-startup-speed Единственный момент, который мне не понравился - я бы не отключал C2 компиляцию - скорость старта может и увеличится, а вот выйти на оптимальную производительность не получится. И еще интересное исследование - https://github.com/dsyer/spring-boot-allocations Авторы выключили в Spring Boot все, за что мы его любим - Dependency Injection и быструю автоконфигурацию, повесили все на единственный classloader и ускорили старт в 5(!) раз. Только зачем нужен такой Spring?)
Но вернемся к отказу от Spring. Писать на голой Java я не предлагаю) Есть две альтернативы - Quarkus и Micronaut. Оба при создании основной целью ставили получить более быстрый и легковесный фреймворк, чем Spring.
Вот сравнительный бенчмарк Quarkus https://habr.com/ru/companies/haulmont/articles/443242/ Ускорение старта простейшего приложения в 5 раз, до 0.75 секунд. Я беру цифры без native image (GraalVM ), т.к. в этом случае и Spring будет "летать". Для интереса я сравнил локально, разница получилась не в 5 раз, а примерно в 2, с 2.5 до 1.2 секунды. За счет чего получилось ускориться можно почитать тут https://dev.to/nutrymaco/how-quarkus-use-build-time-to-start-your-application-faster-50n Если вкратце - Dependency Injection происходит во время достаточно сложного процесса компиляции.
А вот сравнение Micronaut со Spring https://www.baeldung.com/micronaut-vs-spring-boot Разница чуть поменьше, в 2,5 раза, но тоже ничего) Вот тут, авторы объясняют, почему они быстрее Spring - https://guides.micronaut.io/latest/building-a-rest-api-spring-boot-vs-micronaut-data-gradle-java.html И снова - внедрение зависимостей на этапе компиляции, нет рефлексии и создаваемых в runtime прокси.
Почему я назвал этот вариант самым тяжелым - оба фреймворка сильно отличаются от Spring - по используемым аннотациям, по API в целом. Кроме того они не такие зрелые, им порядка 5-6 лет, поэтому там просто меньше функционала.
#performance #spring #quarkus #micronaut #java_start_boost
Baeldung
Speed up Spring Boot Startup Time | Baeldung
Learn different configurations and setups that can help decrease Spring Boot startup time.
Небольшое дополнение по Java records. Как известно, Java - это огромное количество библиотек и фреймворков и, следовательно, вопросы совместимости.
Так вот. Spring Boot Web записи поддерживает, как в контроллере, так и в http клиентах. Java сериализация естественно, это же часть спецификации Java. Jackson сериализация. Mapstruct. И Spring Data JPA, там где это возможно, учитывая иммутабельность https://www.baeldung.com/spring-jpa-java-records
Что я забыл? Наверное забыл, но 3 года прошло - поддержку должны были уже запилить)
#java #spring
Так вот. Spring Boot Web записи поддерживает, как в контроллере, так и в http клиентах. Java сериализация естественно, это же часть спецификации Java. Jackson сериализация. Mapstruct. И Spring Data JPA, там где это возможно, учитывая иммутабельность https://www.baeldung.com/spring-jpa-java-records
Что я забыл? Наверное забыл, но 3 года прошло - поддержку должны были уже запилить)
#java #spring
Baeldung
Using Java Records with JPA | Baeldung
Learn how we can use records with JPA and Spring Data JPA.
Всем привет!
Небольшое развитие поста про выбор альтернативы IDEA Ultimate.
В посте особое внимание по понятным причинам было обращено на поддержку Spring.
Так вот, благодаря комментариям выяснилось, что в России пилится 3 плагина для Spring:
1) Amplicode https://amplicode.ru/
2) Sber\Giga - назовем его так, т.к. его еще никто не видел
3) Explyt https://github.com/explyt/spring-plugin/wiki/Videos
Последний я изучил по видосам - выглядит неплохо как плагин чисто для Spring. А Amplicode вырывается вперед благодаря поддержке JPA, Liquibase, MapStruct, Docker....
Конкуренция, однако. Вот что импортозамещение делает) Будем наблюдать.
За наводку на Explyt спасибо @alex_inozemtsev
#idea #spring
Небольшое развитие поста про выбор альтернативы IDEA Ultimate.
В посте особое внимание по понятным причинам было обращено на поддержку Spring.
Так вот, благодаря комментариям выяснилось, что в России пилится 3 плагина для Spring:
1) Amplicode https://amplicode.ru/
2) Sber\Giga - назовем его так, т.к. его еще никто не видел
3) Explyt https://github.com/explyt/spring-plugin/wiki/Videos
Последний я изучил по видосам - выглядит неплохо как плагин чисто для Spring. А Amplicode вырывается вперед благодаря поддержке JPA, Liquibase, MapStruct, Docker....
Конкуренция, однако. Вот что импортозамещение делает) Будем наблюдать.
За наводку на Explyt спасибо @alex_inozemtsev
#idea #spring
amplicode.ru
Инструменты разработки веб-приложений | Amplicode
Современные инструменты разработки веб-приложений и сервисов на Spring Boot: надежные инструменты для разработчиков
Всем привет!
Небольшая памятка по созданию бинов в Spring контексте. Рассматриваем Spring Boot приложение.
Что влияет на итоговый набор бинов?
0) база - влияют собственно определенные в сервисе бины.
Я насчитал 5 способов определения бинов в порядке распространнености:
а) Spring annotation-based - через @Component сотоварищи
б) Java-based configuration, причем что интересно - методы @Bean могут быть не только у них, но и у Annotation-based, о разнице можно почитать тут: https://stackoverflow.com/questions/3330618/bean-inside-class-with-configuration-and-without-it
в) старые и уже наверное не добрые xml-based configuration
г) экзотические groovy bean definitions https://docs.spring.io/spring-framework/reference/core/beans/basics.html#beans-factory-groovy
д) Spring понимает JSR 330 (привет от Java EE) аннотации при добавлении соответствующих зависимостей https://docs.spring.io/spring-framework/reference/core/beans/standard-annotations.html
Причем способы можно миксовать, например, добавляя xml и groovy конфигурации через context.loadBeanDefinitions() или @ImportResource.
1) кроме того бины тянутся из подключенных в проекте стартеров, при включенной @AutoConfiguration (или @SpringBootApplication), исключить лишнее можно через параметр exclude
2) корневые пакеты для поиска бинов. По умолчанию он один и равен пакету, где лежит класс с @SpringBootApplication. Может быть переопределен @SpringBootApplication(scanBasePackages = "com.example.myproject"). К слову, @SpringBootApplication под капотом включает в себя @ComponentScan - автоматический поиск бинов.
3) можно не использовать автоматический поиск бинов (@ComponentScan), а собрать их в конфигурации и явно их импортировать через @Import
4) у Spring Data JPA свои настройки корневых пакетов для поиска репозиториев, указываются через @EnableJpaRepositories(basePackages="com.example.myproject")
5) использование профилей Spring при запуске и наличие @Profile в @Configuration и @Component
6) более гибко условное подключение бинов можно сделать через разного рода @Conditional. Это целый пакет аннотаций, бывают условия с SpeL и даже бины, задающие условие c помощью Java кода. Детальнее тут https://www.baeldung.com/spring-boot-annotations
7) можно вклинится в момент, когда метаданные (BeanDefinition) уже созданы, а Bean - еще нет, через создание своего BeanFactoryPostProcessor https://docs.spring.io/spring-framework/reference/core/beans/factory-extension.html#beans-factory-extension-factory-postprocessors
и что-нибудь подшаманить - например, заменить bean.
8) есть печально знаменитая опция allowBeanDefinitionOverriding, позволяющая переопределять бины просто создавая новый бин с тем же интерфейсом позже по времени
9) более предсказуемая, но также не рекомендуемая аннотация @Primary на компоненте, "хардкодящая" главный бин для внедрения
И возможно, я что-то забыл)
Вот такой простой и понятный процесс инициализации бинов. Казалось бы, что может пойти не так?)
Например, это приводит к головной боли у разработчиков плагинов, пытающихся воссоздать Spring context без запуска Spring приложения. Это не так-то легко в первую очередь из-за динамических частей - там где наличие бина определяется в Java коде. Вот хорошая, "с кишочками" статья про решение этой проблемы https://habr.com/ru/companies/explyt/articles/854304/
И выходит, что создатели Spring, увы, не подумали о разработчиках плагинов.
#spring #ide
Небольшая памятка по созданию бинов в Spring контексте. Рассматриваем Spring Boot приложение.
Что влияет на итоговый набор бинов?
0) база - влияют собственно определенные в сервисе бины.
Я насчитал 5 способов определения бинов в порядке распространнености:
а) Spring annotation-based - через @Component сотоварищи
б) Java-based configuration, причем что интересно - методы @Bean могут быть не только у них, но и у Annotation-based, о разнице можно почитать тут: https://stackoverflow.com/questions/3330618/bean-inside-class-with-configuration-and-without-it
в) старые и уже наверное не добрые xml-based configuration
г) экзотические groovy bean definitions https://docs.spring.io/spring-framework/reference/core/beans/basics.html#beans-factory-groovy
д) Spring понимает JSR 330 (привет от Java EE) аннотации при добавлении соответствующих зависимостей https://docs.spring.io/spring-framework/reference/core/beans/standard-annotations.html
Причем способы можно миксовать, например, добавляя xml и groovy конфигурации через context.loadBeanDefinitions() или @ImportResource.
1) кроме того бины тянутся из подключенных в проекте стартеров, при включенной @AutoConfiguration (или @SpringBootApplication), исключить лишнее можно через параметр exclude
2) корневые пакеты для поиска бинов. По умолчанию он один и равен пакету, где лежит класс с @SpringBootApplication. Может быть переопределен @SpringBootApplication(scanBasePackages = "com.example.myproject"). К слову, @SpringBootApplication под капотом включает в себя @ComponentScan - автоматический поиск бинов.
3) можно не использовать автоматический поиск бинов (@ComponentScan), а собрать их в конфигурации и явно их импортировать через @Import
4) у Spring Data JPA свои настройки корневых пакетов для поиска репозиториев, указываются через @EnableJpaRepositories(basePackages="com.example.myproject")
5) использование профилей Spring при запуске и наличие @Profile в @Configuration и @Component
6) более гибко условное подключение бинов можно сделать через разного рода @Conditional. Это целый пакет аннотаций, бывают условия с SpeL и даже бины, задающие условие c помощью Java кода. Детальнее тут https://www.baeldung.com/spring-boot-annotations
7) можно вклинится в момент, когда метаданные (BeanDefinition) уже созданы, а Bean - еще нет, через создание своего BeanFactoryPostProcessor https://docs.spring.io/spring-framework/reference/core/beans/factory-extension.html#beans-factory-extension-factory-postprocessors
и что-нибудь подшаманить - например, заменить bean.
8) есть печально знаменитая опция allowBeanDefinitionOverriding, позволяющая переопределять бины просто создавая новый бин с тем же интерфейсом позже по времени
9) более предсказуемая, но также не рекомендуемая аннотация @Primary на компоненте, "хардкодящая" главный бин для внедрения
И возможно, я что-то забыл)
Вот такой простой и понятный процесс инициализации бинов. Казалось бы, что может пойти не так?)
Например, это приводит к головной боли у разработчиков плагинов, пытающихся воссоздать Spring context без запуска Spring приложения. Это не так-то легко в первую очередь из-за динамических частей - там где наличие бина определяется в Java коде. Вот хорошая, "с кишочками" статья про решение этой проблемы https://habr.com/ru/companies/explyt/articles/854304/
И выходит, что создатели Spring, увы, не подумали о разработчиках плагинов.
#spring #ide
Stack Overflow
@Bean inside class with @Configuration and without it
There is a @Bean annotation in Spring 3.0. It allows to define a Spring bean directly in a Java code. While browsing Spring reference I found two different ways of using this annotation - inside cl...
Всем привет!
Я снова вернулся)
И предновогодний пост будет снова про AI и Java.
Для начала про LLM. Чтобы LLM дала осмысленный ответ - ей нужен правильный промт и побольше контекста. Не даром в новых версиях моделей объем контекста растет - возьмем тот же Gemini с 1 млн токенов.
Но с точки зрения разработки - важен не только объем, но автоматизация работы с контекстом, т.е. некая бизнес-логики. Например, если мы делаем свой агент и у нас несколько источников точных данных, которые мы хотим скормить модели. И эта бизнес-логика скорее всего будет похожая у разных агентов...
LLM - область достаточно молодая, стандарты в ней зарождаются прямо сейчас. Встречайте MCP https://spec.modelcontextprotocol.io/specification/ - сайт стандарта - и https://habr.com/ru/articles/862312/ - интро на русском.
Он стандартизирует в первую очередь транспортное API - клиент и сервер - для работы с источниками точных данных и LLM. Содержит ряд готовых серверов для работы с файловыми данными, СУБД, веб-поиском.
Как это все относится к Java? А вот как: есть Spring AI, уже писал про него https://t.me/javaKotlinDevOps/241 Он дает универсальное API для обращения к различным LLM. Сейчас туда добавили - в статусе experimental - Spring AI MCP https://docs.spring.io/spring-ai/reference/api/model-context-protocol.html
Причем добавили достаточно быстро, хотя до Python конечно же далеко. Вообще поддержка Python, я полагаю, появилась вместе со стандрартом)
P.S. Да, вспоминая Kotlin в названии канала - если посмотреть примеры Spring AI - получите, распишитесь: https://github.com/spring-projects/spring-ai-examples/blob/main/kotlin/
#llm #spring
Я снова вернулся)
И предновогодний пост будет снова про AI и Java.
Для начала про LLM. Чтобы LLM дала осмысленный ответ - ей нужен правильный промт и побольше контекста. Не даром в новых версиях моделей объем контекста растет - возьмем тот же Gemini с 1 млн токенов.
Но с точки зрения разработки - важен не только объем, но автоматизация работы с контекстом, т.е. некая бизнес-логики. Например, если мы делаем свой агент и у нас несколько источников точных данных, которые мы хотим скормить модели. И эта бизнес-логика скорее всего будет похожая у разных агентов...
LLM - область достаточно молодая, стандарты в ней зарождаются прямо сейчас. Встречайте MCP https://spec.modelcontextprotocol.io/specification/ - сайт стандарта - и https://habr.com/ru/articles/862312/ - интро на русском.
Он стандартизирует в первую очередь транспортное API - клиент и сервер - для работы с источниками точных данных и LLM. Содержит ряд готовых серверов для работы с файловыми данными, СУБД, веб-поиском.
Как это все относится к Java? А вот как: есть Spring AI, уже писал про него https://t.me/javaKotlinDevOps/241 Он дает универсальное API для обращения к различным LLM. Сейчас туда добавили - в статусе experimental - Spring AI MCP https://docs.spring.io/spring-ai/reference/api/model-context-protocol.html
Причем добавили достаточно быстро, хотя до Python конечно же далеко. Вообще поддержка Python, я полагаю, появилась вместе со стандрартом)
P.S. Да, вспоминая Kotlin в названии канала - если посмотреть примеры Spring AI - получите, распишитесь: https://github.com/spring-projects/spring-ai-examples/blob/main/kotlin/
#llm #spring
Model Context Protocol
Specification - Model Context Protocol
Всем привет!
Прочитал статью про работу с секретами в Java: https://habr.com/ru/companies/sberbank/articles/870116/
Лично я из статьи подметил три интересных момента:
1) Сейчас много говорят о безопасной разработке. Книги, доклады на конференциях… Что имеем на практике? Вот есть понятная рекомендация — хранить пароли не в String, а в char[]. Так как String — это объект, и его содержимое будет в heap dump до очередной уборки мусора. А уборка мусора проходит в несколько этапов, и принудительно вызвать её мы не можем. А char[] мы можем очистить сразу после использования. Так вот — в статье у нас есть embedded Tomcat, Jersey HTTP client и Hikari pool. Три широко распространённых компонента, требующих секретов при работе. Сколько из них поддерживают передачу секретов в char[]? Увы, только Jersey client. И это уровень фреймворков и библиотек, на бизнес-уровне всё будет ещё хуже.
2) Перегружаемые настройки Spring Cloud, работающие через @RefreshScope и описанные мною ранее, подходят, увы, не всегда. Основная проблема — передача секрета в компоненты, инициализируемые сложно, однократно при старте или некорректно обрабатывающие событие обновления секретов — например, сбрасывающие активные клиентские сессии.
3) Кроме @RefreshScope изобрели ещё два “велосипеда", причём оба в Spring Boot: SSL bundles и Spring Cloud Vault. Первый предназначен для работы с хранилищами сертификатов, второй — для работы с HashiCorp Vault. Оба поддерживают обновление секретов на лету. Все три инструмента взаимодополняют друг друга, хотя и не покрывают 100% кейсов.
#security #spring
Прочитал статью про работу с секретами в Java: https://habr.com/ru/companies/sberbank/articles/870116/
Лично я из статьи подметил три интересных момента:
1) Сейчас много говорят о безопасной разработке. Книги, доклады на конференциях… Что имеем на практике? Вот есть понятная рекомендация — хранить пароли не в String, а в char[]. Так как String — это объект, и его содержимое будет в heap dump до очередной уборки мусора. А уборка мусора проходит в несколько этапов, и принудительно вызвать её мы не можем. А char[] мы можем очистить сразу после использования. Так вот — в статье у нас есть embedded Tomcat, Jersey HTTP client и Hikari pool. Три широко распространённых компонента, требующих секретов при работе. Сколько из них поддерживают передачу секретов в char[]? Увы, только Jersey client. И это уровень фреймворков и библиотек, на бизнес-уровне всё будет ещё хуже.
2) Перегружаемые настройки Spring Cloud, работающие через @RefreshScope и описанные мною ранее, подходят, увы, не всегда. Основная проблема — передача секрета в компоненты, инициализируемые сложно, однократно при старте или некорректно обрабатывающие событие обновления секретов — например, сбрасывающие активные клиентские сессии.
3) Кроме @RefreshScope изобрели ещё два “велосипеда", причём оба в Spring Boot: SSL bundles и Spring Cloud Vault. Первый предназначен для работы с хранилищами сертификатов, второй — для работы с HashiCorp Vault. Оба поддерживают обновление секретов на лету. Все три инструмента взаимодополняют друг друга, хотя и не покрывают 100% кейсов.
#security #spring
Хабр
Секреты в Java-сервисах на Spring: где брать и как обновлять
Привет, Хабр! Меня зовут Андрей Чернов, я Java‑архитектор в СберТехе, где разрабатываю архитектуру микросервисов. Сейчас я расскажу про нюансы работы с секретами в Java‑сервисах...
Всем привет!
Разбираясь с HashiCorp Vault, понял, что многие, как минимум я, недооценивают его. Что такое Vault? В первую очередь — безопасное хранилище секретов. Аутентификация и авторизация, хранение всех данных в зашифрованном виде. Причём до ввода мастер-пароля администратором само приложение не имеет к ним доступа. Это всё понятно.
Но есть ещё киллер-фича: автогенерация секретов. Архитектура Vault оперирует понятием движка (engine) для работы с различными секретами. Рассмотрим, как ротация сделана для разных движков.
Движок для работы с сертификатами — PKI engine — умеет перегенерировать сертификаты с истекающим сроком. Вот документация: https://www.hashicorp.com/blog/certificate-management-with-vault
Database engine умеет создавать «одноразовых» пользователей в СУБД с помощью фичи под названием dynamic secrets: https://www.hashicorp.com/blog/why-we-need-dynamic-secrets. «Одноразовых» — то есть с ограниченным временем жизни, на один типовой сеанс работы с БД. Причём API Vault позволяет продлить время жизни пользователя для синхронизации с временем сессии. Не уверен, что любая БД выдержит такой режим работы, но видится, что эта функция сильно увеличивает безопасность работы с БД. Может возникнуть вопрос — как Vault их создаёт. ANSI SQL — это хорошо, но диалекты отличаются, да и в конкретной компании могут быть свои правила. Тут всё просто — SQL-запрос для создания пользователя и выдача ему необходимых прав создаются администратором Vault. Естественно, нужно задать логин и пароль администратора СУБД, под которым будут выполняться эти запросы. Но кажется, Vault вполне можно считать безопасным местом для их хранения. Больше деталей здесь: https://www.baeldung.com/vault, а в части интеграции со Spring Vault — здесь: https://www.baeldung.com/spring-cloud-vault.
Также есть возможность ротировать пароли доменных пользователей, используя Active Directory engine — см. https://developer.hashicorp.com/vault/docs/secrets/ad.
И обычные пароли: https://www.hashicorp.com/resources/painless-password-rotation-hashicorp-vault. Странно, что для последнего нужен внешний плагин, но такая возможность есть.
Итого: автоматическая ротация секретов и распространение их с помощью Vault Agent (в виде сайдкаров или JAR-библиотек) выглядят крутой фичей в плане безопасности и упрощения работы администраторов. Наверняка на этом пути будут подводные камни, но путь однозначно верный.
#security #vault #spring
Разбираясь с HashiCorp Vault, понял, что многие, как минимум я, недооценивают его. Что такое Vault? В первую очередь — безопасное хранилище секретов. Аутентификация и авторизация, хранение всех данных в зашифрованном виде. Причём до ввода мастер-пароля администратором само приложение не имеет к ним доступа. Это всё понятно.
Но есть ещё киллер-фича: автогенерация секретов. Архитектура Vault оперирует понятием движка (engine) для работы с различными секретами. Рассмотрим, как ротация сделана для разных движков.
Движок для работы с сертификатами — PKI engine — умеет перегенерировать сертификаты с истекающим сроком. Вот документация: https://www.hashicorp.com/blog/certificate-management-with-vault
Database engine умеет создавать «одноразовых» пользователей в СУБД с помощью фичи под названием dynamic secrets: https://www.hashicorp.com/blog/why-we-need-dynamic-secrets. «Одноразовых» — то есть с ограниченным временем жизни, на один типовой сеанс работы с БД. Причём API Vault позволяет продлить время жизни пользователя для синхронизации с временем сессии. Не уверен, что любая БД выдержит такой режим работы, но видится, что эта функция сильно увеличивает безопасность работы с БД. Может возникнуть вопрос — как Vault их создаёт. ANSI SQL — это хорошо, но диалекты отличаются, да и в конкретной компании могут быть свои правила. Тут всё просто — SQL-запрос для создания пользователя и выдача ему необходимых прав создаются администратором Vault. Естественно, нужно задать логин и пароль администратора СУБД, под которым будут выполняться эти запросы. Но кажется, Vault вполне можно считать безопасным местом для их хранения. Больше деталей здесь: https://www.baeldung.com/vault, а в части интеграции со Spring Vault — здесь: https://www.baeldung.com/spring-cloud-vault.
Также есть возможность ротировать пароли доменных пользователей, используя Active Directory engine — см. https://developer.hashicorp.com/vault/docs/secrets/ad.
И обычные пароли: https://www.hashicorp.com/resources/painless-password-rotation-hashicorp-vault. Странно, что для последнего нужен внешний плагин, но такая возможность есть.
Итого: автоматическая ротация секретов и распространение их с помощью Vault Agent (в виде сайдкаров или JAR-библиотек) выглядят крутой фичей в плане безопасности и упрощения работы администраторов. Наверняка на этом пути будут подводные камни, но путь однозначно верный.
#security #vault #spring
HashiCorp
X.509 certificate management with Vault
In this blog post, we’ll look at practical public key certificate management in HashiCorp Vault using dynamic secrets rotation.
Всем привет!
Не отпускает меня тема AI)
Напомню, что с одной стороны AI ~= Python, но с другой стороны Java потихоньку подтягивается, о чем я уже писал на канале, см. по тегам.
Вот отличный пример генерации данных с помощью AI с запоминанием контекста на Spring AI https://piotrminkowski.com/2025/01/28/getting-started-with-spring-ai-and-chat-model/
Обратите внимание на "магию" Spring - в части преобразования ответа модели в коллекцию.
А вот тут https://piotrminkowski.com/2025/01/30/getting-started-with-spring-ai-function-calling/
на "магию" привязки функций, забирающих данные из API брокера и с сервиса-поставщика биржевой информации к вызову модели.
Красиво, черт возьми!)
P.S. Интересно, учитывая недетерминистическое поведение модели - всегда ли эта магия работает. Буду проверять)
#ai #java #spring
Не отпускает меня тема AI)
Напомню, что с одной стороны AI ~= Python, но с другой стороны Java потихоньку подтягивается, о чем я уже писал на канале, см. по тегам.
Вот отличный пример генерации данных с помощью AI с запоминанием контекста на Spring AI https://piotrminkowski.com/2025/01/28/getting-started-with-spring-ai-and-chat-model/
Обратите внимание на "магию" Spring - в части преобразования ответа модели в коллекцию.
А вот тут https://piotrminkowski.com/2025/01/30/getting-started-with-spring-ai-function-calling/
на "магию" привязки функций, забирающих данные из API брокера и с сервиса-поставщика биржевой информации к вызову модели.
Красиво, черт возьми!)
P.S. Интересно, учитывая недетерминистическое поведение модели - всегда ли эта магия работает. Буду проверять)
#ai #java #spring
Piotr's TechBlog
Getting Started with Spring AI and Chat Model - Piotr's TechBlog
This article will teach you how to use the Spring AI project to build applications based on different chat models.
Не Spring-ом единым...
Появилась еще одна библиотека для Java для работы с LLM, а точнее конкретно с OpenAI. Официальная, от OpenAI
<dependency>
<groupId>com.openai</groupId>
<artifactId>openai-java</artifactId>
<version>0.22.0</version>
</dependency>
На что хотелось бы обратить внимание:
1) OpenAI наконец то "дошла" до Java разработчиков
2) Разработчики библиотеки очень любят method chaining (ссылка на статью с примерами в конце поста). Со стороны даже кажется, что череcчур, можно было бы и по-короче инициализировать библиотеку
3) есть поддержка web-поиска
4) есть неочевидное разделение на Completion API - простые вопросы к LLM, типа "как на Java получить список файлов в каталоге" и Assistants API - "напиши мне микросервис, возвращающий курсы акций на бирже". Почему неочевидное - в моделях я вижу обратную тенденцию к унификации, когда одна модель используется для всех типов задач.
5) Assistants API умеет в File Search и Code Interpreter
И небольшой каталог решений по работе с LLM на Java:
1) Spring AI - https://docs.spring.io/spring-ai/reference
Примеры использования:
hello world https://habr.com/ru/articles/784128/
Более сложные примеры
https://piotrminkowski.com/2025/01/28/getting-started-with-spring-ai-and-chat-model/
https://piotrminkowski.com/2025/01/30/getting-started-with-spring-ai-function-calling/
Telegram bot, OpenAI и Spring AI https://habr.com/ru/companies/dockhost/articles/884876/
2) langchain4j https://github.com/langchain4j/langchain4j Характерно, что проект сделан на основе одноименной Python библиотеки. Поддерживается в Quarkus https://www.baeldung.com/java-quarkus-langchain4j
3) прямая интеграция с OpenAI https://www.baeldung.com/java-openai-api-client
P.S. Возможно Assistants API "жрет" больше токенов, отсюда и разделение
#llm #openai #ai #spring
Появилась еще одна библиотека для Java для работы с LLM, а точнее конкретно с OpenAI. Официальная, от OpenAI
<dependency>
<groupId>com.openai</groupId>
<artifactId>openai-java</artifactId>
<version>0.22.0</version>
</dependency>
На что хотелось бы обратить внимание:
1) OpenAI наконец то "дошла" до Java разработчиков
2) Разработчики библиотеки очень любят method chaining (ссылка на статью с примерами в конце поста). Со стороны даже кажется, что череcчур, можно было бы и по-короче инициализировать библиотеку
3) есть поддержка web-поиска
4) есть неочевидное разделение на Completion API - простые вопросы к LLM, типа "как на Java получить список файлов в каталоге" и Assistants API - "напиши мне микросервис, возвращающий курсы акций на бирже". Почему неочевидное - в моделях я вижу обратную тенденцию к унификации, когда одна модель используется для всех типов задач.
5) Assistants API умеет в File Search и Code Interpreter
И небольшой каталог решений по работе с LLM на Java:
1) Spring AI - https://docs.spring.io/spring-ai/reference
Примеры использования:
hello world https://habr.com/ru/articles/784128/
Более сложные примеры
https://piotrminkowski.com/2025/01/28/getting-started-with-spring-ai-and-chat-model/
https://piotrminkowski.com/2025/01/30/getting-started-with-spring-ai-function-calling/
Telegram bot, OpenAI и Spring AI https://habr.com/ru/companies/dockhost/articles/884876/
2) langchain4j https://github.com/langchain4j/langchain4j Характерно, что проект сделан на основе одноименной Python библиотеки. Поддерживается в Quarkus https://www.baeldung.com/java-quarkus-langchain4j
3) прямая интеграция с OpenAI https://www.baeldung.com/java-openai-api-client
P.S. Возможно Assistants API "жрет" больше токенов, отсюда и разделение
#llm #openai #ai #spring
Хабр
ChatGPT на Java. Пишем «Hello World» на Spring AI
В преддверии Нового Года, начинаем осваивать генеративные сети с помощью привычного всем Java разработчикам фреймворка Spring. Несколько месяцев назад в Spring добавили модуль AI , который упрощает...
Тут мы включаем асинхронное выполнение событий. Операции выполняются в разных транзакциях и в разных потоках.
Все варианты имеют право на жизнь, главное не забывать как работает Spring Events. Ну и если у нас есть "дешевые" транзации на БД (дешевые по сравнению с распределенными транзакциями), то имеет смысл использовать их по максимуму.
P.S. Что интересно, статья с baeldung.com по запросу Spring Events ранжируется выше официальной документации.
#spring #transactions #event_driven
Все варианты имеют право на жизнь, главное не забывать как работает Spring Events. Ну и если у нас есть "дешевые" транзации на БД (дешевые по сравнению с распределенными транзакциями), то имеет смысл использовать их по максимуму.
P.S. Что интересно, статья с baeldung.com по запросу Spring Events ранжируется выше официальной документации.
#spring #transactions #event_driven
Baeldung
Spring Events | Baeldung
The Basics of Events in Spring - create a simple, custom Event, publish it and handle it in a listener.