CAS allows you to externalize your configuration settings so you can work with the same CAS instance in different environments. You can use properties files, YAML files, environment variables and command-line arguments (just to name a few!) to externalize and provide configuration. These strategies present a very flexible and powerful way to manage CAS configuration for production deployments in a variety of use cases. This is a short blog post on how to manage CAS configuration across tiers and avoid duplication of settings as much as possible.
Our starting position is based on:
In most cases, when you run CAS in standalone mode specially, the default configuration directory on the filesystem (i.e.
/etc/cas/config) may include
(cas|application).(yaml|yml|properties) files that can be used to control behavior. You could design your configuration management scheme such that all common properties across all deployment environments and tiers are managed inside the likes of
cas.properties file, while tier-specific settings are separated out into their own individual configuration file, such as
For example, let’s suppose that there are two different deployment environments for development and production where each should contain a different value for the CAS setting
cas.authn.accept.users. To achieve this, this setting needs to be extracted from the common
cas.properties file and be put inside
production.properties files with relevant values:
development.properties file would be:
production.properties file would be:
Finally, you need to make sure the correct configuration profile is activated when CAS is running. One way to achieve this would be to pass along the
spring.profiles.include parameter as a system property when CAS is run, with a value of the configuration profile appropriate for the tier.
For example, to run with a development profile:
java -jar -Dspring.profiles.include=development build/libs/cas.war
…and to run with a production profile:
java -jar -Dspring.profiles.include=production build/libs/cas.war
spring.profiles.includeis passed directly on the command-line. If you are deploying CAS using an external server container, the setting can be passed to CAS as an environment property as well to make things slightly more comfortable.
Study this reference for more details.
I hope this review was of some help to you and I am sure that both this post as well as the functionality it attempts to explain can be improved in any number of ways. Please know that all other use cases, scenarios, features, and theories certainly are possible as well. Feel free to engage and contribute as best as you can.