Version 6

    GITHUB REPO

     

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

     

    GOAL

     

    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.

     

    ARCHITECTURE

    architecture.png

     

    Features

    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).

     

    NEXT STEPS

     

    Dynamic Pillars.

     

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

     

    clusters:

      testcluster01:

        bmanagement: 0.0.0.0

        enableinstance: True

        status: running

        maddress: 230.0.0.11

        balanceraddr: '*'

        balancerport: 80

        balancerallowfrom:

          - 123.34.56

          - 124.56.78

          - 123.34.23

        adgroupaddress: 224.0.1.106

        adgroupport: 23364

    {% if grain == dev or whatever %}

        jspconfig:

          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

        nodes:

    {% for 10 .. 30 %}

          clusternode{{ i }}:

            portoffset: {{ i }}00

    {% endfor %}