In the config migration guide, the section on profile activation is not really actionable. The first sentence says:
You can still use the
spring.profiles.activeproperty to activate specific profiles, however, you won’t be able to use this property in combination withspring.config.activate.on-profile.
The previous section just told me to start using spring.config.activate.on-profile (as I do have profile specific YAML documents). This section tells me, if I do that, then I can't use spring.profiles.active anymore, but doesn't tell me what to do instead.
The next sentence then talks about included profiles:
If you previous used spring.profiles.include in combination with spring.profiles, you should look at the new “profile groups” feature.
I understand "look at" as "replace with", and I can do that. But then I still don't know how to activate my "main" or "parent" profile. What do I replace spring.profiles.active with, which the previous sentence told me not to use? Or, can I use it for the main profile, if I use profile groups for every other profile, as the second sentence suggests?
(This part could be considered more suitable for StackOverflow, but I really think the guide should be updated as well).
I have application.yml in classpath, first document is general configuration, second is environment independent, but profile specific for production, up to now using spring.profiles: production, third is rabbitmq with config that triggers rabbitmq autoconfiguration. In the production document, I have spring.profiles.include: rabbitmq. (also there are testing and dev profiles).
Then I have application.yml outside of the Jar, it is a single document, and it is specific for production, containing environment specific URLs and credentials, it also uses spring.profiles: production.
I start the application with --spring.profiles.active=production
So applying the migration guide, I do the following:
* I keep the file structure
* I replace spring.profiles: production with spring.config.activate.on-profile: production
* I replace spring.profiles: rabbitmq with spring.config.activate.on-profile: rabbitmq
* I define (in general config) spring.profiles.group.production: ["rabbitmq"]
* I remove spring.profiles.include: rabbitmq from the production profile
* I want to still start my application --spring.profiles.active=production but that section of the guide tells me I can't
Is my understanding so far correct? If so, isn't the point that I can't combine spring.profiles.include (instead of .active) with spring.config.activate.on-profile?
If so, I want the guide to clearly tell me how I activate the "main" profile in this constellation, or remove the confusing sentence that I can't use spring.profiles.active with spring.config.activate.on-profile.
Comment From: blacelle
This refers to https://github.com/spring-projects/spring-boot/wiki/Spring-Boot-Config-Data-Migration-Guide
(On my side, i'm stuck with the removal of spring.profiles.include, and this page was out of sight)
Comment From: philwebb
Thanks for the issue @rainerfrey, we'll try to update that section to make things clearer.
To make sure I've understood your current setup. You currently have an application.yaml file inside your jar that looks like this? :
# general config
...
---
# production config
spring.profiles: production
spring.profiles.include: rabbitmq
...
---
# rabbit config
spring.profiles: rabbitmq
...
---
# testing config
spring.profiles: test
...
---
# dev config
spring.profiles: dev
...
And you have one outside your jar that looks like this?:
# production config
spring.profiles: production
...
The one outside has production credentials.
Following migration, you should have an application.yaml inside your jar that looks like this:
# general config
spring.profiles.group.production: [ "rabbitmq" ]
...
---
# production config
spring.config.activate.on-profile: "production"
...
---
# rabbit config
spring.config.activate.on-profile: "rabbitmq"
...
---
# testing config
spring.config.activate.on-profile: "test"
...
---
# dev config
spring.config.activate.on-profile: "dev"
...
And the one outside can look like this:
# production config
spring.config.activate.on-profile: "production"
...
You should be able to start your application with --spring.profiles.active=production and get the result that you want.
You could also simplify the file that's outside of the jar if you want to by dropping spring.config.activate.on-profile: "production". With Boot 2.4, files outside of the jar will override all values inside the jar (even profile specific ones).
Have I've summarized things correctly above? Does your application work correctly after the migration?
Comment From: rainerfrey
@philwebb that's the perfect summery.
To be honest, I haven't upgraded that application yet, only a simpler one without the rabbitmq profile. There everything works as expected.
In the mean time, I found the original blog post for the configuration changes. I think the piece that tripped me up in the wiki guide was: I interpreted
you won’t be able to use this property in combination with spring.config.activate.on-profile
as: "if you use spring.config.activate.on-profile, you can't use spring.profiles.active at all".
From the blog post, I deduce that I can't use spring.profiles.active inside the document that declares spring.config.activate.on-profile. Assuming this is correct, this would be really helpful information in the Wiki guide.
Comment From: Bryksin
I'm totally confused with the migration documentation and I'm not getting how to set active profile now...
Here is an example of what I had in the past services, before Spring Boot v2.4.0 release
spring:
application:
name: authentication
profiles:
active: dev
---
spring:
profiles: dev
cloud:
config:
enabled: false
*** some local dev props ***
---
spring:
profiles: qa54-nspace20-docker | prod250-nspace10-docker
cloud:
config:
fail-fast: true
# defined as Docker ENV
uri: ${CONFIG_SERVICE_URL}
Where Cloud Config was pulling props from own git repo based on application name (in this case authentication) and active profile https://<your_config_service_url>/<app_name>/<active_profile>
Here is an example of the cloud-config file:
authentication.yml
---
spring:
profiles: qa54-nspace20-docker
server:
# defined as Docker ENV
port: ${SERVICE_PORT}
*** some QA props ***
---
spring:
profiles: prod250-nspace20-docker
server:
# defined as Docker ENV
port: ${SERVICE_PORT}
*** some PROD props ***
So when I was running the application locally from the code, it was by default using dev profile
However, if I run it in the Docker (means I run it in QA or Prod)
In that case, service even didn't know the port it should run on, it was just referring to Cloud Config URL, which was set in the Docker as Env Var
The same as SPRING_PROFILES_ACTIVE which is default Env Var used by Spring Boot to set an active profile.
Those docker env var's based on the deployment environment - were passed inside the docker by Kubernetes deployment logic
Now spring.profiles.active doesn't work at all
I'm getting at the start of the service the following log:
No active profile set, falling back to default profiles: default
Setting spring.config.use-legacy-processing: true also has no effect, service simply doesn't start without profile
Nor in the migration doc says anything about the fate of SPRING_PROFILES_ACTIVE Env Var
So, if I have to use now: spring.config.activate.on-profile - it is fine, but how do I set the active profile now if it says:
You can still use the spring.profiles.active property to activate specific profiles, however, you won’t be able to use this property in combination with spring.config.activate.on-profile
Comment From: philwebb
@Bryksin What version of Spring Cloud are you using?
Comment From: Bryksin
@philwebb
set('springCloudVersion', "2020.0.0-M5")
I used Spring Initializr to get started
Comment From: philwebb
I've updated the migration guide to hopefully improve the situation.
Comment From: philwebb
@Bryksin I'm not sure exactly what's going on with your issue. Can you try M6 and if that fails raise an issue with Spring Cloud (along with a sample app).
Comment From: rainerfrey
I've updated the migration guide to hopefully improve the situation.
Thank you, this is a lot easier to understand now, and the additional examples are really helpful.