SpotiByeAds
SpotiByeAds copied to clipboard
daspartho
State of configuration properties
With more and more properties being added, it's getting very difficult to manage all the properties in a clean way. We have come across multiple issues with docker properties builders, and the complexity will only get worse as more are added. There is also an issue with redundancy, as can be seen with the mongo settings that are repeated for all the collectors, as well as the API. @Mpluya had opened a pull request #1138 to utilize spring cloud config, which would definitely reduce the amount of redundant properties. It could also remove the need for the docker properties builders which has a lot of complexity in the scripts. We have been talking about this, and our ideal state would be below.
Phase 1: Add the dependency for spring cloud config. We could add the codebase for a spring cloud config server to Hygieia's codebase, as seen in #1138 , or we could have that outside the project all together. We could then let the cloud config server manage all the properties, and have those loaded on startup.
Phase 2: Begin to shift properties from the cloud config server to an admin page on Hygieia's UI. The end state would ideally be the cloud config server having the mongo properties, and then each collector could get the other properties from the database after connection. This would allow you to modify things like jenkins servers, or gitlab host from the UI, instead of properties files. This would not need to be done all at once, and could potentially be moved over in parts. This would remove the need for the properties builder, and potentially the need for dockerfiles altogether through use of docker maven plugin configuration.
Would appreciate some feedback and your thoughts.
@brennanananan @Mpluya @tabladrum @amitmawkin @satishc1 @nireeshT @MarkRx
@rob-miller-777 Phase 2 aligns with what we had in mind...storing the app properies in mongo and being able to control it from the admin page. Was there a reason why you want to move all properties to spring cloud config and then move them into mongo... instead of directly moving them to mongo? Why not move just the db properties to the cloud config server as phase 1? And phase 2 move the app properties to mongo.
That works as well, just thought it might be easier to move all the properties at once, and then pull the ones we can into the database. Just don't want to have properties being set in three different places.
Yea I've wanted this for a while. I had started to build it with system properties but those got removed somewhere :). If possible see if you can create the page dynamically without tying the implementation to each collector.
As for managing the properties I would just put them into the API server. No need for yet another server that needs to be spun up.
We have been going down the path of embedding a cloud config server into the API, however we have come across quite a few reasons why that could get messy.
-
Context Root - The context root of the application needs to be set to "/api" for the UI to work properly, which would mean all the collectors would have to get their config properties from "http://localhost:8080/api/locationToConfig". This is not a deal breaker, but just doesn't feel great.
-
Security - If you want to lock down your cloud config server using a username and password, some work would have to be down to allow this to happen since the API only accepts JWT tokens, and refuses basic auth.
-
Performance - The API is one of the heaviest hit apps in the suite already, making it the config server would only add to the load. It could also make having multiple API's and load balancing them tricky to manage. Also, if you decide to use an external cloud config server, you would have an unused one running within your API.
-
Dependency on API - If you are starting up all the apps at the same time, the API would needed to be started first for the cloud config server to be available for all the other apps. This means all the collectors would have a dependency on the API, which they don't currently have.
I like the idea of each component having it's own set of responsibilities, and I would rather not have the API responsible for too many things within the application.
@rob-miller-777 For "2. Security" ...Working on a PR for basic auth...should be available soon.
Anyone have issues with us removing the docker properties builders altogether? They are not needed using the cloud config server and it would get ugly trying to make running them conditional.
@rob-miller-777 @MarkRx @tabladrum Could talk about it during the conf call tomorrow. If someone doesn't use the cloud config server, they might have issues if we take out the docker props.
I still am in favor of putting it in the API. The purpose of an API layer is to do this very thing. Hence you will see that existing SDLC tools all have config rest endpoints within their API layers. Plus by having it in the API you can more readily interact with model changes that need to happen when a config changes. Suppose a config change requires updating existing documents. How would you do that in a separate server without rewriting the business logic?
The context root problem is easy to fix and the config server should only be accessible by the admin role. A few more config calls isn't that much of a problem and performance really is an issue just use horizontal scaling of the API and UI layers. You'll have a dependency either way - API or cloud config server.
As for docker properties (as well as command line properties) you will need a phase in period. Phase 1 could be to insert all the properties data into config objects when the collectors start that is accessible but not modifiable by the UI. After some time has passed turn on modification and remove the command line props. If the config is going to go into the database then it should be all or nothing - starting with command line properties should be removed.
Just so we are on the same page, when we create the admin functionality for making configuration changes, I am all for those calls being in the API app. The cloud config server is just a standalone server that reads configuration files from a git repo, and serves them up to applications asking for them. Our end goal is to have a cloud config server that manages all the configuration that won't change, such as Mongo connection settings. Anything we want to be dynamic, Sonar servers, Jenkins servers, etc..., would be stored in the MongoDB, and modifiable and retrievable through the UI/API.
Also, we can't store the Mongo connection information inside Mongo for obvious reasons, so we would need some way to get it to the application. I'm not saying cloud config is the only way, but it is super easy to setup, and offers some awesome functionality. The same config server can hold the connection information for all environments of Hygieia your organization would have, and can give you the appropriate mongo info based on your spring profile.
What if we were to not include a cloud config server inside the codebase, but just added the 1 dependency necessary to the 'core' project, that would make all the apps look for a cloud collector on startup. You would just need to pass the apps the name of the application, and uri of the config server at startup. We could also make using the properties builder optional somehow, because you wouldn't need both. I could get a branch out there showing what that would look like if you wanted to see it, really shouldn't be more than a couple file changes.
Take a look at this. All I did was add the cloud config dependency which will trigger spring to look for a cloud config server at startup of all the apps, if none are found it continues on normally. I also added a condition to the properties builder to skip if a property is set so it is no longer required if you plan on utilizing cloud config. So the only real difference here is it no looks for a cloud config server on startup, but if not found, no change. All you would have to do for the cloud config server to work is provide the spring.application.name, which corresponds to the properties files the config server holds. And also spring.cloud.config.uri if it exists anywhere besides http://localhost:8888, which is the default location.
https://github.com/capitalone/Hygieia/compare/master...StateFarmIns:simpleConfig?expand=1