I have a setup where I am using the following:
Spring Boot 1.5.13 with Spring Cloud Version Edgware.S3
I have Spring Cloud Config Server and my Spring Boot apps are its clients
Each app carries a bootstrap.yml with the config server uri and some other properties.
Running containers on a Docker Swarm
I am currently passing Swarm secrets to the clients via a custom script which reads the files put into /run/secrets/ and creating a /config/bootstrap.properties file. It ends up looking like this:
spring.cloud.config.username=user
spring.cloud.config.password=password
My Docker image's default command is then this:
java -Djava.security.egd=file:/dev/./urandom -jar /${appName}.jar --spring.cloud.bootstrap.location=file:/config/bootstrap.properties"
Great. This is working without a problem. The app, seemingly, reads:
The external bootstrap.properties to read in the config server's credentials
The classpath bootstrap.yml to read in the rest of the config client props
Fetches and reads in the config server's application-appName.yml
Then reads the bundled application.yml from the classpath
Now. I'm moving the apps to Spring Boot 2.0.3 with Finchley.RELEASE and well, this breaks.
What is happening now is:
The external bootstrap.properties is read in to get the config server's credentials
The classpath bootstrap.yml is SKIPPED entirely (UNEXPECTED!)
Fetches and reads in the config server's application-appName.yml
Then reads the bundled application.yml from the classpath
The problem is that the properties that were set in the internal bootstrap.yml are now missing for the app so it blows up on start. I've been able to reproduce it outside the container environment by doing the same thing; point the app to an external bootstrap.properties. If I copy over the bootstrap.yml properties into the bootstrap.properties, then it works just fine. Also, if I don't provide an external properties file, then the internal bootstrap.yml kicks in without a problem. So it's either one or the other!
I'v also tried modifying the bootstrap location to include the default locations but no luck:
-- spring.cloud.bootstrap.location=file:/config/bootstrap.properties,classpath:,classpath:/config,file:,file:config/
Any ideas where to look next? Maybe there is a new spring.cloud.config property I'm missing? Or can anyone confirm which behavior is the correct behavior? Assuming they fixed a potential loophole in Finchley then I can just put this to rest and look for another solution. If it's 'broken' in Finchley, I guess an issue report is in order?
Well, some more digging showed that it looks like this is the new behavior:
https://github.com/spring-projects/spring-boot/wiki/Spring-Boot-2.0-Migration-Guide
The behavior of the spring.config.location configuration has been fixed; it previously added a location to the list of default ones, now it replaces the default locations. If you were relying on the way it was handled previously, you should now use spring.config.additional-location instead.
It didn't look to be Spring Cloud specific but I had nothing to lose.
Changing my java command to use this new property did the trick:
--spring.config.additional-location=file:/config/bootstrap.properties
Thanks.
Related
I have a working spring boot application and I am trying to remove some properties from application.yaml file and read them from an embedded config server in the same app. At the moment, I am trying to read properties from file system through "native" profile type, and I am planning to later replace this with S3. Also, I am trying to read the configuration directly from backend repository as explained here https://docs.spring.io/spring-cloud-config/docs/current/reference/html/#_embedding_the_config_server , rather than connecting through an endpoint.
If you want to read the configuration for an application directly from
the backend repository (instead of from the config server), you
basically want an embedded config server with no endpoints. You can
switch off the endpoints entirely by not using the #EnableConfigServer
annotation (set spring.cloud.config.server.bootstrap=true).
I have introduced following changes to my existing application to achieve this.
Added following dependencies to pom.xml
spring-cloud-starter-config
spring-cloud-config-server
spring-cloud-config-client
application-dev.yaml
spring:
could:
bootstrap:
enabled: true
bootstrap.yaml
spring:
profiles:
active: composite
cloud:
config:
server:
composite:
- type: native
search-locations: file:C:\\Users\\chamila\\config-test\\config
# bootstrap: true
The required properties are saved in a different application-dev.yaml file at the above file path. I have not used #EnableConfigServer annotation from my app class, as I want connect directly without the endpoint.
However, still my program is failing to read the properties from the config-server. I tried setting spring.cloud.config.server.bootstrap=true and spring.cloud.bootstrap.enabled=true from both application-dev.yaml and bootstrap.yaml, but it didn't work?
Any idea what I am missing? I note that I never specified how to connect to the config-server in my application-dev.yaml file also. Is that an issue?
Any help is highly appreciated.
I created a sample project of an embedded Configuration Server which uses a custom repository:
https://github.com/taxone/embedded-config-server
The initial problem was that the custom EnvironmentRepository was not available via bootstrap, as described in this issue.
I followed https://cloud.spring.io/spring-cloud-config/reference/html/#_embedding_the_config_server and achieved the expected result.
Add spring-cloud-starter-bootstrap to your dependencies as suggested in https://github.com/taxone/embedded-config-server.
Make sure that composite profile is active when you start the app.
Verify that your native configuration is added by finding a log message from NativeEnvironmentRepository during startup.
(Optional) Remove spring.cloud.bootstrap.enabled from application-dev.yaml.
(Optional) Remove spring-cloud-config-client dependency as it is included in both spring-cloud-starter-config and
spring-cloud-config-server.
(Further steps) Use #RefreshScope on a spring bean to achieve dynamic properties. Requires POST actuator/refresh.
In Quarkus, We have properties file inside project itself called application.properties.
Is there any Quarkus way to define external properties file in my use case like i am developing a mail sender and i want to add recipients in future.
Is it possible to give application.properties outside at local and inject it at runtime?
You can add a configuration file in your application working directory under config/application.properties : https://quarkus.io/guides/config#overriding-properties-at-runtime
There is ongoing discussion to have more runtime configuration capabilities here: https://github.com/quarkusio/quarkus/issues/1218
You can achieve this by keeping .properties (or .yaml) in Spring Cloud Config Server.
It's really easy to set it up. It's is well documented in following link (official documentation):
Quarkus - Reading properties from Spring Cloud Config Server
As loïc says, you can follow the convention and create a config/application.properties. You can also use the property quarkus.config.locations to specify additional config locations. It can be defined at runtime like below
java -Dquarkus.config.locations=app-config/config.properties -jar my-app.jar
So I want to override some settings for all my microservices, so I create a git repo and an application.yml file for that.
Download registry jar from jhipster.
run it with the following command.
java -jar jhipster-registry-5.0.2.jar --spring.profiles.active=prod --spring.security.user.password=xxx --jhipster.security.authentication.jwt.secret=abcde --spring.cloud.config.server.composite[0].type=git --spring.cloud.config.server.composite[0].uri=https://github.com/xxx --spring.cloud.config.server.composite[0].username=xxx --spring.cloud.config.server.composite[0].password=xxx
The services communicate through feign client which takes its data from the application.yml. The settings look like this:
application:
external:
services:
service-name:
base-url: local
But when I run the jhipster registry pointing to this repo. I get the following error.
Origin: ...
Reason: The elements [] are left unbound
I tried using all kinds of combos for the file name. application.yml, application-prod.yml, application-dev.yml, service-name.yml and also application.yml
There doesn't seem to be a problem for other properties, such as for database password and url. Or even arbitrary chains like abc.abc.abc.abc="data", these work. I even played around and simply messed up the spellings like mistyping external, services and application.
When I misspelled application like aaaaplication. It doesnt give an error. Only when I include "application:" in my yml file jhipster throws an error.
Please confirm if I am correct in assuming that jhipster won't allow application to be overriden. And if yes then how can I override this?
I don't think its optimal to change all the services for this. So is there a workaround for this?
Trying to get a older version of Spring Boot running on Pivotal Web Services.
It needs to connect to a Eureka server. I have stood up a new Eureka server in the same space the Client App is running on in PWS.
As I don't have the code for the Client application (can't modify the application property/yml files), I need to configure the Client's Eureka client to connect to the new Eureka server using Environmental Variables.
Here is what I have tried:
In the Cloud Foundries 'manifest.yml' I currently have:
---
applications:
- name: <Client application name>
...
other non related settings
...
env:
EUREKA_INSTANCE_HOSTNAME: https://<pws route of eureka server>
This is not picked up.
It looks like that property is picked up like that:
https://jar-download.com/artifacts/org.springframework.cloud/spring-cloud-netflix-eureka-client/1.1.0.RELEASE/source-code/org/springframework/cloud/netflix/eureka/EurekaClientAutoConfiguration.java
I have tried a few variable names:
eureka.instance.hostname
EUREKA_CLIENT_SERVICEURL_DEFAULTZONE
eureka.client.serviceUrl.defaultZone
I also tried setting a SPRING_APPLICATION_JSON to contain these combinations in the same way in the manifest.yml.
None of them seem to get picked up.
Is there a different way that this can be done? Again, I don't have access to the code, only the Jar.
So its not pretty, but I was able to modify the application.properties files in the Jars using VIM to contain this setting:
eureka.client.serviceUrl.defaultZone=<pws route>/eureka/
Just made the Jar write-able, added that setting, saved and then cf push'd it up. Works. Not sure why the ENV did not work, but its not worth fixing. Everything in this Jar is ancient (Spring Cloud version 1.0). Its all going to get re-written anyway, just need the legacy version running somewhere stable while that work happens.
My Spring Boot app will have 4 different environments:
Local; running locally on my machine
Dev
UAT
Prod
When a new user registers for my app, the backend sends them an email to verify their address/account. In this email there will be a link; the user clicks the link which verifies them in the database and allows them to now login and use the app.
These links of course have to have the environment built into them:
Locally, the link might be http://localhost:9200/v1/data/accounts/verify?vt=12345
In dev the link might be: http://dev.myapp.example.com/v1/data/accounts/verify?vt=12345
In UAT the link might be: http://uat.myapp.example.com/v1/data/accounts/verify?vt=12345
In Prod the link might be: http://myapp.example.com/v1/data/accounts/verify?vt=12345
In all three environments, the hostname + port are different. Locally I specify localhost:9200 (both localhost + port). Non-locally I don't need to specify port because the app will be running on nodes behind a load balancer. In production I don't need an environment-specific subdomain like dev or uat.
In order for my emails to work correctly in all 4 environments, I need to set an environment variable that is then used by my email generator to generate links correctly.
I could use something homegrown, such as a custom property in application.properties like emailDomain, and set the property different in each environment's properties file.
But I feel like the smart folks that make up the Spring Boot community have probably already solved this problem for me...have they? Is there already a Spring Boot app property I can set that will take care of all this for me?
In the comments, I read that your main concern is being able to update the property without having to modify your .JAR/.WAR or changing some code.
This is possible since you can externalize your Spring boot configuration. If you check the Externalized Configuration docs, you can see that it looks for properties within:
OS environment variables.
...
Profile-specific application properties outside of your packaged jar (application-{profile}.properties and YAML variants)
Profile-specific application properties packaged inside your jar (application-{profile}.properties and YAML variants)
Application properties outside of your packaged jar
(application.properties and YAML variants).
Application properties packaged inside your jar (application.properties and YAML variants).
So, ideally, you can put an application.properties file next to your JAR, and update the properties in that file depending on the environment you run on.