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
Related
I have 3 microservices on my server Customer, Order and Shipping. I want these 3 services to use the same configuration from the config server. According to the spring cloud document, they said that
The HTTP service has resources in the form:
/secret/{**application**}/{profile}
/secret/{**application**}
/secret/{**defaultContext**}/{profile}
/secret/{**defaultContext**}
where the "application" is injected as the **spring.application.name** in the SpringApplication
so If I want these 3 services to use the same configuration I may have 2 options either use the same spring.application.name, which I don't want to do that, or create a configuration file for each service. It would be nice if I can use the same configuration file for every services since it's easy to maintain and update. Is it possible to do that?
update:
I may need to improve my searching skill lol. I found this document that provides an example on how to do that. Basically, all you need to do is to name the configuration file as application and it will be available to every services.
https://cloud.spring.io/spring-cloud-config/multi/multi__spring_cloud_config_server.html#spring-cloud-config-server-vault-server
I am implementing a Spring Boot application which will be providing a multitenant environment. That is achieved in my case by using a database schema for each customer. Example see this project.
Now I am wondering how to implement tenant-specific configurations. I am using #ConfigurationProperties to bundle my property values, but these are getting instantiated once and not for each tenant.
What if I would like to use Spring Cloud Config with multiple tenant specific git repository as an configuration backend. Would it be possible when using a jdbc backend for Spring Cloud Config?
Is there any way with default Spring mechanisms or do I have to implement a database based configuration framework myself?
Edit: For example I have two tenants called Tenant1 and Tenant2. Both are running over the same application in the same context and are writing in the database schemes tenant_1 and tenant_2.
Identification of tenants is happening over keycloak (see Spring Keycloak multi tenant example). So I identify the tenantId from the jwt token and select the database connection like described here.
But now I would need the same mechanism for #Configuration beans. Since #Configuration beans are as far as I know Singletons, so there is always ONE configuration per application scope, and not ONE configuration per tenant.
So using Spring Cloud Config Tenant1 is using https://git-url/tenant1, Tenant2 is using Hashicorp Vault as backend and perhaps Tenant3 will be using a jdbc based configuration backend. And all of that in ONE (of course scalable) application.
In case your application uses tenant specific files (html templates etc), the following can be applied. As I have used the below approach for handling many tenants and works fine and easy to maintain.
I would suggest that you maintain a consistent configuration source (JDBC) for all of your tenant configurations. This helps you have a single source that is cacheable and scalable for your application. Also, you could have your tenants navigate to a configuration page to manage their settings and alter them to suit their needs at any point of time on the fly. (Example Settings: Records Per Page, Theme, Logo, Filters etc...)
Having the tenant configuration in files in git will be a difficult task when you wanted to auto-provision tenant's when they sign-up as it will involve couple of distributed services. Having them in a TenantSettings table with the tenantId as a column could help you get the data in no time and will be easy.
You can use Spring Cloud Config for your scenario and it is adoptable. It is easily configurable and provides out of the box features. For your specific scenario, you can have any number of microservices running yet all controlled by one Spring Cloud Config Server which is connected to one Git Repository. Your all microservices are asking configuration properties from Spring Cloud Config Server and it is directly fetching properties from Git Repository. That repository can have multiple property files. It can hold common properties for all the microservices or specific service based configuration properties. If you want to keep confidential properties more securely, that is also made possible via HashiCorp vault. I will leave an image below for you to get a better idea about this concept.
In the below image, you can see the Git Repository with common configuration property files and specific configuration property files for different services yet in same repository.
I will add another image for you to get a better idea how does this can be arranged with application profiles as well.
Finally I will add something additional to show the power of Spring Cloud Config and out of the box features it allows us to play with. You can automatically refresh configuration properties in running application as well. You can configure Spring Cloud Config to do that. I will add an architectural diagram to achieve that.
References for this answer is taken from Spring in Action, Fifth Edition
Craig Walls
It's well understood that in a microservices architecture, configuration must be externalized.
Tools like zookeeper, etcd or consul are excellent options to store that configuration. However a new layer on top of those services is required in order to provide new functionalities that are fundamental in a configuration server. Ex. versioning; change history; "draft" / published configuration, etc...
I've found spring config server, which is an interesting project and addresses all these concerns using git for handling the above mentioned requirements. However, I'd like avoid using git due to additional required setup. ex. replication, etc...
Do you know any other options other then spring config server?
Our findings have been the same - configuration must be externalized and the notion of "code as config" through the lessons learned from implementing time consuming Puppet/Chef systems.
We're building a microservices and API orchestration system at LunchBadger. We also uses git - but it's encapsulated into our system that we provide as a service, because we want configuration to be externalized AND dovetail into whatever CI/CD pipeline infrastructure you may have or are looking to adopt. We also provide visualization on top of microservices and APIs so that you can get an idea of the topology of your once monolithic app in the form of many microservices.
You can look into Microconfig.IO and it's Microconfig Server. It's deployed via docker and configured via 3 env vars. It still use git repo for config storage, but that's actually a proper way to go. As a bonus you get a powerful templating functionality designed explicitly to handle app configuration
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
I have been playing with Spring Cloud Config and like many of the ideas I see there. I would like to better understand how its creators intended on it being used though.
Lets say that I have several services that support a larger API. Because these services are independent from each other, their source is managed in separate repositories. This allows us to version them and deploy them separately from one another. Today, their properties are managed individually.
I like the idea of having a single config server provide all of the configuration information for the individual applications/services that support this larger API. Looking at the default implementation of EnvironmentRepository (which is GIT based), I would have to have a single repository with all of my application config files in it. Because they all live within the same repository, they would all be managed/versioned together in a single place.
How do I make both models work with each other? Would it be better to have a repository per application instead of one for all applications? What are your thoughts?
-Joshua
It might just be a detail of the implementation of the EnvironmentRepository. See here for some discussion on how and when that might happen.