Русские Блоги
В работе проекта существует несколько сред, таких как онлайн-среда prod (продукт), среда разработки dev (разработка), тестовая среда test, тестовая среда qa, unit test unitest и т. Д. Разные среды требуют разных конфигураций для запуска наших программ в разных сценариях. Например, среда prod и среда разработки обычно должны подключаться к разным базам данных и настраивать разные конфигурации вывода журнала. Также существуют классы и методы, которые имеют разные реализации в разных средах.
Каталог статей
2. Активация профиля
При фактическом использовании в аннотациях указано несколько сред, таких как prod, test и qa. Какой профиль используется во время выполнения, контролируется spring.profiles.active. Ниже описаны два метода: режим файла конфигурации и режим командной строки.
(1) Активировать профиль в режиме файла конфигурации
spring.profiles.active=dev
Кроме того, то же самое можно настроить и в resources / application.yml, эффект такой же:
Пошаговая инструкция по заполнению CSS Profile
spring: profiles: active: dev
(2) Активировать профиль из командной строки
При запуске после упаковки добавьте параметры:
java -jar spring-boot-02-config-0.0.1-SNAPSHOT.jar —spring.profiles.active=dev；
2. Многопрофильные файлы ресурсов
1. Файл конфигурации ресурса
В дополнение к application.properties файл конфигурации ресурсов Springboot также может иметь соответствующий файл ресурсов application- .properties.
Предположим, что рабочая среда приложения: dev, test, prod
Затем мы можем добавить 4 файла конфигурации:
- applcation.properties-public конфигурация
- application-dev.properties-конфигурация среды разработки
- конфигурация среды application-test.properties-test
- конфигурация среды application-prod.properties-production
Для активации профиля в файле applcation.properties также можно активировать различные файлы конфигурации свойств: spring.profiles.active = test
2. Примеры использования
Ниже приведен пример нескольких файлов конфигурации ресурсов, которые в основном различают среду разработки dev и онлайн-среду prod.
Создайте новый интерфейс в Sound.java на уровне контроллера, чтобы возвращать информацию в файле конфигурации: имя и локальный.
Содержимое файла application.properties выглядит следующим образом:
## Свойства активации файла конфигурации для нескольких сред spring.profiles.active=prod
Содержимое файла application-dev.properties выглядит следующим образом:
Содержимое файла application-prod.properties выглядит следующим образом:
После запуска Springboot посетите http: // localhost: 2222 / sound / hello, вы получите следующие результаты. Если вы посетите http: // localhost: 11111 / sound / hello в это время, вы не сможете посетить, потому что в это время spring.profiles.active=prod Среда prod активирована, и используется конфигурация в application-prod.properties.
360 Mentors: Как правильно заполнить Common App и CSS Profile
Измените файл application-dev.properties, spring.profiles.active=dev Активируйте среду разработки. Перезапустите Springboot, и вы сможете посетить http: // localhost: 11111 / sound / hello.
Источник: russianblogs.com
Внешние данные конфигурации в Spring
Большинство наших приложений зависят от внешних сервисов, например серверов баз данных, SMS-шлюзов и систем наподобие PayPal. Эти сервисы могут существовать более чем в одной среде, то есть в средах разработки и эксплуатации. Если мы хотим подключиться к эксплуатационной среде, мы должны сначала пройти через среду разработки. Таким образом, во время создания приложений нам приходится переключаться между средами. Это связано с тем, что у каждой среды своя уникальная конфигурация со своими параметрами подключения и прочими значениями.
Проблема
Предположим, что мы разрабатываем платежный сервис, который подключается к внешнему платежному провайдеру. Значения коммерческого счета в эксплуатационной среде и среде разработки не совпадают. То есть при каждом переключении среды нам приходится изменять значения и компилировать код заново, а это неэффективно.
Решение
Лучшее решение этой проблемы — вывод данных конфигурации приложения во внешний источник. Нам не нужно будет каждый раз заново компилировать код при переключении среды. Мы сможем переопределить значения параметров конфигурации, затратив меньше усилий. Наше приложение Spring сможет считывать значения коммерческого счета из внешних источников, например переменных среды, аргументов командной строки и файлов свойств.
Вывод данных конфигурации во внешний источник
Источники свойств
Существуют различные способы вывода данных конфигурации приложения Spring во внешний источник. Для задания свойств приложения мы можем использовать переменные среды, файлы свойств (например, в формате YAML или с расширением *.properties) и аргументы командной строки. Мы также можем хранить файлы свойств в произвольных местах и сообщать приложению Spring, где их искать.
Файлы свойств
По умолчанию приложение Spring загружает свойства из файлов application.properties или application.yml из перечисленных ниже источников в порядке приоритета (то есть вышестоящий файл свойств переопределяет файлы из источников нижнего уровня) и добавляет их в среду:
- подкаталог конфигурации текущего каталога;
- текущий каталог;
- пакет конфигураций в параметре classpath;
- корневой каталог classpath.
По умолчанию имя файла конфигурации — application. При желании мы можем указать другое имя, используя ключ свойств среды spring.config.name . В примере ниже мы переопределили имя конфигурации Spring, заданное по умолчанию, на new_name .
spring.config.name=new_name
Пользовательское место хранения
Мы можем задать внешний источник свойств приложения или файлов YAML с помощью свойства среды spring.config.location . Это свойство может указывать на любое пользовательское место хранения и таким образом переопределять местоположение по умолчанию. См. пример ниже:
spring.config.location=
Примечание. При указании расположения каталога необходимо убедиться, что после значения spring.config.location стоит символ / (например, spring.config.location=classpath:/config/ ) и что задано имя файла конфигурации по умолчанию. Также с помощью ключа свойств spring.config.additional-location можно указать дополнительные каталоги, поиск в которых будет проводиться перед поиском в местоположениях по умолчанию.
spring.config.additional-location=
Spring Boot также поддерживает обобщенное указание местоположения с помощью подстановочных символов. Эта функция полезна в средах с несколькими источниками свойств конфигурации, таких как среды Kubernetes. Например, у вас есть конфигурации Redis и MySQL.
Они могут храниться в разных местах, но при этом они обе должны быть указаны в файле application.properties , чтобы их видело приложение. Это может привести к тому, что два отдельных файла application.properties будут смонтированы в разных местах, например /config/redis/application.properties и /config/mysql/application.properties . В таком случае использование обобщенного указания каталога config/*/ позволит обрабатывать оба файла.
Форматы файлов
Файл свойств приложения может быть в формате YAML или иметь расширение .properties. Если эти два файла свойств будут храниться в одной и той же папке конфигурации, файл application.properties будет иметь приоритет над файлом application.yml . В следующем фрагменте кода показаны настройки коммерческого счета, определенные в файле свойств каждого типа.
application.properties
merchantaccount.name=Maureen Sindiso Mpofu merchantaccount.username=momoe merchantaccount.code=771222279 merchantaccount.number=100 merchantaccount.currency=ZWL server.port: 9092
application.yml
merchantaccount: name: Maureen Sindiso Mpofu username: momoe code: MCA1230 number: 771222279 currency: ZWL
Файлы форматов YAML и .properties
YAML — это легкочитаемый стандарт сериализации данных, часто применяемый в файлах конфигурации. Он является надмножеством формата JSON и очень удобен при составлении иерархической конфигурации. Файлы формата YAML предпочтительны, поскольку они более понятны и удобочитаемы, особенно по сравнению с файлами .properties. Помимо этого, у них есть другие очень полезные функции, например безопасность типов и т. д.
Для загрузки файла YAML приложению Spring требуется библиотека SnakeYAML в параметре classpath . В приведенном примере кода использованы стартеры Spring Boot, поэтому необходимости включать данную библиотеку в параметр classpath нет.
Множество профилей
YAML позволяет указать несколько профилей в одном файле конфигурации, тогда как при использовании файла .property нам может потребоваться файл конфигурации для каждого профиля. Рассмотрим следующий пример.
1. Файл YAML
application.yml
spring: profiles: active: development — spring: profiles: development merchantaccount: name: Maureen Sindiso Mpofu username: momoe code: MCA1230 number: 771222279 currency: ZWL server: port: 9090 — spring: profiles: production server: port: 9093 merchantaccount: name: Maureen Sindiso Mpofu username: momoe code: MCA1234 number: 771222279 currency: ZWD
2. Файл .properties
В случае с файлом .properties , при определении двух профилей нужно создать отдельный файл конфигурации для каждого из них. К имени каждого файла конфигурации добавляется -.properties . В примере ниже показаны профили приложения для разработки и эксплуатации.
application-development.properties
merchantaccount.name=Maureen Sindiso Mpofu merchantaccount.username=momoe merchantaccount.code=771222279 merchantaccount.number=100 merchantaccount.currency=ZWL server.port: 9092
application-production.properties
merchantaccount.name=Maureen Sindiso Mpofu merchantaccount.username=momoe merchantaccount.code=MCA1234 merchantaccount.number=771222279 merchantaccount.currency=ZWD server.port: 9093
При наличии свойств, общих для профилей разработки и эксплуатации, нам может потребоваться файл application.properties, заданный по умолчанию.
application.properties
spring.profiles.active=development #default port number server.port=9091
Образец данных конфигурации в приведенных выше фрагментах кода устанавливает профиль разработки в качестве активного профиля. Поэтому при запуске приложения значения свойств, определенные в этом профиле, будут иметь приоритет над эксплуатационным профилем. Но не стоит забывать, что настройки профиля можно также переопределить с помощью аргументов командной строки.
Вы можете узнать больше о профилях Spring в этой статье.
Читаемость
YAML поддерживает списки и карты в виде иерархических свойств, и по сравнению с файлом расширения .properties версия YAML более удобочитаемая. Допустим, мы хотим настроить параметры подключения для реальной и тестовой сред. Сначала зададим имена подключений в виде списка, а затем сопоставим их с соответствующими URL-адресами с помощью карты, как показано ниже. Рассмотрим, как реализация в YAML может упростить эту конфигурацию в сравнении с файлом .properties.
application.yml
connection: names: — test — live addresses: test: http://host/test live: http://host/live
application.properties
#list connection.names[0]=test connection.names[1]=live #map connection.addresses.test=http://host/test connection.addresses.live= http://host/live
Тестовые примеры для проверки сопоставлений можно найти в тестовых пакетах с примером кода из данной статьи.
Аргументы командной строки
Когда мы вводим аргумент командной строки, приложение Spring преобразует его в свойство и добавляет в Spring Environment. С помощью этих аргументов можно сконфигурировать параметры приложения. К примеру, следующие аргументы командной строки переопределят порт сервера приложения, заданный любым другим источником свойств. При запуске приложения командой Maven или Java мы все равно получим тот же результат.
Команда Maven:
$mvn spring-boot:run -Dspring-boot.run.arguments=»—spring.profiles.active=production»
Команда JVM:
$java -jar target/app.jar – spring.profiles.active=production
Также можно вводить несколько аргументов одновременно. Дополним приведенный выше пример еще одним свойством — портом сервера, как показано ниже.
Команда Maven (через пробел):
$mvn spring-boot:run -Dspring-boot.run.arguments=»—spring.profiles.active=production – server.port=8089″
Команда JVM:
$java -jar target/app.jar – spring.profiles.active=production – server.port=8089
Переменные среды
Если у нас нет возможности изменять значения свойств через командную строку, на выручку приходят переменные среды. Приложение Spring может считывать свойства из них. При запуске оно ищет переменную среды под именем SPRING_APPLICATION_JSON , которая может содержать набор свойств JSON в одностроковом формате.
Мы можем поэкспериментировать и переопределить адреса подключения, указанные в нашем файле свойств, как описано ниже.
Откроем терминал и выполним следующую команду. Она устанавливает переменные среды приложения, переопределяя настройки подключения.
$export SPRING_APPLICATION_JSON=’>>’
После этого запустим наше приложение:
$java -jar -Dspring.profiles.active=development target/app.jar
Результат
Проверив журнал, мы заметим, что адреса подключения в профиле разработки были переопределены, а значения в файле JSON, который мы передали через переменную среды, были в приоритете.
Передача свойств
application.yml
merchantaccount: name: Maureen Sindiso Mpofu username: momoe code: MCA1230 number: 771222279 currency: ZWL
Порядок приоритета данных конфигурации
В приложении Spring Boot может быть несколько источников свойств. Поэтому важно знать, какой источник свойства имеет наивысший приоритет. Например, если конфигурация нашего приложения находится в файле application.yml и во время выполнения приложения мы решаем передать аргументы командной строки, тогда значения свойств в файле application.yml будут переопределены значениями аргументов командной строки.
В Spring Boot 2.2.x используется приведенный ниже порядок источников свойств. Источник свойств, расположенный выше в списке, имеет приоритет над источниками под ним.
- java
- java developer
- spring externalized configuration
- application.properties
- application.yml
Источник: habr.com
Spring Profiles
Для начала рассмотрим, как создавать профили в Spring Boot и делать профиль активным с помощью файла application.properties.
За основу возьмем Spring Boot REST API приложение, написанное в статье.
Только теперь будем использовать не встроенную базу данных, а базу MySQL. Создадим в ней три схемы для трех окружений — development, test и production. Не забудьте включить соответствующую Maven-зависимость (либо можно скачать код готового приложения):
mysql mysql-connector-java
В нашем приложении будет соответственно три профиля. Назовем их dev, test и prod.
Активный профиль задается в файле application.properties:
spring.profiles.active=dev
Для каждого профиля создадим соотвествующий файл:
- application-dev.properties
- application-test.properties
- application-prod.properties
В каждом из них будут свои настройки базы данных. Например, в файле application-test.properties они будут такими:
spring.datasource.url=jdbc:mysql://localhost:3306/test_database_name spring.datasource.username=root spring.datasource.password=admin spring.jpa.hibernate.ddl-auto=create
В файле application-dev.properties они такие:
spring.datasource.url=jdbc:mysql://localhost:3306/dev_database_name spring.datasource.username=root spring.datasource.password=admin spring.jpa.hibernate.ddl-auto=create
Теперь давайте запустим наше REST-приложение. Поскольку в application.properties стоит активация профиля dev, DataSource будет инициализироваться настройками файла application-dev.properties, то есть использоваться будет база данных dev_database_name. В этом можно убедиться, добавив Person в базу с помощью запроса через Postman и посмотрев, что таблица Person не пуста в базе dev_database_name. Как это делать, мы показывали в предыдущей статье.
Убедитесь, что перед запуском приложения вы создали три пустые базы MySQL: dev_database_name, test_database_name и prod_database_name.
Теперь попробуем активировать профиль для интеграционного теста. Тесты мы писали с помощью REST-assured.
Активация профиля для тестирования
Просто, не правда ли?
Но это еще не все, далее мы рассмотрим как содавать для каждого профиля свои бины с помощью аннотаций.
Давайте аннотируем класс ExampleTestBean, экземпляр которого будет создаваться только при активном профиле test:
Проверим, что бин действительно создается. Мы активировали профиль test, внедрили бин ExampleTestBean и проверили, что он не нулевой:
Как получить активный профиль программно
Обратите внимание, что в предыдущем примере мы взяли и напечатали текущий активный профиль:
for (final String profileName : environment.getActiveProfiles())
Цикл используется потому, что активных профилей может быть несколько. У нас он один, так что берем и печатаем самый первый.
Итог
Настройка профилей в Spring и Spring Boot оказалась легкой.
Как всегда, полный код примера доступен на GitHub.
Автор sysout Опубликовано 29.07.2018 15.04.2021 Рубрики Spring, Spring Core
Добавить комментарий Отменить ответ
Прошу прощения: на комментарии временно не отвечаю.
Источник: sysout.ru
Как использовать профили в приложении Spring Boot
В этом уроке мы узнаем, как мы можем использовать профили в приложении Spring Boot.
Мы обсудим следующие моменты в этом уроке:
1. Что такое профиль весенней загрузки и почему нам нужно профилирование
2. Как выполнить профилирование в Spring Boot с примером
3. Как установить / изменить профиль по умолчанию
1. Что такое профиль весенней загрузки и почему нам нужно профилирование
Предположим, вы работаете с приложением Spring Boot. Вы протестировали приложение локально на своем компьютере, подключившись к локальной базе данных, которая установлена на вашем компьютере. Теперь вы хотите развернуть это приложение в среде DEV, и у вас также есть сервер базы данных DEV. у вас есть база данных
Теперь, когда вы тестируете приложение локально, в вашем файле application.properties вы бы поместили такие данные, как url базы данных, имя пользователя, пароль для локальной базы данных, которая установлена на вашем компьютере, но как только вы перейдете в среду DEV, вы захотите Ваше приложение для общения с базой данных DEV, а не с локальной базой данных.
Таким образом, вы можете изменить файл application.properties, указав сведения, необходимые для подключения к базе данных DEV, зафиксировать код и развернуть его в DEV, но теперь проблема заключается в том, что этот код будет нормально подключаться к базе данных DEV, но когда вы попытаетесь выполнить этот код из локальной системы, он не будет работать, потому что вы изменили детали базы данных на базу данных DEV.
Итак, еще раз, чтобы заставить его работать на вашем локальном компьютере, вам нужно будет внести изменения в application.properties, которые требуются для локального и выполнения приложения.
Как вы можете видеть, здесь много суеты между местными и DEV.
Теперь представьте, что у вас есть больше сред, таких как ST, ET (QA), PROD, и вам нужно все время вносить изменения вручную. Это будет настоящий кошмар.
Так в чем же решение?
Весенние Профили Загрузки в Спасении!
Spring Boot позволяет вам настроить конфигурацию приложения, чтобы вы могли работать с одним и тем же кодом приложения в разных средах без необходимости вносить изменения.
Spring Boot Profiles позволяет вам настраивать несколько файлов application.properties для каждой среды, так что когда вы находитесь в локальной среде, он будет использовать локальный файл свойств, когда вы находитесь в DEV, он будет использовать файл свойств DEV и так далее, без вас как Программист должен внести какие-либо явные изменения в код.
В общем, если у вас есть свойства приложения, которые различаются в зависимости от среды, вы можете справиться с этим с помощью Spring Profiles.
Выглядит круто. Не правда ли
2. Как выполнить профилирование в Spring Boot с примером
2.1 Следуйте моему посту Как создать проект Spring Boot с помощью Spring Initializer и создать проект Spring Boot с именем «Springbootprofiles». Добавьте только веб-зависимость, так как этого будет достаточно для нашего тестирования.
2.2 В файле приложения .properties, который был автоматически создан Spring intializer, добавьте следующую строку:
application.environment = Это локальная среда
2.3 Запустите приложение, нажав на проект и выбрав Запуск от имени -> Выполнить настройки -> Выполнить
2.4 Проверьте журналы консоли, созданные Spring boot
Вы увидите следующую строку в журналах
2019-07-07 20: 00: 52.147 ИНФОРМАЦИЯ 15560 – [main] cbjsSpringbootprofilesApplication: активный профиль не установлен, откат к профилям по умолчанию: по умолчанию
Что в основном говорит о том, что мы не установили какой-либо профиль явно, поэтому Spring Boot использует профиль по умолчанию, что означает, что Spring Boot использует конфигурации из файла application.properties.
Как мы можем это проверить?
Давайте посмотрим на следующие шаги.
2.5 Создайте контроллер с именем ProfileController.java следующим образом:
Источник: coderlessons.com