You can configure the Dynamic Routing feature to route HTTP requests to members of Liberty collectives without having to regenerate
the WebSphere plug-in configuration file when the environment changes.
About this task
To use Intelligent Management to route HTTP requests to a Liberty collective, you must enable the
dynamicRouting-1.0
feature on one or more collective controllers in a collective.
The feature provides the Dynamic Routing service, which dynamically retrieves routing information
from the collective repository and delivers this information to the WebSphere® plug-in. The feature also provides the
dynamicRouting command. Use its setup,
genPluginCfg, and genKeystore command actions together to
generate the keystores that are needed for secure communication between the plug-in and the Dynamic
Routing service, and a plug-in configuration file that enables Intelligent Management in the WebSphere plug-in.
The routing rules capability enables incoming requests
to the WebSphere plug-in to be routed to a specified set of servers. Additionally, requests can
selectively be rejected or redirected. Selection of whether a rule applies to an incoming request is
done through matching of attributes of the incoming request.
Procedure
-
Enable Dynamic Routing in a controller by adding the following code to the
featureManager tag in the server.xml of the
controller.
<feature>dynamicRouting-1.0</feature>
-
Start all controllers that are enabled by the Dynamic Routing feature.
-
Run the dynamicRouting setup command on one of the controllers to generate
the keystore and plug-in configuration files. For example:
./dynamicRouting setup --port=9444 --host=controller1.acme.com --user=admin --password=passw0rd --keystorePassword=webAS --pluginInstallRoot=/opt/HTTPServer_Plugins/ --webServerNames=webserver1
Note: Ensure a specified value of the --user
argument exists in a user registry and
is assigned an administrative role.
For more information, see Dynamic routing command.
-
Copy the generated plugin-key.p12 and plugin-cfg.xml
files to a temporary directory on the web server host.
-
On the web server host, run gskcapicmd (included in the IHS package) to
convert the keystore to CMS format and to set personal certificate as the default. CMS format is the
supported format of the WebSphere plug-in. For example:
gskcapicmd -keydb -convert -pw webAS -db /tmp/plugin-key.p12 -old_format pkcs12 -target /tmp/plugin-key.kdb -new_format cms -stash
- Use chown <user>:<group> plugin-key.kdb plugin-key.rdb
plugin-key.sth on the files that are created by the gskcapicmd in the
temporary directory. The user and group should match the ones found listed as
User
and Group
in the file
IHSinstallRoot/conf/httpd.conf
.
For
example:
chown nobody:nobody plugin-key.kdb plugin-key.rdb plugin-key.sth
-
Copy the plugin-key.kdb, plugin-key.rdb, and
plugin-key.sth files that are created by gskcapicmd from the
temporary directory to the directory
--pluginInstallRootargument_value/config/web_server_name/
.
-
Copy the plugin-cfg.xml to the directory specified in the
WebSpherePluginConfig directive in the web server
httpd.conf file. The plugin-cfg.xml is generated with the
<IntelligentManagement>
stanza. When Dynamic Routing is enabled in a collective,
one <Connector>
stanza exists for each collective controller.
For example:
<IntelligentManagement>
<Property name="webserverName" value="webServer1"/>
<ConnectorCluster enabled="true" maxRetries="-1" name="default" retryInterval="60">
<Property name="uri" value="/ibm/api/dynamicRouting"/>
<Connector host="controller1.acme.com" port="9444" protocol="https">
<Property name="keyring" value="/opt/HTTPServer_Plugins/config/webserver1/plugin-key.kdb"/>
</Connector>
</ConnectorCluster>
</IntelligentManagement>
-
Start the web server and begin routing to the application installed in the collective.
- Optional:
Add the
<dynamicRouting>
element to the controller
server.xml to specify properties for dynamic routing.
The connectorClusterName property specifies the name that dynamic routing
associates with the collective. If the connectorClusterName property is not
specified, the name of the collective is used. The retryInterval property
specifies how long to wait before a reconnection to a controller if a connection fails. The
maxRetries property specifies the number of times to try to reconnect to a
failed collective controller.
For example:
<dynamicRouting maxRetries="4" retryInterval="20" connectorClusterName="collective1">
<TraceSpecification name="default" specification=":DEBUG"/>
</dynamicRouting>
The generated
plugin-cfg.xml has the
<ConnectorCluster>
properties:
<IntelligentManagement>
<TraceSpecification name="default" specification=":DEBUG"/>
<Property name="webserverName" value="webServer1"/>
<ConnectorCluster enabled="true" maxRetries="4" name="collective1" retryInterval="20">
<Property name="uri" value="/ibm/api/dynamicRouting"/>
<Connector host="controller1.acme.com" port="9444" protocol="https">
<Property name="keyring" value="/opt/HTTPServer_Plugins/config/webServer1/plugin-key.kdb"/>
</Connector>
</ConnectorCluster>
</IntelligentManagement>
-
Optional: Create routing rules to specify how particular requests are handled.
Results
With the dynamicRouting-1.0
feature enabled, Intelligent Management can now
dynamically route HTTP requests to Liberty
collectives.