Step by step guide on using was installer in *nix Environment - dvarounis/was-installer GitHub Wiki
It is recommended to use the installer.sh wrapper script in order to run the was-installer script in a Linux/Unix Environment. It also can be used in a windows environment with Linux Shell installed like Cygwin or Windows Subsystem for Linux (WSL) in Win 10. Here are the steps on how to setup this:
-
Download the scripts in WAS Deployment Manager host or in Standalone WAS host
Run
git clone https://github.com/dvarounis/was-installer.git
preferably into your WAS user $HOME/bin -
Edit WAS parameters in the wrapper bash script installer.sh like the following:
#Path to WAS DMGR profile DMGR_HOME="/opt/ibm/websphere/appserver/profiles/Dmgr01" #Prefer RMI Connector for most deployments, especially most time consuming CONNECTOR_TYPE="RMI" #BOOTSTRAP_ADDRESS Port(used for RMI Connector) CONNECTOR_PORT=9809 #Prefer large XmX in case of large EAR applications WSADMIN_HEAPSZ="-Xms256m -Xmx4096m"
-
Edit topology.sample.xml to match your WAS application topology then rename it to topology.xml
For example in case we need to deploy 2 applications, app1 and app2, each with EAR file name pattern app1-ear and app2-ear, in application server mysrv of Node mynodeNode01 the topology file would be like:
<?xml version="1.0" encoding="UTF-8"?> <wastopology xmlns="http://www.gr.ibm.com" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://www.gr.ibm.com wastopology.xsd"> <server name="mysrv" nodename="mynodeNode01"> <application name="app1" earfileptrn="app1-ear" vhost="default_host"></application> <application name="app2" earfileptrn="app2-ear" vhost="test_vhost"> <webserver name="ihs1" nodename="ihs1-node"/> </application> </server> </wastopology>
You may see that the two applications can be bound to different virtual hosts(default_host and test_vhost) and the app2 also has ihs1 IBM HTTP Server as additional target. The topology.xml can be more complex in order to depict the actual applications-to-targets(servers,cluster or (optionally)web servers) mapping.
-
Upload the EAR files in the DMGR/WAS host where the script is installed
In case the required EAR files cannot be pulled from an HTTP URL(e.g. an artifact repository) you have to upload those files by default in
binaries
sub-directory of the current path of the script (this can be changed in installer.sh(see $BINDIR parameter)). -
Run the installer wrapper script to install/update the applications in the required targets(Servers or Clusters)
The recommended way to run the installer script is through the wrapper script with the EAR file urls as parameters , i.e.
installer.sh [ <ear-url1> <ear-url2> ...]
. This can be done if the EAR files are uploaded in an artifact repository like Sonatype Nexus or Jfrog Artifactory. The wrapper script will download the provided EARs through HTTP and place them insidebinaries
sub-directory along with any other EARs placed there manually in step 4. Alternative follow step 4 and run the installer.sh script without parameters.
Then the wrapper script will call the wsadmin installer.py script in order to install all the EARs placed in binaries
directory in WAS targets based on topology.xml.
The wsadmin script will group all provided EARs by target(Server or Cluster) and deploy each target group serially.
In case the target is a cluster it will make a rollout update operation(i.e. Stop each member of cluster, update with the EARs and then start the WAS Server serially) unless you set a -S
flag in installer.sh which will handle the cluster deployment as a WAS Server deployment, i.e. it will Save and Synchronize the WAS configuration.