I'm starting to use Spring Cloud Config and would like to give a way for clients to override properties that come from cofnig server. However, after reading https://docs.spring.io/spring-boot/docs/current/reference/html/boot-features-external-config.html, it isn't apparent when the Cloud Configuration applies.
I've also read http://cloud.spring.io/spring-cloud-config/spring-cloud-config.html and it talks about overrides. But they seem to be the opposite of what I want (those overrides are for overriding the client provided properties).
So, where does the Cloud Config fit in the ordering? Would I still be able to give a local application.properties file on the classpath to override certain Cloud Config properties?
The git commit/push process is part of the process, actually...Spring Cloud Config uses git to handle the config files, changes, auditing, etc., as git is ideally suited for that, & Config leverages those strengths.
If you're just looking for a way to expedite testing of config changes and are willing to accept the tradeoffs, you can use a local (or local network) repo for your config repository for testing. I realize this isn't what you're asking specifically, but it's an option that may help, assuming you're using the Config server app's application.properties to point to the underlying git repo. If so, you can override spring.cloud.config.server.git.uri on the command line like so:
java -Dspring.cloud.config.server.git.uri=${HOME}/testing/config-repo -jar your_jar_here.jar
This will allow you to tweak the config settings for client apps/services that obtain their settings from the Config server without affecting the production config files (even branches).
I hope this helps. If not, or if I've misunderstood your goals or constraints, please clarify (a use case or two might help me triangulate better, if you can share them) and I'll take another run at it. :)
Cheers,
Mark
Related
I have some properties in my microservice. They are changed a lot so I want to store them somewhere out of microservice so that I don't have to undeploy it again and again. One solution is to store them in database but it will be less efficient that way. Can you advise me a solution where I can store them?
Basically this microservice is used by a vast number of people. I want that file to be read ONCE when microservice is deployed (unless or until there is some change in the file) to minimize the calls.
You should use Spring Cloud Config which enables to use a centralized server which exposes a Git Repo which you can use to store environment specific configuration files (application.properties)
You should go with Centralized configuration, spring cloud supports config server, It is highly recommended for microservice architecture.
For reference: https://spring.io/guides/gs/centralized-configuration/
Basically, you have a centralized place to store all the configurations and don't need the redeploy the application every time you change the configs.
NOTE: in case you change the db properties then probably you need the restart the service
Is there any way by chance to make spring config server to clone only specific path instead of whole git repo? When I'm running it on production I may not want my entire code base repository to be cloned to some location as it is always a risk. I've done my research and couldn't figure out ways to clone only specific paths of git repo.
One solution is to host the configurations in a seperate repo. But that would defeat the purpose of one code many deploys suggestion of 12factor.net.
Another possibility is to copy the properties into config server's classpath and then to use native profile to load them. But this would defeat the purpose of Spring ConfigServer.
Also kindly do clarify What would be the best way to run spring config server on a production?
You should be separating your code base from your configuration settings.
Repo 1: Your App Code
Repo 2: Your Spring Cloud Config Server Code
Repo 3: Your configuration settings
When you're deploying, you're deploying the code. Not the configuration. A configuration change should not require a new deployment. A new deployment might require an updated configuration change, but the two are generally decoupled.
Configuration can be dynamically updated while code is running. This is completely separate from updating code and deploying the app. That's the whole point of externalized configuration.
TL;DR: You're looking at "one code many deploys" wrong. Configuration is externalized.
I took this straight from 12factor.net
Apps sometimes store config as constants in the code. This is a violation of twelve-factor, which requires strict separation of config from code. Config varies substantially across deploys, code does not.
Even though you are no longer storing them as constants but still in the same repository is not enough separation from the code. Use a separate repository for configurations.
The role of the Config Server while using Spring Cloud Config seems to be pretty dumb and hosting it seems to be an unnecessary overhead. Is there a way to get the Clients to directly read configs from the git repo?
You can let Spring Boot look at specific locations for the config files: https://docs.spring.io/spring-boot/docs/current/reference/html/boot-features-external-config.html#boot-features-external-config-application-property-files
If you set this location to your cloned git repo (checked out on the branch you need) and solve the update from the origin repository, this might work.
It is achievable via the embedding config server approach
Do refer to Embedding The Config Server section
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 a centralized configuration for spring boot service. I followed this link to make it.
I have configServer and configs two separate project. Configs have several properties files. And configServer reading it and rendering to other services.
Now I want to make configs UI based.
e.g.
application.properties of configs which is hosted at git.
logging.path=logs
logging.level.root=INFO
logging.level.org.springframework.boot.autoconfigure.security=INFO
It`s UI should be
logging.path as key text box for value( logs ).
Is there any example for it. Any help will be appreciated.
Thanks.
Since you mention using text box in your post, I'm assuming that by UI you mean GUI.
While I'm not aware of any examples (and you do not specify whether you want to have a destktop or web application) if you're using git to store configuration, your app needs to:
Checkout the git repo with configuration (using JGit for example)
Load properties files generate edit window for each file (something
similar to what IntelliJ does for environment variables in run
configurations perhaps)
Save edits to files
Commit and push changes (again using JGit or a similar library)
I want to use spring cloud config to externalise application properties. I have configured config-server and client, but i don't want to use git(enterprise) as source, this is due to the fact that git may be down for the maintenance. Therefore, i thought about releasing application properties to nexus as application.properties.tar.gz and do the following:
1.) When config-server starts, download the release version from nexus and then unpack the tar.gz to a file system on the server where config-server is running.
2.) The config server which will pick the unpacked properties files.
Please note that the nexus url, application.properties.tar.gz version and location are all passed as VM options to config server.
Is this a sensible option? if this not best option, please could you suggest any other options?
Thanks
kankalam
Unless the Git server is down for maintenance so frequently, I wouldn't go with that option, it seems to be an overkill. Also the Nexus server might go down, so there's no advantage on doing that.
The config server does not read the configuration from the repo once and again, the repository is cloned when configuration is requested. From the docs:
The default strategy for locating property sources is to clone a git
repository (at spring.cloud.config.server.git.uri) and use it to
initialize a mini SpringApplication. The mini-application’s
Environment is used to enumerate property sources and publish them via
a JSON endpoint.
With that in mind, you need to check that the git server you use is available before you start the application or before you refresh its context. If you think it might be a problem, you still have two options:
Set up a dedicated Git server for your application (Check out Gogs as a lightweight option).
Go the "native" way and load the files from the file system. This way you don't have a version control of the configuration files, but you could do it separately into your project.