Problem Description
We use EKS for deployments and our Spring active profile is used for deployment environment definition
However composite config for config service requires composite
profile to be activated
spring:
application:
name: config-service
profiles:
active: composite
cloud:
config:
server:
composite:
-
type: git
uri: <your_repo_url>
-
type: awss3
bucket: <your_bucket>
if composite
profile is not set, it doesn't work.
The same is related to any other config sources apart from git.
For example, if I want awss3 bucket to work, I must set active awss3
profile
Example:
spring:
application:
name: config-service
profiles:
active: awss3
cloud:
config:
server:
awss3:
bucket: <your_bucket>
if awss3
was not set to be active, the config would not take an effect
Suggested solution Allow usage spring profiles like in any other Spring Boot projects, without specific profiles
Example:
spring:
application:
name: config-service
profiles:
active: dev
---
spring:
config:
activate:
on-profile: dev
cloud:
config:
server:
composite:
-
type: git
uri: <your_repo_url>
-
type: awss3
bucket: <your_bucket>
In the example above I would expect the composite
setup would be active, but it is not.
or in the following config, I would expect in dev
profile aws s3 backend would be active and in qa
profile it will use git as a backend
spring:
application:
name: config-service
profiles:
active: dev
---
spring:
config:
activate:
on-profile: dev
cloud:
config:
server:
awss3:
bucket: <your_bucket>
---
spring:
config:
activate:
on-profile: qa
cloud:
config:
server:
git:
uri: <your_repo_url>
But this approach doesn't work.
We have 30+ Spring Boot services following a naming convention where the active profile is = to env name Where Config Service forces to use their own hardcoded profile names instead of the common pattern of Spring Boot profiles usage.
I know that active profiles can be combined through a comma, but in our case, it is not required and only Config Service require this, which feels incorrect approach.
Comment From: ryanjbaxter
Why not separate the configurations out into their own docs?
application-dev.yaml contains
spring:
profiles:
active: awss3
cloud:
config:
server:
awss3:
bucket: <your_bucket>
application-qa.yaml contains
spring:
profiles:
active: git
cloud:
config:
server:
git:
uri: <your_repo_url>
Comment From: Bryksin
The problem here is not in the file separation or how to solve the problem, having several profiles through commas is also a solution. Workarounds exist and they are not so problematic.
However, this ticket is about hardcoded obligatory profile names that must be used to activate different backends support which feels a bit incorrect. Developers should be able to use any profile names they want, and it should not affect the functionality.
If the config file contains configuration for AWS s3 it should be enabled without a specific profile name like awss3
or composite
or else...
Comment From: ryanjbaxter
So you are basically just suggesting we remove the requirement for profiles and just use the presence of specific properties to dictate functionality?
I think someone could make a similar argument in the other direction as well. They may like the fact that things don't take effect unless specific profiles are enabled.
I am not sure there is an approach that please everyone.
Comment From: Bryksin
Well, I was taking for reference the standard spring boot application, non of the integrations required a specific active profile.
As I mentioned we have 30+ microservices tidily integrated with AWS and EKS and non-of them require awss3
active profile to start working with S3 bucket :)
These hardcoded profiles names just caught my eye because they are definitely standing out from standard spring boot profiles usage and it is just not logical from the config file point of view, have a look at this example:
spring:
application:
name: config-service
profiles:
active: dev
---
spring:
config:
activate:
on-profile: dev
cloud:
config:
server:
composite:
-
type: git
uri: <your_repo_url>
-
type: awss3
bucket: <your_bucket>
How is that hinting to me that I should use a composite
profile? it just doesn't make sense. As a developer, I would expect that if dev
profile is active, the rest of the config under that profile will be active, as it does for any spring boot app, but in case of config service it doesn't, I need to search documentation and find out that apparently profile names (per each backend integration) are hardcoded and if I want them to work I must active them separately or by using composite
Comment From: ryanjbaxter
This has been this way for a while, would love to now if others have similar thoughts as you