Questions about configuration management (CAS 5.0)

[David Curry]

So I'm planning to jump right over CAS 4.x and take advantage of all the CAS 5.0 awesomeness (we're part of the 53% still running 3.5.2). Just for a change of pace, I thought I'd try actually reading all the instructions first this time and planning things out, instead of just jumping into "mvn clean package" and figuring it out as I go :-). And I must say, the new documentation site is excellent. So far it's been super-easy to find my way around and read about the things I want to know, and the linking from the top-level pages to the lower-level detail pages is really easy to follow. Combined with all the work you've done on intention-driven configuration, I'm enjoying the process of planning my CAS 5.0 deployment so much more than I did when I was working on CAS 3.x.

But, I have come up with a couple of questions...

At the bottom of the "Configuration Management" page (https://apereo.github.io/cas/development/installation/Configuration-Management.html) there are a couple of sections, "Reloading Changes" and "Clustered Deployments" that I'm not sure I completely understand.

First, reloading changes. The first paragraph there explains the embedded configuration server that notices when the application.properties file gets updated and reloads the properties. But then the second paragraph talks about an "adopter" needing to submit a request to CAS to refresh its current state to make the new properties actually take effect. But it doesn't say whether the embedded configuration server is considered an adopter. So here's my first point of confusion -- If I edit application.properties, will those changes take effect all by themselves just by editing the file? Or do I also need to manually visit the server dashboard page and click "Refresh"?

Next, clustered deployments. I understand that if the Spring Cloud Bus is configured, then when one of the servers reloads its properties, it will broadcast them out to the other servers on the bus, so that they all get them. But here's my next point of confusion -- Let's suppose I have 3 servers (A, B, and C) and change the properties file on A. The Cloud Bus will make sure those changes get propagated to the running instances on B and C, but will it also update the properties file on those two servers? Or do I need to make sure the files are kept in sync through some out-of-band process?

Thanks,

--Dave

[Misagh Moayyed]

First, reloading changes. The first paragraph there explains the embedded configuration server that notices when the application.properties file gets updated and reloads the properties. But then the second paragraph talks about an "adopter" needing to submit a request to CAS to refresh its current state to make the new properties actually take effect. But it doesn't say whether the embedded configuration server is considered an adopter. So here's my first point of confusion -- If I edit application.properties, will those changes take effect all by themselves just by editing the file? Or do I also need to manually visit the server dashboard page and click "Refresh"?

It depends. 

If you are running CAS in embedded mode via the -jar option, any changes you make to the externally-defined application.properties file must be refreshed on the dashboard. This is a current limitation of the UI; there is a screen that shows and lists all your properties, but it doesn’t yet let you edit them right there. If it did, it would auto-refresh everything and you wouldn’t have to worry about “where is my application.properties” file. This bit of UI enhancement will likely not make it to 5 for the GA release and so for the time being, you edit the file, and you refresh the config by pressing that button (or you send a POST to the relevant endpoint which is what that button does). We are working on that missing UI bit to make sure the screen can be edited, and that will likely make its way into subsequent patches post the 5 GA release. If it does, saving the property/change on the UI will do the refresh. One-stop shop. 

If you were running CAS in embedded mode via the native boot plugin, something we don’t yet have worked out, there is no refresh needed when you edit settings that are under src/main/resources of your configuration/overlay regardless of what those settings/files are. That directory is and will be monitored by the plugin constantly and resources there will be auto-loaded. This model is best suited for development. A refresh is still needed for anything that sits outside your “workspace” directory where your local CAS config files are. Same story with the UI. 

If you are running CAS in an external container, it’s the same as if you were running it with a -jar option. Refresh is needed. 

Next, clustered deployments. I understand that if the Spring Cloud Bus is configured, then when one of the servers reloads its properties, it will broadcast them out to the other servers on the bus, so that they all get them. But here's my next point of confusion -- Let's suppose I have 3 servers (A, B, and C) and change the properties file on A. The Cloud Bus will make sure those changes get propagated to the running instances on B and C, but will it also update the properties file on those two servers? Or do I need to make sure the files are kept in sync through some out-of-band process?

You still need to sync. Changes are not persisted on disk; they are only broadcasted and applied to the runtime running instance. Ideally, you are keeping track of those settings in a shared repository where you make a change in once place and its broadcasted to all nodes. I have tested this throughly with that repository being github. It’s amazing how Spring Cloud does it. You make a change, you commit and CAS auto-recognizes it and shoots a message to all nodes, who then recognize the change and update the running CAS instance invisibly. 

If you are not using a shared “repository”, as I said, you do need to sync. 

I have played around with the idea of using something other a properties file to keep these changes, specially for the implementation of that UI and specially when you don’t want to deal with source control. (Odd, but it happens). A lightweight DB table or a MongoDB collection of some sort as an option which would then allow you to centralize those settings better (and hey, you can write your own UI on top of that if you wanted to). 

HTH.  

And I’ll see about formulating something intelligent for the docs. Thanks for the feedback!

Thanks,

--Dave

--
You received this message because you are subscribed to the Google Groups "CAS Community" group.
To unsubscribe from this group and stop receiving emails from it, send an email to cas-user+u...@apereo.org.
To post to this group, send email to cas-...@apereo.org.
Visit this group at https://groups.google.com/a/apereo.org/group/cas-user/.
To view this discussion on the web visit https://groups.google.com/a/apereo.org/d/msgid/cas-user/2148dba1-c059-4c45-babe-4e6c48144924%40apereo.org.
For more options, visit https://groups.google.com/a/apereo.org/d/optout.

[David Curry]

Thanks for the detailed answers; that all makes sense.

The GitHub approach to storing the application.properties file(s) sounds pretty neat; especially if we were to ever do some kind of split on-prem/cloud deployment (which we have been kicking around but won't be in our first iteration).

But what do you do about storing passwords in those files? I see a shortish mention of Java Simplified Encryption in the Security Guide... is that how you handle it? If so, is that included out of the box, or will I need to include something in the Maven overlay? And (of course), is there any guidance about how to actually use it?

[Misagh Moayyed]

That is included OOTB. You do not need to do anything extra. 

You are to use this:

http://cloud.spring.io/spring-cloud-config/spring-cloud-config.html#_encryption_and_decryption

I created this issue to explain the above link better from the CAS perspective:

https://github.com/apereo/cas/issues/1907

Keep an eye on that one. Some notes about it will show up in the CAS docs. 

-- 
Misagh

To view this discussion on the web visit https://groups.google.com/a/apereo.org/d/msgid/cas-user/1439ec30-708f-43a4-bb43-00932ea64de7%40apereo.org.

[David Curry]

Ah... that's the web page I couldn't find (not knowing my way around Spring Cloud). Subject to actually trying it, it looks relatively straight forward.

Thanks!