WebSphere Automation "How To" Series #4 : How to register WebSphere Application Server traditional servers using configuretWasUsageMetering.py script
Previous blogs in this WebSphere Automation "How To" series :
WebSphere Automation "How To" Series #1 : How to get WebSphere Automation UI WebSphere Automation "How To" Series #2 : How to specify user roles and permissions WebSphere Automation "How To" Series #3 : How to configure WebSphere Automation with an Enterprise LDAP This post will focus on how to register WebSphere Application Server traditional servers using configuretWasUsageMetering.py script.
To register your WebSphere Application Server traditional server with WebSphere Automation, you will use the URL and API key to configure your server with the usage metering service that is in WebSphere Automation. You will use the same usage metering information to register all of your WebSphere Application Server traditional servers and your WebSphere Application Server Liberty servers. This post is going to focus solely on how to register WebSphere Application Server traditional servers using configuretWasUsageMetering.py script.
For this example, we initially have no servers registered. The following is the WebSphere Automation UI screenshot showing no registered servers.
IBM Docs
https://www.ibm.com/docs/en/ws-automation?topic=monitoring-registering-websphere-application-server-traditional-servers provides information on registering WebSphere Application Server traditional servers, detailing steps to either manually register the servers or utilize the provided configuretWasUsageMetering wsadmin script to register the servers.
We can use the 'Copy to clipboard' icon provided for the configuretWasUsageMetering.py script on
https://www.ibm.com/docs/en/ws-automation?topic=monitoring-registering-websphere-application-server-traditional-servers and paste this script on the deployment manager machine for our tWAS v9.0.5.11 ND cell.
The following are the first few lines of the configuretWasUsageMetering.py script with comments describing the script and showing the required parameters.
#------------------------------------------------------------------------------------
# configuretWasUsageMetering.py - configure tWAS server with usage metering feature
#------------------------------------------------------------------------------------
#
# This script configures a traditional WebSphere Application Server with the usage
# metering service using the scripting client wsadmin. This script creates a keystore,
# retrieves signer from api-usagemetering-host and store it to keystore. It also creates
# was-usage-metering.properties file including all required properties (input) and copy
# them to the given node and server. If node and server names are not given, it will copy
# keystore and was-usage-metering.properties to all servers. The script also synchronizes
# the changes to the active nodes and start servers. We assume an environment in which
# the scripting client is connected to the Network Deployment manager, but this script
# could be used in a base install.
#
# This script contains the following required and optional parameters:
#
# Required parameters:
# url - url for accessing cpd route in "https://<cpd-route>/websphereauto/meteringapi" format
# apiKey - API key for authentication token
# sslRef - SSL name of server SSL configuration
# or
# trustStorePassword - trustStore password to create a new truststore
To get the URL of the usage metering service, you can issue the following oc command.
oc get route cpd -n NAMESPACE -o jsonpath=https://{.spec.host}/websphereauto/meteringapi
To get the API key, you first need to know the instance name. You can get the instance name with the following command.
oc get WebSphereSecure -n NAMESPACE -o jsonpath='{.items[?(@.kind=="WebSphereSecure")].metadata.name}'
Using your instance name, you can get the API key with the following command
oc -n NAMESPACE get secret INSTANCENAME-metering-apis-encrypted-tokens -o jsonpath='{.data.INSTANCENAME-metering-apis-sa}' | base64 -d
For this example, we have a tWAS v9.0.5.11 ND cell running with a dmgr and 4 nodes with 2 application servers on each node for a total of 8 application servers. Using the values for URL and API key captured along with a trustStorePassword, by default we will register all the servers in the ND cell using the configuretWasUsageMetering.py script.
wsadmin.sh -f configuretWasUsageMetering.py url=https://cpd-websphere-automation.apps.XXX.com/websphereauto/meteringapi apiKey=XXXXXXXXXXXXXXX trustStorePassword=tspassw0rd
WASX7209I: Connected to process "dmgr" on node dmgr using SOAP connector; The type of process is: DeploymentManager
WASX7303I: The following options are passed to the scripting environment and are available as arguments that are stored in the argv variable: "[url=https://cpd-websphere-automation.apps.XXX.com/websphereauto/meteringapi, apiKey=XXXXXXXXXXXXXXX, trustStorePassword=tspassw0rd]"
Input arguments:
url: https://cpd-websphere-automation.apps.XXX.com/websphereauto/meteringapi
apiKey: ********
trustStorePassword: ********
Creating keystore meteringTrustStore ...
Keystore was created: meteringTrustStore(cells/NDCell|security.xml#KeyStore_1649093021884)
Using default certificate alias: meteringalias
Retrieving signer from port ...
Signer was retrieved from host: cpd-websphere-automation.apps.XXX.com, port: 443 and store to keystore: meteringTrustStore
Creating was-usage-metering.properties file with all specified properties ...
Copying keystore meteringTrustStore.p12 and was-usage-metering.properties to all servers ...
keystoreFile meteringTrustStore.p12 was created on all servers.
was-usage-metering.properties was created on all servers.
Syncing config changes to all nodes ...
Sync nodes were done!
After executing the configuretWasUsageMetering.py script, for this example we now have 8 servers registered. The following is the WebSphere Automation UI screenshot showing the registered servers.
You can find more IBM Docs related to WebSphere Automation at https://www.ibm.com/docs/en/ws-automation
#websphere#automation#WSA#WebSphereAutomation