This question is similar to (but different in the aim): Shared Config(at git) between SPring Boot Services so I will make use of the example the OP wrote there.
In my case I am using Spring Cloud Config Server with the Vault as backend, but for the sake of argument I will describe it as if it were in git. So imagine I have 4 Services: A, B, C and D.
And I have the following configs:
- A-prod.properties
- A-dev.properties
- B-prod.properties
- B-dev.properties
- C-prod.properties
- C-dev.properties
- D-prod.properties
- D-dev.properties
- application-prod.properties
- application-dev.properties
Now according to the docs I will have one of the services, let's say Service C getting his properties from C-(ENV).properties as well as application-(ENV).properties. Similarly the same with the others, i.e. everyone gets their own file and everything on application.properties.
My question is:
Is it possible to have for example a "semi-global" shared properties, e.g. a file that A and C share some config and another that B and D share some config?
An usage example would be DB Connection Credentials, where two services make use of one set of credentials, and the others another one.
I have been trying to find infos about this and doing some tests, but nothing that got me anywhere...
Unfortunately, it's not possible to achieve what you want. The only way to share properties is by using the application.properties(yml) file which is merged to every other configuration file.
Related
I am new to spring boot, have come across a situation...
l have 10 different property files based on various logical modules of a monolith application(db.properties,jms.properties, etc) and 7 envs(pre, sit1,sit2,uat1,uat2,prod, dr). The idea of having diffrent property files so that we can use them almost with no change whenever we move to microservice based approach.
One approach says - we use various spring application names
like - spring.application.name=db,jms,a,b .....
In this way we will land up having 10×7 = 70 files under same folde? (In order to make it profile driven) like jms.properties,jms-dev.properties,jms-uat.propetris...... for all various logical modules.
Is there any better approach to host the files using config server?
We have a monolith application and we plan to continue the same for the time being.
I am struggling to build such facility using spring cloud config server...if any one can help
As said in the title, is there a way to add application users in Thorntail WilFly server, much like you would do with "add-user.sh -a" script in the full server distribution?
I understand you can provide an external configuration file to Thorntail but that seems a bit of overhead just for specifying where users are located.
Thanks
The answer by Thomas Herzog is very good from a conceptual point of view -- I'd especially agree with securing the application using an external Keycloak, potentially with the help of MicroProfile JWT. I'm just gonna provide a few points in case you decide not to.
You can define users directly in project-defaults.yml, like this:
thorntail:
management:
security-realms:
ApplicationRealm:
in-memory-authentication:
users:
bob:
password: tacos!
in-memory-authorization:
users:
bob:
roles:
- admin
The project-defaults.yml file doesn't have to be external to the app, you can build it directly into it. Typically, in your source code, the file will be located in src/main/resources, and after building, it will be embedded inside the -thorntail.jar. It can be external, of course, and if this is something else than a throwaway prototype or test, sensitive data like this should be external.
You can also use the .properties files from WildFly:
thorntail:
management:
security-realms:
ApplicationRealm:
properties-authentication:
path: .../path/to/application-users.properties
properties-authorization:
path: .../path/to/application-roles.properties
It depends on for what you need the users? Thorntail creates standalone Microservices, which are different to hosted applications in a wildfly-server.
Is there are a management console in thorntail?
Yes there is, but I have never used it.
https://docs.thorntail.io/2.2.0.Final/#_management
https://docs.thorntail.io/2.2.0.Final/#_management_console
The users you maybe able to create there shouldn't be persistent, because there is no wildfly-server installation as you are used to with a standalone wildfly-server installation, it is all packaged in the jar. A Microservice shouldn't need to be configured after its deployment anymore, at least not like this.
How to secure my application?
I would recommend to use an external user management via keycloak, which is integrated in thorntail via the keycloak fraction. With the keycloak fraction you can define security constraints to your endpoints similar in a web.xml.
https://docs.thorntail.io/2.2.0.Final/#_keycloak
Another way is to use the security fraction which provides you JAAS support for your microservice.
https://docs.thorntail.io/2.2.0.Final/#_security
The configuration is done via the thorntail specific project-defaults.yml configuration file, where you can configure the fractions via YAML.
What is a thorntail fraction?
A thorntail fraction is similar to a spring boot start dependency with spring, whereby the fraction provides the API for the developement and bundles the implementation and integration into thorntail. The fraction actually is a jboss module which is packaged into the standalone Microservice during re-packaging phase.
Where can I find examples?
See the following links for examples how to use security in thorntail. You should take a look at them.
https://github.com/thorntail/thorntail-examples/tree/master/security
Take a look at the src/main/resources/projects-defaults.yml which contains the configuration for thorntail fractions and the pom.xml which defines the used fractions.
I want to use a common application properties file for multiple microservices which will have some common configuration like DB Source config etc..I have use the config Server with Eureka server and zull Proxy.
Issue:
When using configServer we need to provide the spring.application.name = 'xyz'
which in turn find the xyz.properties for this microservice configuration.
The same way when we register the service with zuul proxy also need the same application name for configure the service path as zuul.routes.xyz.path = /iii/*.
Now I want that multiple service will share the same property file(xyz.properties) but need to register the zuul route as well so I have to provide the different name for each service. If I will provide the different name to each service they will not be able to locate the same property file.
I am new to spring boot micro services.
spring.config.client.name supports multiple names separated by commas to load the configuration properties.
In this case, store the common properties in common.yml and xyz properties in xyz.yml. Finally, mention spring.cloud.config.name: xyz,common
spring:
cloud:
config:
uri: http://localhost:8888
name: xyz,common
Output:
Fetching config from server at : http://localhost:8888
Located environment: name=xyz,common, profiles=[default], label=null, version=91edcf96c6a88707bf39014a16ad5d301d6b4575, state=null
Located property source: CompositePropertySource {name='configService', propertySources=[MapPropertySource {name='configClient'}, MapPropertySource {name='https://github.com/BarathArivazhagan/config-server-repository/common.yml'}, MapPropertySource {name='https://github.com/BarathArivazhagan/config-server-repository/xyz.yml'}]}
I would like to point out that the provided solution leverages the "spring.config.client.name" client side property semantics to achieve a config server behavior of serving properties files from multiple files other than application[-profile].* and {appname}[-profile].*
However, note that for a simple case and considering a root dir, the config server serves properties from files defined in this root dir or under a folder with the name of the application, that the property files under it correspond to, i.e. */{appname}/application[-profile].** or */{appname}/{appname}[-profile].**
The "spring.config.client.name" environment property instructs the config server which application names the requesting app matches with. This means that given a spring.config.client.name=a,b , the config server will assume serving properties defined for app (with name) a and b to the requesting app! This is not the exact same thing as I want my properties been served from file names a and b! Therefore we are abusing the property semantics for managing our config server serving from the file names we would like it to.
However, due to the actual semantics of spring.config.client.name the config server will serve everything applicable from
/a[-profile].*
/b[-profile].*
/a/{applicable names}
/b/{applicable names}
The caveat here is that we achieve what we want only for the root directory and, moreover, if we have a configserver that serves multiple springboot apps we loose the ability to have all our properties under our application's name-folder.
Even worse, if there exists another app (or -attention!- will exist in the future) with the same name as one of our desired property file names, the config server will start serving to our app ALL the configuration defined for that other app!!! This could end up in wrong and even harmful served configuration!
(I repeat it will serve everything applicable under /{other-app-name-that-i-happened-to-use-as-filename-and-defined-it-through-spring.config.client.name}/*!!!)
So beware when pirsuiting this approach!
I have issued a pull request for spring-cloud-config-server 1.4.x, that supports defining additional file names, through a spring.cloud.config.server.searchNames environment property, in the same sense one can do for a single springboot app, as defined in the Externalized Configuration.Application Property Files section of the documentation, using the spring.config.name enviroment property. I hope they review it soon
I currently have a number of deployable applications that work in a distributed fashion to solve a business problem. We are currently using a number of property configuration files to provide changing configuration per environment based off a system environment variable. All these deployable application share common configuration for database and messaging. This is currently achieved by picking up property files from the class path and having both deployed apps share a common jar for each connection (db, jms) containing property files.
I am looking to start using Spring Config Server to externalize this configuration if possible. I have a question about how to share this common config.
Currently it looks something like this:-
Web1
- database
- jms
Messaging1
- database
- jms
In this situation both deployed apps share the same connections and these connections change per environment (lab, prf, prd, etc). How can I achieve the same with the Spring Configuration Server where I have app config for each deployable app?
Application.yml
Web1.yml
Web1-dev.yml
Messaging1.yml
Messaging1-dev.yml
If a connection property changed for an environment I would need to make the change to each deployable app configuration rather than making it just once.
Is there currently anyway to achieve this? Am I just missing a simple point?
I found working solution here https://cloud.spring.io/spring-cloud-config/single/spring-cloud-config.html, paragraph "2.1.5 Sharing Configuration With All Applications". It says:
With file-based (i.e. git, svn and native) repositories, resources
with file names in application* are shared between all client
applications (so application.properties, application.yml,
application-*.properties etc.). You can use resources with these file
names to configure global defaults and have them overridden by
application-specific files as necessary.
You should create application.properties or application.yml at the top level of configuration repository (if it is git or svn based). Don't forget to commit the changes.
This is how I have configured for my setup.
1 All Common properties across all services and environments will be in root->application.properties files
2 All Common properties across all environments specific to service will be root->service-X.properties files
3: Similarly, to have common properties across specific environment use env->application.properties file
server:
port: 8888
spring:
cloud:
config:
server:
git:
uri:[git repo]
search-paths: /,/{profile}/
Finally found a solution. It's buried in the issues at github ...
https://github.com/spring-cloud/spring-cloud-config/issues/32
It worked liked described. I only noticed, that you need to put the files in a /config folder to make it work. If you put it in the root the file ist used by the configserver itself and is not included in the config requests.
application.properties/application.yml will be shared across all applications.
application-DEV.properties/application-DEV.yml will be shared across all DEV environment applications. You can replace DEV with any spring profile.
{applicationName}.properties/{applicationName}.yml will be shared across the give application.
Does anybody knows if it is possible to expose more than 1 property file per application in Spring Cloud config server?
For example I would like to have defined in my git repo properties for the same app, but in different files:
myapp-customer-services.yml
myapp-products-services.yml
and have all those properties defined inside the files, exposed under "myapp".
No that's not possible currently. I'm not sure it really makes much sense to be honest, since you can easily clearly delineate different sets of properties within a YAML file using separate documents.
Yes it is possible to expose more than 1 property file per application in Spring Cloud config server
You can access it in you client by using following properties
first specify profile which you want
example
myapp-customer.yml
myapp-products.yml
spring.profiles.active=customer,products
spring.cloud.config.name=myapp