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:
6.2.x11In 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 development.properties and production.properties file.
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 development.properties and production.properties files with relevant values:
Your development.properties file would be:
cas.authn.accept.users=<value-for-development>
…and your production.properties file would be:
cas.authn.accept.users=<value-for-production>
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.include is 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.
If you have questions about the contents and the topic of this blog post, or if you need additional guidance and support, feel free to send us a note and ask about consulting and support services.
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.
Happy Coding,
Monday-Friday
9am-6pm, Central European Time
7am-1pm, U.S. Eastern Time
Monday-Friday
9am-6pm, Central European Time