Configuration management for properties - clue(s) needed

[David Curry]

So I'm building a development/planning a production high availability clustered setup of CAS 5.0 servers, and I'm trying to work out the best way to manage the property settings (/etc/cas/config/cas.properties). I've read the "Configuration Management" page, as well as the "Clustered Deployments" and "Reloading Changes" pages underneath it.

At least in our environment, once you get the properties figured out, they don't change very often. So the simplest solution might just be to continue keeping them in a master cas.properties file that gets copied manually to all servers in the cluster when it changes. But, while simplicity is an advantage, the disadvantages are (1) the potential for people to edit the files on the servers instead of the master resulting in the servers getting out of sync, (2) the potential for people to edit the files on the servers instead of the master and changes getting lost the next time someone updates from the master, and (3) the need to restart the servers when changes are made.

The documentation suggests using a Git repository to store the cas.properties file, and hooking Spring Cloud Config up to monitor that. With proper configuration and use of Git, this can solve the problem of different servers getting out of sync or changes getting lost, and the Spring Cloud configuration server (and Spring Cloud Bus) eliminate the need for restarting the servers. But, I have logistical problems -- while we do have an internal Git repository, it's not set up for high availability and we're not likely to do that any time soon, making it a single point of failure (unacceptable). I suppose we could use GitHub or Bitbucket to get around that, but we don't use them today and we're not sure we want to put our config files out there, even with the sensitive information encryption solution the documentation offers, just because of the potential for someone to screw up and upload an unencrypted version.

So... MongoDB. I'm already leaning toward using MongoDB for service registry persistence (just installing MongoDB on the same virtual machines running the CAS servers and configuring it to replicate among them). And I see that Spring Cloud Config can also be set up to use MongoDB as a source. Then when I change my properties in MongoDB, Spring Cloud Config and Spring Cloud Bus will do their things, just like with the Git setup.

But... I'm kinda learning as I go here on some of this stuff and so far I'm almost totally clueless about Spring Cloud and MongoDB.

I think I understand how things will work for the service registry piece -- the CAS documentation says that if CAS detects an empty MongoDB registry it will initialize it from the default JSON service definitions it already has, and then from there the service management webapp will take care of adding / changing / removing things in the (MongoDB) registry. So that seems pretty straight forward, and I'll be giving it a try as soon as I can teach myself how to install and configure MongoDB. :-)

But I don't see anything in the configuration management documentation analogous to this for properties. How do properties get added / changed / removed in MongoDB?

• Will the CAS admin screens update the database when you change properties (the documentation implies "no")?
• If yes to the above, then do the CAS admin screens give you access to all properties (I haven't tried them yet)?
• Is there some third-party application I'm supposed to be using?
• Should I be using the MongoDB shell (and if so, is there some guidance on doing that with CAS properties)?
  
• Something else?

Any clues that can be thrown my way would be much appreciated.

Thanks,

--Dave

[Misagh Moayyed]

But I don't see anything in the configuration management documentation analogous to this for properties. How do properties get added / changed / removed in MongoDB?

 

By you. Manually, much like the current .properties file.

·         Will the CAS admin screens update the database when you change properties (the documentation implies "no")?

Short answer is, no.

Long answer is no not in 5, but there is a pull request pending today that should allow CAS in follow-up releases to manage settings via the admin screens. This is very much a non-trivial task because property/setting sources can work in tandem at the same time. In other words, you could (not that you ever should) divide your settings across config files, Github, Mongo and Vault, etc and CAS will eventually find the setting. This sort of flexibility via Spring Cloud makes it difficult for an admin screen to save and manage settings, because it would need to know the target destination somehow.

·         If yes to the above, then do the CAS admin screens give you access to all properties (I haven't tried them yet)?

·         Is there some third-party application I'm supposed to be using?

·         Should I be using the MongoDB shell (and if so, is there some guidance on doing that with CAS properties)?

·         Something else?

At this point, your best bet would be to manually create the MongoDb database, collections, etc and stuff your settings in there. The docs do and should explain what the collection should be named, and what the JSON document should look like.

[David Curry]

Thanks for the clarifications, Misagh. I think for the moment then, I may just kick this particular can down the road and just copy the properties file around. It's not like I don't have plenty of other features and settings and options to play around with. :-)

--Dave