Рубрики
Без рубрики

Весенняя загрузка: Настройка свойств

В этом руководстве мы рассмотрим настройку свойств Spring Boot с помощью файлов свойств и значений.

Автор оригинала: Dhananjay Singh.

Вступление

В этой статье мы рассмотрим Настройку свойств загрузки Spring .

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

Существует несколько способов настройки проекта Spring:

  • На основе Java
  • На основе XML
  • На основе свойств

Конфигурация свойств на основе Java и XML была классическим способом настройки приложений Spring до того, как Spring Boot представила нам файл application.properties .

Это дополнение позволяет нам внешне настраивать приложение и легко получать доступ к свойствам, определенным в файле.

По умолчанию файл application.properties можно использовать для хранения пар свойств, хотя вы также можете определить любое количество дополнительных файлов свойств.

Чтобы зарегистрировать файл свойств, вы можете аннотировать класс @Configuration с помощью дополнительной @PropertySource аннотации:

@Configuration
@PropertySource("classpath:custom.properties")
public class ConfigClass {
// Configuration
}

Используя этот метод, вы можете зарегистрировать любое количество дополнительных файлов .properties :

@Configuration
@PropertySource("classpath:custom.properties")
@PropertySource("classpath:another.properties")
public class ConfigClass {
// Configuration
}

Впрыскивание Свойств Пружинного Ботинка

Настройка приложения

Самый простой способ начать со скелетного проекта-использовать Spring Initializr . Выберите предпочитаемую версию Spring Boot, добавьте зависимость Web и создайте ее как проект Maven:

Если вы откроете проект, вы заметите, что файл application.properties хранится по пути src/main/resources|/.

Это файл по умолчанию, на который Spring полагается для загрузки свойств. Мы можем записать наши пользовательские или специфические для пружины свойства в виде пар ключ-значение здесь:

message.default.welcome=Welcome...
message.default.goodbye=Goodbye...

Вместо файла свойства мы также можем использовать файл .yml и определить те же свойства, что и:

message:
  default:
    welcome: Welcome...
    goodbye: Goodbye...

Это работает из-за SnakeYaml jar, присутствующего в пути к классу. YAML файлы более лаконичны и поддерживают карты, списки и т.д.

Какой тип использовать, зависит от вас и вашей команды. В этом уроке мы будем использовать тип .properties .

Ввод Свойств С Использованием @Value

Давайте посмотрим, как мы можем использовать эти свойства в простом REST API:

@RestController
public class GreetController {

    @Value("${message.default.welcome}")
    private String welcomeMessage;

    @Value("${message.default.goodbye}")
    private String goodBye;

    @RequestMapping("/welcome")
    public String welcome() {
        return welcomeMessage;
    }

    @RequestMapping("/bye")
    public String bye() {
        return goodBye;
    }
}

Это довольно просто. Используя аннотацию @Value , мы можем ввести значения из файла application.properties в поля класса в компоненте, управляемом Spring GreetController .

Затем у нас есть пара конечных точек REST, которые просто возвращают эти значения:

Использование @Value позволяет установить значение по умолчанию, если запрошенное значение по какой-либо причине недоступно:

@Value("${message.default.welcome:SomeDefaultValue}")
private String welcomeMessage;

Если сообщение.по умолчанию.добро пожаловать значение отсутствует, значение будет установлено как Некоторое значение по умолчанию .

Если вы хотите узнать больше об аннотации @Value , у нас есть подробная статья об этом!

Ввод Свойств С Помощью @ConfigurationProperties

Если наши свойства имеют какой-то общий контекст, например один и тот же префикс, мы можем использовать аннотацию @ConfigurationProperties , которая сопоставит эти свойства объектам Java:

@Configuration
@ConfigurationProperties(prefix = "message.default")
public class MessageProperties {

    private String welcome;
    private String goodbye;

    // Getters and Setters
}
  • @Configuration сообщит Spring о создании компонента этого класса.
  • @ConfigurationProperties инициализирует поля с соответствующими именами свойств.

Теперь мы можем использовать этот боб в других бобах, управляемых весной:

@Autowired
MessageProperties messageProperties;

Переопределение Свойств

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

Мы достигаем этого, сохраняя различные файлы или получая значения свойств через переменные среды.

Использование Пружинных Профилей

Наиболее распространенный способ записи “изменяющихся” свойств-хранить их в разных файлах. Эти файлы зависят от среды, и наше приложение может загружать их в зависимости от переменных среды.

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

Все, что нам нужно сделать, это следовать соглашению об именовании – приложение-<среда>.свойства для наших файлов свойств:

  • Все, что нам нужно сделать, это следовать соглашению об именовании –
  • приложение-<среда>.свойства
  • для наших файлов свойств: Все, что нам нужно сделать, это следовать соглашению об именовании –

Чтобы уведомить Spring, какие файлы использовать, мы должны установить переменную среды – spring.profiles.active .

При этом, если значение spring.profiles.active равно dev , например, Spring boot загрузит файл application-dev.properties и аналогично.

Примечание : application.properties всегда загружается, независимо от значения spring.profiles.active . Если в application.properties и application-<среда>.properties присутствует одно и то же значение ключа , последнее переопределит первое.

Обычно мы записываем все общие свойства каждой среды в application.properties и переопределяем свойства, относящиеся к конкретной среде, с помощью профиля application-<среда>.свойства .

Давайте посмотрим на это, создав application-dev.properties :

message.default.welcome = Welcome to DEV environment...

Существует несколько способов настройки spring.profiles.active переменной.

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

Мы можем установить его в переменных среды операционной системы, как в Windows:

Давайте запустим наше приложение, и в журналах вы увидите загружаемый профиль dev :

Давайте проверим обе наши предыдущие конечные точки REST:

Как мы видим, сообщение.по умолчанию.добро пожаловать значение получено из application-dev.свойства файл и сообщение.по умолчанию.до свидания свойство получено из application.свойства .

У нас может быть несколько значений в spring.profiles.active например dev,qa :

Любой дубликат ключа будет переопределен последним профилем, в приведенном выше случае qa .

Мы также можем передать spring.profiles.active в качестве аргумента командной строки, например:

Git Essentials

Ознакомьтесь с этим практическим руководством по изучению Git, содержащим лучшие практики и принятые в отрасли стандарты. Прекратите гуглить команды Git и на самом деле изучите это!

java -jar -Dspring.profiles.active=dev greeting-service-0.0.1-SNAPSHOT.jar

Создание приложения.свойства из расположения сборки

Мы также можем переопределить внутренние свойства, создав файл application.properties на том же уровне, с которого выполняется .jar . Контекст Spring переопределит свойства, используя этот недавно созданный файл.

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

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

Экстернализация Свойств С Помощью Сервера Облачной Конфигурации

Многие из приложений, созданных в настоящее время, основаны на архитектуре микросервиса. Эти приложения не только развертываются отдельно, но и могут иметь несколько собственных экземпляров (в зависимости от нагрузки), и общее количество может легко превысить 100.

Управление объектами в этом конкретном архитектурном стиле с помощью обычных методов требует слишком больших усилий. Кроме того, чтобы изменить свойство, мы должны снова перестроить приложение и развернуть его или, в лучшем случае, перезапустить приложение. Это требует простоя, что в некотором роде сводит на нет все назначение микросервисов.

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

Spring Cloud Config предоставляет централизованный, внешний, безопасный и простой способ хранения и обслуживания конфигураций приложений для различных сред:

Короче говоря, у нас есть Сервер конфигурации , работающий как отдельное приложение, которое подключается к репозиторию Git.

Когда мы запускаем новое приложение (клиент конфигурации), оно получает все необходимые свойства с сервера конфигурации. Не имеет значения, существовало ли приложение, когда мы настраивали сервер, или нет.

Создание сервера конфигурации

Как всегда, мы начинаем с использования Spring Initializr .

Выберите предпочитаемую версию Spring Boot, добавьте зависимость от сервера конфигурации и создайте ее как проект Maven:

Аннотируя наш основной класс с помощью @EnableConfigServer , мы помечаем его как сервер конфигурации:

@SpringBootApplication
@EnableConfigServer
public class Application {

    public static void main(String[] args) {
        SpringApplication.run(Application.class, args);
    }
}

А теперь нам нужно настроить несколько вещей в файле application.properties :

server.port = 8888
spring.cloud.config.server.git.uri = https://github.com/dhananjay12/spring-cloud-config
spring.cloud.config.server.git.searchPaths = app-properties

Здесь мы определили порт, на котором будет работать сервер конфигурации. Затем мы указали URL Git , который он должен использовать для поиска свойств.

Примечание : По умолчанию Spring выполняет поиск файлов свойств в корневом каталоге. Если нам нужно указать конкретную папку, мы можем указать ее местоположение с помощью путей поиска .

Вот как выглядит репозиторий Git:

Теперь мы можем запустить сервер конфигурации. Если вы хотите проверить конфигурацию сервера Spring Config, следуя соглашению – http://localhost:8888/<имя приложения>/<профили пружин> покажет нам всю необходимую информацию.

В нашем случае это было бы – http://localhost:8888/greeting-service-cloud/default :

Создание клиента конфигурации

Давайте создадим ту же службу приветствий, но с парой дополнительных зависимостей:

Здесь мы создали сервис приветствия-облачный сервис с Веб -|/, Клиентом конфигурации и Приводом зависимостями.

Он имеет те же сопоставления REST, что и раньше, с добавлением аннотации @RefreshScope . Эта аннотация позволяет динамически обновлять компонент во время выполнения:

@RestController
@RefreshScope
public class GreetController {

    @Value("${message.default.welcome}")
    private String welcomeMessage;

    @Value("${message.default.goodbye}")
    private String goodBye;

    @RequestMapping("/welcome")
    public String welcome() {
        return welcomeMessage;
    }
    @RequestMapping("/bye")
    public String bye() {
        return goodBye;
    }
}

Помимо application.properties теперь нам нужно создать bootstrap.properties , который загружается перед application.properties .

Обычно он используется клиентом Spring Config для получения свойств с сервера Spring Config :

spring.application.name = greeting-service-cloud
spring.cloud.config.uri = http://localhost:8888

Здесь мы сначала задаем имя приложения. Сервер конфигурации Spring будет искать это имя файла в репозитории Git и обслуживать его содержимое.

Мы также должны упомянуть, где работает сервер конфигурации, указав его в spring.cloud.config.uri .

Давайте запустим эту службу и взглянем на журналы:

Обратите внимание, что сначала он получил свойства с сервера конфигурации Spring.

Примечание : Если сервер конфигурации недоступен, приложение не запустится.

Теперь давайте проверим наши конечные точки ОТДЫХА:

Таким образом, мы экстернализировали наши свойства и обеспечили их хорошую отслеживаемость в нашем репозитории Git. Некоторые важные моменты, которые стоит отметить:

  • Мы также можем использовать пружинные профили-активные здесь. Если эта переменная задана в клиентской среде конфигурации, например. dev , он будет передан на сервер конфигурации при запросе свойств. Затем сервер конфигурации будет искать приветствие-сервис-облако-dev.свойства в репозитории Git и передавать его клиенту.
  • Если в репозитории Git присутствует файл application.properties , он будет передан всем клиентам в дополнение к другим файлам.
  • Если клиент Конфигурации запрашивает свойства, например, скажем dev профиль, сервер Конфигурации вернет application.properties , application-dev.properties и приветствие-сервис-облако-dev.свойства . Общие свойства будут переопределены последним.

Обновление свойств без перезапуска

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

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

Мы должны включить эти конечные точки вручную, указав management.endpoints.web.exposure.include = * в свойствах приложения.

Давайте добавим это в репозиторий Git и перезапустим приложение. Мы можем проверить многие детали вашего приложения, посетив конечные точки, такие как http://localhost:8080/actuator/env , http://localhost:8080/actuator/mappings и т.д.

Тот, который нас интересует, – это /привод/обновление . Мы можем заставить компонент обновить его конфигурацию (т. Е. Снова извлечь конфигурацию с сервера конфигурации), аннотируя компонент с помощью @RefreshScope .

Примечание : Если компонент обновляется, то при следующем доступе к компоненту (т. Е. выполняется метод) создается новый экземпляр.

Это может быть вызвано отправкой пустого HTTP POST запроса на конечную точку обновления клиента – http://<хост:порт>/привод/обновить .

Давайте изменим значение одного из них в репозитории Git на что – то другое:

message.default.welcome = Welcome from cloud config server changed...
message.default.goodbye = Goodbye...

management.endpoints.web.exposure.include = *

Теперь давайте запустим конечную точку обновления:

curl localhost:8080/actuator/refresh -d {} -H "Content-Type: application/json"

Проверьте /добро пожаловать конечную точку:

Таким образом, мы смогли обновить свойство запущенного приложения, не перезапуская его.

Вывод

В этой статье мы рассмотрели, как настроить свойства в нашем приложении Spring Boot.

Во-первых, мы обсудили простые способы добавления свойств в наше приложение, а затем изменения/переопределения этих свойств в зависимости от различных сред.

Во-вторых, мы рассмотрели, как получить свойства с сервера Spring Config и как обновить свойства без перестройки или перезапуска.

Как всегда, код для примеров, используемых в этой статье, можно найти на Github .

Читайте ещё по теме: