I want to deploy my spring boot in a distributed environment. In general what is the best practise followed?
1.Each node of distributed environment having its own application.properties
2.All nodes of distributed environment sharing one application.properties
It is my first spring boot project, please dont kill me for this question :P
Many options are possible depending on your needs, some are trivial, others are more complicated but more flexible.
For the beginning, you can keep the configuration inside the spring boot application, not the ideal way of course, but its dead simple. You can place application-local.properties, application-production.properties, etc inside your resources folder and run the spring boot application with active profiles for the environment you need.
Another, more advanced setup is using the configuration file but keeping it outside the application. Here you'll deploy this configuration file separately from the application, and here many options possible, including shared filesystems, automatic deployment, etc. You can run spring boot application with --spring.config.location=<path to configuration file>
Now if you want to keep configurations in a git repository or filesystem and you have many microservices in your organization, managing them becomes a mess. So in this case, you can check configuration servers. Spring boot comes integrated with configuration server which is a part of spring cloud project. You can find here more information.
This is by far the most advanced setup - you can even change configurations dynamically and not restart the spring boot microservices (google for Refreshable beans in spring boot configuration). Moreover you can keep the configuration in git repository and it will automatically be able to work with it.
There are other solutions, maybe less integration with spring boot applications, but can be considered if you already use them in your organization: etc.d, consul, and so forth.
Usually, people when entering spring boot world start with the first or second option and then adopt the third option of one of its alternatives.
Personally I would try using a configuration server: Centralized Configuration. Basically you keep your configuration files in a git repo with a relatively simple Spring Boot app on top of it, which your other Spring Boot apps can connect to and ask for configuration.
Also, in combination with the actuator it also gives you the ability to change the configuration on-the-fly without restarting your application.
All of the two strategies:
it depends what you want to achieve.
In the first case I suggest to follow the Single Host Per Service Pattern and provide your spring boot app as a docker container and then deploy it on an orchestrators like AWS ECS, Kubernetes, Swarm and so on even provide a single VM per service may be a solution but I suppose that may to expensive.
The benefits hear was that our application is usable without other effort on develop since that you have all the configuration near to your code, any change of configuration in this pattern will be a new deploy that will create a new docker image on your docker registry. In this way you can prevent the configuration drift and all and all the replicas will be updated and consistent you probably will use canary deploy or blue green deploy pattern.
The second strategy brings you to have a similar configuration pattern of many PAAS like Cloud Foundry and Openshift. All the Application replicas will share one single configuration entrypoint.
In case of Spring with the Spring Cloud, you may be choose Spring Cloud Configuration Server. In this case all the application will ask the configuration to a server, the server can be discovered whit an embedded client that will try to retrieve the configuration or through a discovery service system like Netflix Eureka or Consul.
The benefit in this case is that you can scale dinamically the number of instance of the config server will be the discovery system to provide all the replica that was registred. In the case of a configuration server you can benefit of many configuration storage like, file system, SVN, GIT or recently JDBC. More important you can benefit of the special @RefreshScope that will create your bean as a proxy and will you permit to reshresh the configuration on hot via actuator endpoint /actuator/refresh with the last Spring Cloud (Finchley) or /refresh with the previous Spring Cloud version, even Spring Cloud Bus can be used to propagate the reshresh event. If you use zuul the routes will be updated in case of changes and refresh, in this way you can be used to implements blue green deploy or canary deploy strategy.
I hope that it can be usefull for you
