Основной способ настройки профилей Spring в Cloud Foundry - использование переменных среды.
Cloud Foundry не предоставляет способ установки групп переменных среды для организации или пространства.Вы можете установить только промежуточную группу и группу переменных рабочей среды, которая применяется ко всем промежуточным или всем запущенным приложениям.Это в дополнение к стандартным средствам для установки переменных среды в приложении.
Я думаю, вы могли бы заставить это работать, но это займет немного усилий.Вот идея.
Создайте собственный сборочный пакет (не паникуйте, это не так уж сложно).Единственной обязанностью buildpack является создание сценария .profile.d/ (обычный сценарий Bash), который содержит export SPRING_PROFILES_ACTIVE=<some-profile>.
. Любой пакет buildpack может создавать сценарии .profile.d/, которые в основном используются для настройки переменных среды.Эти сценарии автоматически создаются средой перед запуском любого приложения.Таким образом, если buildpack устанавливает SPRING_PROFILES_ACTIVE здесь, он будет доступен для вашего приложения и вступит в силу.
https://docs.cloudfoundry.org/buildpacks/custom.html#contract
Вам просто нужно создать bin/supply и bin/detectскрипты, как определено по ссылке ниже.bin/supply - это то место, куда вы должны поместить свою логику для создания сценария .profile.d/, а bin/detect может быть таким же простым, как exit 0, который просто скажет, что он будет выполняться всегда.
https://docs.cloudfoundry.org/buildpacks/understand-buildpacks.html#buildpack-scripts
Ваш пользовательский пакет сборки может быть таким же простым, как использование жестких профилей кодирования, или может показаться причудливым, если взглянуть на среду VCAP_APPLICATION, содержащую имя пространства.
Пример: echo $VCAP_APPLICATION | jq .space_name.
Затем пакет сборки может применить логику для установки правильного профиля с учетом имени пространства.Я не думаю, что имя org доступно приложению во время подготовки / выполнения, по крайней мере, не через переменные среды, поэтому было бы сложнее применить логику на его основе.
Последний шаг - использование поддержки multi-buildpack CF.Ваш пользовательский сборочный пакет будет поставляемым сборочным пакетом, поэтому он будет первым, а затем вы перечислите фактический сборочный пакет, который будет использоваться вторым при загрузке приложения.
Пример: cf push -b https://github.com/your-profile/your-custom-buildpack -b java_buildpack your-cool-app.
https://docs.cloudfoundry.org/buildpacks/use-multiple-buildpacks.html
Надеюсь, это поможет!