Version 1



    GitHub - kucerarichard/SaltedJBoss: SaltStack-based JBoss Cluster Mgmt via Pillar-driven Orchestration of Standalone Ser…




    The goal of SaltedJBoss is to create an ergonomically feasible way and flexible means to make big or small JBoss clusters composed of standalone nodes.


    Good enough 1.0 released.  Survived 8 node cluster rollout(16 node cluster ran out of memory when heap settings bumped),  not huge cluster but put in some production fixes, manual deployment failsafes(in the event of beacon failure,  which happened).  See repo also for a more complete writeup and code comments.   .  

    Wildfly devs please don't get rid of deployment scanner anytime soon..


    I recommend running Salt in tandem with RHQ/JBossON,  they both are good at some things and it never hurts to have more mgmt tools.







    JBoss Cluster

    Management of JBoss clusters is the goal. The difference is they are composed with standalone configuration rather than domain management or JBossON support.

    A standalone configuration has some advantages over domain mgmt and JON-based mgmt:

    • Deployment scanner support
    • Ease of debugging
    • Simplicity and leveraging strengths of JBoss
    • Dynamic compilation of JSPs to cluster
    • Ergonomically feasible/programmable deployment of large, independently managed clusters on many hosts/containers with multiple JVMs on each host/container(if desired)

    File-based configuration vs Salt JBoss7 Modules

    • State and Execution modules for JBoss are available in saltstack.
    • The JBoss7 Execution module is incorporated in SaltedJBoss
    • The JBoss7 State modules are not currently used.
    • JBoss has excellent support for file-based configuration so it is not necessary, or even possible, to channel all the config needed to build a cluster through the CLI.
    • This gives external management systems such as salt great access to JBoss for building servers.
    • The jboss7 and jboss7_cli execution modules are used for convenient functions such as "reload" the CLI functions are called from a generated command script which calls all the minions which form the cluster with the command.
    • The script uses a salt-call approach (remote execution of jboss7 module as a command directly on the minion) in order to be able to pass dynamic parameters to the command while on the master (that would otherwise be more cumbersome with a state file).




    Dynamic Pillars.


    For example,  should be possible to have even more flexibility in the Pillar by writing code in it:





        enableinstance: True

        status: running


        balanceraddr: '*'

        balancerport: 80


          - 123.34.56

          - 124.56.78

          - 123.34.23


        adgroupport: 23364

    {% if grain == dev or whatever %}


          dev: 'true'

          checkinterval: 5

    {% endif %}

        launchhost: jboss-test1.zzzzz.zzzzz

        launchdir: /usr/local/testcluster01-deployments

        launchhandler: jboss-deploy.sls

        jbosshome: /usr/local/jboss-eap-6.4


    {% for 10 .. 30 %}

          clusternode{{ i }}:

            portoffset: {{ i }}00

    {% endfor %}