Connecting the host controller to the domain controller

In this recipe, you will learn how to connect the host controller to the domain controller. We will refer to the domain controller as master, while we will refer to the host controllers as slave.

Getting ready

The purpose of this recipe is to show how to run a domain controller, and a series of other host controllers (we will use two host controllers) that connect to it. Whether the domain controller is on the same machine or on a different one, the connection type is meant to be "remote".

For the recipe, we will simulate two machines defining different configuration folders for each server that we are going to use. This is also a good practice for the development environment, as you can test a pseudo production scenario. Nevertheless, as we will have a Host Controller process running along with a Domain Controller process, and because both are responsible for remote management, with the management interfaces settled by default to listen on localhost:9990, we will have to bind them differently for each host controller.

In Chapter 2, Running WildFly in Standalone Mode, we saw how to run multiple WildFly instances on the same machine but with different IPs or port numbers. Here we have to do the same thing. For brevity, we will see just how to bind the host controllers on different ports.

Lastly, the host controller that connects to the domain controller needs to be authenticated. For this reason, we will need to create a new user by running the add-user.sh script, providing the information as depicted in the following screenshot:

This user belongs to the ManagementRealm, the same that was used in Chapter 1, Welcome to WildFly! to create the wildfly user in order to access the Web Console.

Keep note of the last line, the characters in red, that we will use later in the recipe.

How to do it…

First we need to create the Domain Controller and two Host Controller configuration folders. Let's create the structure of our directories:

1. Open your terminal and type as follows:

   $ cd $WILDFLY_HOME
   $ cp -a domain master
   $ cp -a domain slave-1
   $ cp -a domain slave-2
   $ mv slave-1/configuration/domain.xml slave-1/configuration/domain.xml.unused
   $ mv slave-2/configuration/domain.xml slave-2/configuration/domain.xml.unused

2. Now open the domain.xml file of the master directory and replace the server-groups declaration with the following XML code snippet:

   <server-groups>
       <server-group name="server-group-REST-app" profile="default">
           <jvm name="default">
               <heap size="64m" max-size="512m"/>
           </jvm>
           <socket-binding-group ref="standard-sockets"/>
       </server-group>
       <server-group name="server-group-SOAP-app" profile="default">
           <jvm name="default">
               <heap size="64m" max-size="512m"/>
           </jvm>
           <socket-binding-group ref="standard-sockets"/>
       </server-group>
   </server-groups>

3. Here we are simulating a server group dedicated to host applications targeting the RESTful technology, and another server group dedicated to host applications targeting the SOAP technology. This is just an example. A server group might match with a particular application, or a technology (thus more applications); the choice is up to you. My suggestion is to be as consistent as possible when making such decisions.
4. Edit the host.xml file of the master directory and remove the entire servers declaration. Once done, run the master as follows:

   $ ./bin/domain.sh -Djboss.domain.base.dir=master

5. The log should look as follows:

   08:44:53,589 INFO  [org.jboss.modules] (main) JBoss Modules version 1.4.2.Final
   08:44:53,730 INFO  [org.jboss.as.process.Host Controller.status] (main) WFLYPC0018: Starting process 'Host Controller'
   [Host Controller] Java HotSpot(TM) 64-Bit Server VM warning: ignoring option MaxPermSize=256m; support was removed in 8.0
   [Host Controller] 08:44:54,319 INFO  [org.jboss.modules] (main) JBoss Modules version 1.4.2.Final
   [Host Controller] 08:44:54,503 INFO  [org.jboss.msc] (main) JBoss MSC version 1.2.4.Final
   [Host Controller] 08:44:54,543 INFO  [org.jboss.as] (MSC service thread 1-7) WFLYSRV0049: WildFly Full 9.0.0.Beta2 (WildFly Core 1.0.0.Beta2) starting
   [Host Controller] 08:44:55,145 INFO  [org.xnio] (MSC service thread 1-5) XNIO version 3.3.0.Final
   [Host Controller] 08:44:55,147 INFO  [org.jboss.as] (Controller Boot Thread) WFLYHC0003: Creating http management service using network interface (management) port (9990) securePort (-1)
   [Host Controller] 08:44:55,155 INFO  [org.xnio.nio] (MSC service thread 1-5) XNIO NIO Implementation Version 3.3.0.Final
   [Host Controller] 08:44:55,262 INFO  [org.jboss.remoting] (MSC service thread 1-5) JBoss Remoting version 4.0.8.Final
   [Host Controller] 08:44:55,301 INFO  [org.jboss.as.remoting] (MSC service thread 1-1) WFLYRMT0001: Listening on 127.0.0.1:9999
   [Host Controller] 08:44:56,312 INFO  [org.jboss.as.controller.management-deprecated] (Controller Boot Thread) WFLYCTL0028: Attribute enabled is deprecated, and it might be removed in future version!
   [Host Controller] 08:44:56,381 INFO  [org.jboss.as.controller.management-deprecated] (Controller Boot Thread) WFLYCTL0028: Attribute enabled is deprecated, and it might be removed in future version!
   [Host Controller] 08:44:56,387 INFO  [org.jboss.as.controller.management-deprecated] (Controller Boot Thread) WFLYCTL0028: Attribute default-stack is deprecated, and it might be removed in future version!
   [Host Controller] 08:44:56,400 INFO  [org.jboss.as.controller.management-deprecated] (Controller Boot Thread) WFLYCTL0028: Attribute enabled is deprecated, and it might be removed in future version!
   [Host Controller] 08:44:56,413 INFO  [org.jboss.as.controller.management-deprecated] (Controller Boot Thread) WFLYCTL0028: Attribute enabled is deprecated, and it might be removed in future version!
   [Host Controller] 08:44:56,419 INFO  [org.jboss.as.controller.management-deprecated] (Controller Boot Thread) WFLYCTL0028: Attribute default-stack is deprecated, and it might be removed in future version!
   [Host Controller] 08:44:56,710 INFO  [org.jboss.as] (Controller Boot Thread) WFLYSRV0060: Http management interface listening on http://127.0.0.1:9990/management
   [Host Controller] 08:44:56,710 INFO  [org.jboss.as] (Controller Boot Thread) WFLYSRV0051: Admin console listening on http://127.0.0.1:9990
   [Host Controller] 08:44:56,711 INFO  [org.jboss.as] (Controller Boot Thread) WFLYSRV0025: WildFly Full 9.0.0.Beta2 (WildFly Core 1.0.0.Beta2) (Host Controller) started in 2825ms - Started 50 of 52 services (15 services are lazy, passive or on-demand)

   There are no running servers at all.

   Now it's time to configure our first slave, slave-1.

6. Edit the slave-1/configuration/host.xml file and do the following:
   • Name the host as slave-1: <host name="slave-1" xmlns="urn:jboss:domain:3.0">
   • Add the hostcontroller user's secret values inside the ManagementRealm definition:

     <server-identities>
         <secret value="aG9zdGNvbnRyb2xsZXIuMjAxNQ=="/>
     </server-identities>

   • Change the port number for the management-interfaces:

     <management-interfaces>
       <native-interface security-realm="ManagementRealm">
       <socket interface="management" port="${jboss.management.native.port:19999}"/>
         </native-interface>
           <http-interface security-realm="ManagementRealm" http-upgrade-enabled="true">
             <socket interface="management" port="${jboss.management.http.port:19990}"/>
          </http-interface>
     </management-interfaces>

   • Use a remote domain-controller:

     <domain-controller>
         <remote host="${jboss.domain.master.address}" port="${jboss.domain.master.port:9999}" security-realm="ManagementRealm" username="hostcontroller"/>
     </domain-controller>

   • Define the hosts:

     <servers>
       <server name="REST-server-one" group="server-group-REST-app">
         <jvm name="default">
           <heap size="64m" max-size="256m"/>
         </jvm>
       </server>
     </servers>

7. You should end up with a file that looks like the following XML code snippet:

   <?xml version='1.0' encoding='UTF-8'?>
   <host name="slave-1" xmlns="urn:jboss:domain:3.0">
     <extensions>
       <extension module="org.jboss.as.jmx"/>
     </extensions>
     <management>
       <security-realms>
         <security-realm name="ManagementRealm">
           <server-identities>
             <secret value="aG9zdGNvbnRyb2xsZXIuMjAxNQ=="/>
           </server-identities>
           <authentication>
             <local default-user="$local" skip-group-
               loading="true"/>
             <properties path="mgmt-users.properties" relative-
               to="jboss.domain.config.dir"/>
           </authentication>
           <authorization map-groups-to-roles="false">
             <properties path="mgmt-groups.properties" 
             relative-to="jboss.domain.config.dir"/>
           </authorization>
         </security-realm>
         <security-realm name="ApplicationRealm">
           <authentication>
             <local default-user="$local" allowed-users="*" 
             skip-group-loading="true"/>
             <properties path="application-users.properties" relative-to="jboss.domain.config.dir"/>
           </authentication>
           <authorization>
             <properties path="application-roles.properties" relative-to="jboss.domain.config.dir"/>
           </authorization>
         </security-realm>
       </security-realms>
       <audit-log>
         <formatters>
           <json-formatter name="json-formatter"/>
         </formatters>
         <handlers>
           <file-handler name="host-file" formatter="json-formatter" relative-to="jboss.domain.data.dir" path="audit-log.log"/>
           <file-handler name="server-file" formatter="json-formatter" relative-to="jboss.server.data.dir" path="audit-log.log"/>
         </handlers>
         <logger log-boot="true" log-read-only="false" enabled="false">
           <handlers>
             <handler name="host-file"/>
           </handlers>
         </logger>
         <server-logger log-boot="true" log-read-only="false" enabled="false">
           <handlers>
             <handler name="server-file"/>
           </handlers>
         </server-logger>
       </audit-log>
       <management-interfaces>
         <native-interface security-realm="ManagementRealm">
           <socket interface="management" 
           port="${jboss.management.native.port:19999}"/>
         </native-interface>
         <http-interface security-realm="ManagementRealm" http-upgrade-enabled="true">
           <socket interface="management" port="${jboss.management.http.port:19990}"/>
         </http-interface>
       </management-interfaces>
     </management>
     <domain-controller>
       <remote protocol="remote" host="${jboss.domain.master.address}" port="${jboss.domain.master.port:9999}" security-realm="ManagementRealm" username="hostcontroller" />
     </domain-controller>
     <interfaces>
       <interface name="management">
         <inet-address value="${jboss.bind.address.management:127.0.0.1}"/>
       </interface>
       <interface name="public">
         <inet-address value="${jboss.bind.address:127.0.0.1}"/>
       </interface>
       <interface name="unsecure">
         <!-- Used for IIOP sockets in the standard configuration.
           To secure JacORB you need to setup SSL -->
         <inet-address value="${jboss.bind.address.unsecure:127.0.0.1}"/>
       </interface>
     </interfaces>
     <jvms>
       <jvm name="default">
         <heap size="64m" max-size="256m"/>
         <permgen size="256m" max-size="256m"/>
         <jvm-options>
           <option value="-server"/>
         </jvm-options>
       </jvm>
     </jvms>
     <servers>
     <server name="REST-server-one" group="server-group-REST-app">
     <jvm name="default">
     <heap size="64m" max-size="256m"/>
     </jvm>
     </server>
     </servers>
     <profile>
     <subsystem xmlns="urn:jboss:domain:jmx:1.3">
     <expose-resolved-model/>
     <expose-expression-model/>
     <remoting-connector/>
     </subsystem>
     </profile>
   </host>

8. Now we are ready to run our slave-1 host:

   $ ./bin/domain.sh -Djboss.domain.base.dir=slave-1 -Djboss.domain.master.address=127.0.0.1

9. If you check the log output from master, you will notice that slave-1 registered itself to the Domain Controller:

   [Host Controller] 23:45:58,523 INFO  [org.jboss.as.domain] (Host Controller Service Threads - 32) WFLYHC0019: Registered remote slave host "slave-1", JBoss WildFly Full 9.0.0.Beta2 (WildFly 1.0.0.Beta2)

10. Repeat the same changes for the second slave. Set the host name to slave-2 and add the following servers definition:

    <servers>
      <server name="SOAP-server-one" group="server-group-SOAP-app">
        <socket-bindings port-offset="150"/>
      </server>
      <server name="SOAP-server-two" group="server-group-SOAP-app">
        <socket-bindings port-offset="250"/>
      </server>
    </servers>

11. Also, set the jboss.management.native.port and jboss.management.http.port property default values, to 29999 and 29990 respectively. You should end up with a file that looks like the following XML code snippet:

    <?xml version='1.0' encoding='UTF-8'?>
    <host name="slave-2" xmlns="urn:jboss:domain:3.0">
      <extensions>
        <extension module="org.jboss.as.jmx"/>
      </extensions>
      <management>
        <security-realms>
          <security-realm name="ManagementRealm">
            <server-identities>
              <secret value="aG9zdGNvbnRyb2xsZXIuMjAxNQ=="/>
            </server-identities>
            <authentication>
              <local default-user="$local" skip-group-loading="true"/>
              <properties path="mgmt-users.properties" relative-to="jboss.domain.config.dir"/>
            </authentication>
            <authorization map-groups-to-roles="false">
              <properties path="mgmt-groups.properties" relative-to="jboss.domain.config.dir"/>
            </authorization>
          </security-realm>
          <security-realm name="ApplicationRealm">
            <authentication>
              <local default-user="$local" allowed-users="*" skip-group-loading="true"/>
              <properties path="application-users.properties" relative-to="jboss.domain.config.dir"/>
            </authentication>
            <authorization>
              <properties path="application-roles.properties" relative-to="jboss.domain.config.dir"/>
            </authorization>
          </security-realm>
        </security-realms>
        <audit-log>
          <formatters>
            <json-formatter name="json-formatter"/>
          </formatters>
          <handlers>
            <file-handler name="host-file" formatter="json-formatter" relative-to="jboss.domain.data.dir" path="audit-log.log"/>
            <file-handler name="server-file" formatter="json-
            formatter" relative-to="jboss.server.data.dir" path="audit-log.log"/>
          </handlers>
          <logger log-boot="true" log-read-only="false" enabled="false">
            <handlers>
              <handler name="host-file"/>
            </handlers>
          </logger>
          <server-logger log-boot="true" log-read-only="false" 
          enabled="false">
            <handlers>
              <handler name="server-file"/>
            </handlers>
          </server-logger>
        </audit-log>
        <management-interfaces>
          <native-interface security-realm="ManagementRealm">
            <socket interface="management" port="${jboss.management.native.port:29999}"/>
          </native-interface>
          <http-interface security-realm="ManagementRealm" http-upgrade-enabled="true">
            <socket interface="management" port="${jboss.management.http.port:29990}"/>
          </http-interface>
        </management-interfaces>
      </management>
      <domain-controller>
        <remote protocol="remote" host="${jboss.domain.master.address}" port="${jboss.domain.master.port:9999}" security-realm="ManagementRealm" username="hostcontroller" />
      </domain-controller>
      <interfaces>
        <interface name="management">
          <inet-address value="${jboss.bind.address.management:127.0.0.1}"/>
        </interface>
        <interface name="public">
          <inet-address value="${jboss.bind.address:127.0.0.1}"/>
        </interface>
        <interface name="unsecure">
          <!-- Used for IIOP sockets in the standard 
          configuration.
            To secure JacORB you need to setup SSL -->
          <inet-address value="${jboss.bind.address.unsecure:127.0.0.1}"/>
        </interface>
      </interfaces>
      <jvms>
        <jvm name="default">
          <heap size="64m" max-size="256m"/>
          <permgen size="256m" max-size="256m"/>
          <jvm-options>
            <option value="-server"/>
          </jvm-options>
        </jvm>
      </jvms>
      <servers>
      <server name="SOAP-server-one" group="server-group-SOAP-app">
      <socket-bindings port-offset="150"/>
      </server>
      <server name="SOAP-server-two" group="server-group-SOAP-app">
      <socket-bindings port-offset="250"/>
      </server>
      </servers>
      <profile>
      <subsystem xmlns="urn:jboss:domain:jmx:1.3">
      <expose-resolved-model/>
      <expose-expression-model/>
      <remoting-connector/>
      </subsystem>
      </profile>
    </host>

12. Now we are ready to run our slave-2 host:

    $ ./bin/domain.sh -Djboss.domain.base.dir=slave-2 -Djboss.domain.master.address=127.0.0.1

13. If you check the log output from master, you will notice that slave-2 registered itself to the Domain Controller:

    [Host Controller] 23:51:34,134 INFO  [org.jboss.as.domain] (Host Controller Service Threads - 34) WFLYHC0019: Registered remote slave host "slave-2", JBoss WildFly Full 9.0.0.Beta2 (WildFly 1.0.0.Beta2)

How it works…

Let's first talk about the master and then about the two slaves.

Master

Within the master, you define the entire configuration needed to run your WildFly instances. You choose a profile depending on your requirements, set IPs, ports, server, and groups. Everything is persisted into the domain.xml, or whatever file you choose to persist to.

As you launch the domain.sh script, the process by default looks for a domain.xml file and host.xml file to read the configuration, starting from the jboss.home.dir (whatever $WILDFLY_HOME is) appending domain and configuration, unless you specify differently.

We specify differently by adding the jboss.domain.base.dir property valued to master. So WildFly, starting from jboss.home.dir appends master and the configuration. As per the standalone mode, WildFly in the domain mode lets you override different paths if necessary.

The following table summarizes all the properties:

Tip

The master should run alone, without any servers.

Slaves

As stated in the previous paragraph, when you launch WildFly in the domain mode, it looks, by default, for the domain.xml and host.xml files. As we are running the slaves, we do not want to load the domain.xml, that's why we moved it away (actually we renamed it as domain.xml.unused). So the start up process only picks up the host.xml file where we defined our servers and the server groups they belong to.

So basically, within the host.xml file we just defined our servers and the domain controller that they should connect to.

Furthermore, in the host slave-2 we needed to specify a port-offset, because we already have a running instance on our local machine. Both SOAP-server-one and SOAP-server-two will increment their port bindings to 150 and 250, hence 8230 for the first http-connector and 8330 for the second http-connector. Also, we had to change the port number for the management-interfaces.

Lastly, we had to specify the domain controller which the slave will connect to, by passing the -Djboss.domain.master.address=127.0.0.1 parameter.

The domain overview from the Admin Console looks like the following screenshot:

Admin Console—domain overview