salt.states.jboss7

Manage JBoss 7 Application Server via CLI interface

New in version 2015.5.0.

This state uses the jboss-cli.sh script from a JBoss or Wildfly installation and parses its output to determine the execution result.

In order to run each state, a jboss_config dictionary with the following properties must be passed:

jboss:
   cli_path: '/opt/jboss/jboss-7.0/bin/jboss-cli.sh'
   controller: 10.11.12.13:9999
   cli_user: 'jbossadm'
   cli_password: 'jbossadm'

If the controller doesn't require a password, then the cli_user and cli_password parameters are optional.

Since same dictionary with configuration will be used in all the states, it may be more convenient to move JBoss configuration and other properties to the pillar.

Example of application deployment from local filesystem:

application_deployed:
  jboss7.deployed:
    - salt_source:
        target_file: '/tmp/webapp.war'
    - jboss_config: {{ pillar['jboss'] }}

For the sake of brevity, examples for each state assume that jboss_config is contained in the pillar.

salt.states.jboss7.bindings_exist(name, jboss_config, bindings, profile=None)

Ensures that given JNDI binding are present on the server. If a binding doesn't exist on the server it will be created. If it already exists its value will be changed.

jboss_config:

Dict with connection properties (see state description)

bindings:

Dict with bindings to set.

profile:

The profile name (domain mode only)

Example:

jndi_entries_created:
  jboss7.bindings_exist:
   - bindings:
      'java:global/sampleapp/environment': 'DEV'
      'java:global/sampleapp/configurationFile': '/var/opt/sampleapp/config.properties'
   - jboss_config: {{ pillar['jboss'] }}
salt.states.jboss7.datasource_exists(name, jboss_config, datasource_properties, recreate=False, profile=None)

Ensures that a datasource with given properties exist on the jboss instance. If datasource doesn't exist, it is created, otherwise only the properties that are different will be updated.

name

Datasource property name

jboss_config

Dict with connection properties (see state description)

datasource_properties

Dict with datasource properties

recreateFalse

If set to True and datasource exists it will be removed and created again. However, if there are deployments that depend on the datasource, it will not me possible to remove it.

profileNone

The profile name for this datasource (domain mode only)

Example:

sampleDS:
  jboss7.datasource_exists:
   - recreate: False
   - datasource_properties:
       driver-name: mysql
       connection-url: 'jdbc:mysql://localhost:3306/sampleDatabase'
       jndi-name: 'java:jboss/datasources/sampleDS'
       user-name: sampleuser
       password: secret
       min-pool-size: 3
       use-java-context: True
   - jboss_config: {{ pillar['jboss'] }}
   - profile: full-ha
salt.states.jboss7.deployed(name, jboss_config, salt_source=None)

Ensures that the given application is deployed on server.

jboss_config:

Dict with connection properties (see state description)

salt_source:
How to find the artifact to be deployed.
target_file:

Where to look in the minion's file system for the artifact to be deployed (e.g. '/tmp/application-web-0.39.war'). When source is specified, also specifies where to save the retrieved file.

source:

(optional) File on salt master (e.g. salt://application-web-0.39.war). If absent, no files will be retrieved and the artifact in target_file will be used for the deployment.

undeploy:

(optional) Regular expression to match against existing deployments. When present, if there is a deployment that matches the regular expression, it will be undeployed before the new artifact is deployed.

undeploy_force:

(optional) If True, the artifact will be undeployed although it has not changed.

Examples:

Deployment of a file from minion's local file system:

application_deployed:
  jboss7.deployed:
    - salt_source:
        target_file: '/tmp/webapp.war'
    - jboss_config: {{ pillar['jboss'] }}

It is assumed that /tmp/webapp.war was made available by some other means. No applications will be undeployed; if an existing deployment that shares that name exists, then it will be replaced with the updated version.

Deployment of a file from the Salt master's file system:

application_deployed:
  jboss7.deployed:
   - salt_source:
        source: salt://application-web-0.39.war
        target_file: '/tmp/application-web-0.39.war'
        undeploy: 'application-web-.*'
   - jboss_config: {{ pillar['jboss'] }}

Here, application-web-0.39.war file is downloaded from Salt file system to /tmp/application-web-0.39.war file on minion. Existing deployments are checked if any of them matches 'application-web-.*' regular expression, and if so then it is undeployed before deploying the application. This is useful to automate deployment of new application versions.

If the source parameter of salt_source is specified, it can use any protocol that the file states use. This includes not only downloading from the master but also HTTP, HTTPS, FTP, Amazon S3, and OpenStack Swift.

salt.states.jboss7.reloaded(name, jboss_config, timeout=60, interval=5)

Reloads configuration of jboss server.

jboss_config:

Dict with connection properties (see state description)

timeout:

Time to wait until jboss is back in running state. Default timeout is 60s.

interval:

Interval between state checks. Default interval is 5s. Decreasing the interval may slightly decrease waiting time but be aware that every status check is a call to jboss-cli which is a java process. If interval is smaller than process cleanup time it may easily lead to excessive resource consumption.

This step performs the following operations:

  • Ensures that server is in running or reload-required state (by reading server-state attribute)

  • Reloads configuration

  • Waits for server to reload and be in running state

Example:

configuration_reloaded:
   jboss7.reloaded:
    - jboss_config: {{ pillar['jboss'] }}