Skip to content

Configuration Automation

Jump to bottom
Siamak Sadeghianfar edited this page Jun 17, 2013 · 6 revisions

Three categories of configuration is required for applications running on JBoss EAP.

  • Generic JBoss EAP Configs: configs that are applied to JBoss EAP and affect the behavior of the app server. These configs are required regardless of the applications deployed such as management interface security configs.
  • Application-specific JBoss EAP Configs: configs that specific applications expect to be available on JBoss EAP such as datasource configs.
  • Application Configs: configs that changes the internal behaviour of applications deployed on JBoss EAP such as a back-end service endpoint address

The configs in each category are divided into two types:

  • Common: configs that are environment independent such as logging layout
  • Environment-specific: configs that change between environments such as binding address for JBoss EAP or datasource JDBC URL

Puppet modules can be used to managed the first two categories and parts of the application configs.

JBoss EAP and Application Configuration

Generic EAP Configs

These types of configs are handled by a Puppet module created specifically for installing JBoss EAP RPMs. The Puppet module also contains the configs required for the standard JBoss EAP installation which needs to be defined per organization. Various approaches such as CLI or XML editing/copying can be used for this purpose with their own pros and cons which needs to be determined for each particular usecase.

Taking advantage of Puppet parameterized classes, the values for environment-specific config can be determined at provisioning time through for example Foreman. Examples of such

Application-specific JBoss EAP Configs

In order to be consitent, Puppet can be used to managed application-specific configs as well. In order to avoid the overhead of DEV creating Puppet modules for their deployments, a config descriptor can be used to describe the config requirements of an application.The config descriptor will be consumed by the deployment tools (Maven and Jenkins plugins) to generate a Puppet module that applies the required config on JBoss EAP.

Taking advantage of Puppet parameterized classes and Foreman smart variables, the actual values for the environment-specific configs can be fed to the deployment process using Foreman's Environment/HostGroup/Host hierarchy for config inheritance as well as manually by the admin/deployer performing the deployment through Foreman.

Configuration Automation

Config Descriptor

DEV can describe their required configuration in an xml descriptor. The allowed configs in this descriptor depends on the requirement of the organization. Some probable config elements follow: System properties Data source configuration Logging handlers

Application can rely on having the defined system properties, datasource and logging handlers available in the upper environments where it will be deployed.

<?xml version="1.0" encoding="UTF-8"?>
<app-config xmlns="http://www.jboss.org/soe/appconfig/1.0" 
			xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
			xsi:schemaLocation="http://www.jboss.org/soe/appconfig/1.0 app-config-1.0.xsd"
			name="foo"
			version="1.0">
	<application-server>
		<system-properties>
			<property name="prop.key1" />
			<property name="prop.key2" />
			<property name="prop.key3" />
		</system-properties>
		<logging>
			<category name="com.jboss.foo" level="INFO" />
		</logging>
	</application-server>
</app-config>

The schema for the above config descriptor is available at https://raw.github.com/RedHatEMEA/soe-ng/master/lib/app-config-schema/src/main/xsd/app-config-1.0.xsd

Application Configs

Internal config of application are generally outside the scope of SOE. However using system properties in conjunction with the approach described above, it is possible to manage environment-specific configs that applications require internally.

The config descriptor mentioned above can be used by DEV to specify a list of required system properties and expect those properties to be available with appropriate values in each environment. The listed system properties are transformed into class parameters for the generate Puppet module. When the Puppet module is applied to a host, the Puppet module creates a properties file based on the system properties and feeds it in JBoss EAP during start-up.

${JBOSS_HOME}/bin/standalone.sh -P /var/lib/jbossas/standalone/configuration/application.properties

Be aware that the above approach is most appropriate for environments with one application per JBoss EAP instance. Alternatively, the system properties can be injected into standalone.xml through CLI or other means in order to support multiple applications on the same JBoss EAP instance.

Clone this wiki locally