How to provide scaling and elasticity for Liberty Application Server using native installs and Docker. Slides provide the differences between scalability and elasticity locally and remotely, with and without Docker containers.

1. Scalability and Elasticity locally and in the IBM Cloud
Brian S Paskin, Senior Application Architect, R&D Services, IBM Cloud
Updated 22 August 2018
WebSphere Liberty Lunch and Learn
with native installs and Docker

2. Types of Scaling for Liberty
2
 Scaling cluster member
 Elasticity with cluster members
 Scaling with Docker with cluster members
 Elasticity with Docker with cluster members
 Scaling Liberty in the IBM Cloud
 Scaling with Docker in the IBM Cloud

3. Collective Controllers
3
 A Collective Controller allows for the
administration of a group of Liberty servers
– Replica Collective Controllers for high
availability
– Clustering of Liberty servers
– Auto scaling for server elasticity
– Dynamic Routing automatically updates
the plugin file when changes occur
– Health management that triggers actions
based on health of a Liberty server
– Administer all servers and clusters from a
single Collective Controller
– Communications from Collective to
members is over secure connections

4. Auto scaling Liberty servers
4
 Auto scaling automatically adjusts the number of Liberty servers that handle requests
– Requires members be part of a cluster
– Consists of a scaling controller and scaling members
– The scaling controller decides whether to expand or contract the number of servers
– Scaling based on CPU, heap and memory
– Should be used in conjunction with Dynamic Routing for automatic update of available
members to handle requests
 Add the scaling controller feature to the Collective Controller and Replica Sets
<feature>scalingController-1.0</feature>
 Add the scaling member feature and listening port to each member
– Members on the same host should use the same port number
<feature>scalingMember-1.0</feature>
<hostSingleton name="ScalingMemberSingletonService" port="20020" />

5. Auto scaling Liberty servers
5
 Add the auto scaling policy to the Collective and Replica
Sets
– Policies can scale horizontally or vertically, have any
number of minimum and maximum servers and contain
multiple clusters
– Metrics to scale are based on CPU, heap and memory
percentages or any combination
– Scaling out and back to the minimum is based on
minutes passed the threshold
<scalingDefinitions>
<scalingPolicy name="horizontal"
id="Cluster1Policy" max="2" min="1">
<bind clusters="cluster1"/>
<metric name="cpu" min="10" max="70"/>
<metric name="heap" min="1" max="80"/>
<out minInterval="3m" units="instance"/>
<in minInterval="10m" units="instance"/>
</scalingPolicy>
</scalingDefinitions>

6. Provisionable Cluster Elasticity
6
 Provision and start Liberty on new servers based on
cluster scaling definitions
– Utilize Stack Groups to push Liberty, Java and
servers to systems
– New systems must be registered to the Controller
 Liberty, Java and Server must be packaged with specific
names under the ${wlp.user.dir}/stackGroups
directory using the server package command
– Liberty and Java are placed in the installables
directory
– Servers are placed in the packages directory
 Use stackGroup and scalingDefinitions
configurations to push out Liberty to servers
 Start and stop Docker containers based on
configuration
– Containers become part of the cluster

7. Liberty and Docker
7
 Docker allows for packaging applications with all of their dependencies into a standardized
unit for software development and deployment onto a wide range of platforms
 Liberty is Docker ready
– Official repository available Docker Hub
– Available in IBM Bluemix Containers
– Near bare metal performance
– All features of Liberty available
 Dockerfiles on WASdev GitHub
– Upgrade the Docker Hub image with Liberty Core, Base or ND commercial license
– Build your own Docker image for WAS Liberty or Full Profile
 Containers can be part of Cluster and managed by Controllers
– Start and stop sending JSON to a Controller
– Using new panels in Liberty Admin Center *
 Provisional cluster elasticity
– Start and stop containers based on scaling requirements
* 16.0.0.3 and above

8. Using Docker with Liberty
 Official repository can be pulled from the Docker Hub
– Several diverse Docker tags with different features installed
– Install needed features using the installUtility command in the Dockerfile
– Collective Controller is not necessary
 Run Liberty Docker container individually
– Command line from the server
– Create as many instances as necessary
– Map ports to free ports on server
– Include applications or deploy by linking to the dropins directory
 Liberty Docker containers can be added to Cluster
– Requires Collective Controller
– Requires Dockerfile contain register and deregister scripts
– Generic port definitions in the server.xml
– Managed with REST API requests or Admin Console *
8
.war.war
.war
* 16.0.0.3 and above

9. Using Docker with Liberty
 Provisioning Liberty Docker containers for elasticity
– Requires Collective Controller
– Requires Dockerfile contain register and deregister scripts
– Requires stack group configuration
– Generic port definitions in the server.xml
– Manage elasticity with scaling definitions in collective controller
– Decide which servers are start on which system
– Scaling horizontally or vertically
9

10. Single Instances
 Requires a Dockerfile, server.xml and any artifacts necessary
– Use installUtility in Dockerfile to include necessary features
– The ENTRYPOINT is to run the defaultServer
– Liberty is install under the /opt/ibm/wlp directory
– JRE 8 is installed under the /opt/ibm/java directory
 Build the Docker containers using a meaningful tags
 Run Docker containers by exposing the ports defined in server.xml to operating system
ports
 Deploy applications by mapping application to server dropins directory, if necessary
10

11. Clustering Containers
 A Cluster Controller must be installed
– Install the Admin Center to see the changes as they happen
 The Docker host must be registered with the Collective Controller
 Add variables in the Collective Controller server.xml for HTTP and HTTPS ports, which will
increase by the number indicated on the host
<deployVariable name="memberHttpPort" value="9080" increment="1"/>
<deployVariable name="memberHttpsPort" value="9443" increment="1"/>
 A valid username and password need to be added in the Collective Controller server.xml so
the new Docker containers can communicate
<collectiveController user="userName" password="password" />
 Optionally, Dynamic Routing can be enabled to allow the web servers to communicate with the
Docker containers by adding the feature to the Collective Controller
<feature>dynamicRouting-1.0</feature>
11

12. Clustering Containers
 If using a Docker Registry, add the variables to the Collective Controller
– Docker image will be pulled from the registry and deployed to the Docker host
<variable name="dockerRegistry" value="dockerRegistry" />
<variable name="dockerRepository" value="dockerRepository" />
<variable name="dockerUser" value="dockerUser" />
<variable name="dockerUserPassword" value="dockerUserPassword" />
<variable name="dockerUserEmail" value="dockerUserEmail" />
12

13. Clustering Containers
 Dockerfile must add the joinMember and removeMember scripts to the /opt/ibm/docker
directory in the container
– Scripts are called before starting the Liberty server and after shutdown
– Provide updated HTTP and HTTPs ports and register and deregister with the Collective
Controller
 Dockerfile must install clusterMember-1.0, collectiveMember-1.0 and any other
features that will be used by Liberty using the installUtility
 The default HTTP endpoint must contain the variables for the HTTP and HTTPs ports
– Will be passed by the Collective Controller to the Docker container
<httpEndpoint id="defaultHttpEndpoint" host="*" httpPort="${memberHttpPort}"
httpsPort="${memberHttpsPort}" />
 Build the Docker container
13

14. Clustering Containers with REST APIs
 REST APIs can be used to control the starting and stopping of a container, and to view the status
of an operation
– Display deployment rules
GET https://controller_host:controller_port/ibm/api/collective/v1/deployment/rule
– Display status of an operation
GET https://controller_host:controller_port/ibm/api/collective/v1/deployment/{token}/status
– Display complete results of an operation
GET https://controller_host:controller_port/ibm/api/collective/v1/deployment/{token}/results
– Deploy a Docker Container
POST https://controller_host:controller_port/ibm/api/collective/v1/deployment/deploy
– Remove a Docker Container
POST https://controller_host:controller_port/ibm/api/collective/v1/deployment/undeploy
14

15. Clustering Containers
15
POST https://controller_host:controller_port/ibm/api/collective/v1/deployment/deploy
{
"rule": "Liberty Docker Rule",
"hosts": [ "myHostName" ],
"variables": [
{ "name":"imageName", "value":"myImageName" },
{ "name":"containerName", "value":"myContainerName" },
{ "name":"clusterName", "value":"myClusterName" },
{ "name":"keystorePassword", "value":"thePassword" }
]
}
POST https://controller_host:controller_port/ibm/api/collective/v1/deployment/undeploy
{
"host": "myHostName",
"userDir":"Docker",
"serverName":"myContainerName"
}
imageName - Name of the Docker image to be started
containerName - Name given to running Docker container
clusterName - Name of the cluster to join
keystorePassword - Password to the collective keystore

16. Clustering Containers with the Admin Center
 The Admin Center can be used to control the starting and stopping of a container, and to view the
status of an operation *
– Deploy tool to deploy a Liberty server or Node.js server
– Select a server package or Docker container
– Provide the information for Docker image name, container name, and cluster name
 Same information as REST APIs
 Cluster name can be Stack Group name
– Select the hosts to deploy the Docker containers
– Check the status for information about the status of deployment
16 * 16.0.0.3 and above

17. Clustering Containers with Elasticity
 Elasticity allows for the adding or removal of Docker containers based on scaling policy
17

18. Clustering Containers with Elasticity
 A stack group must be added to the Liberty install of the Collective Controller
– Located under the ${wlp.user.dir}/shared/stackGroups directory
– Copy the default stack group and add a meaningful name
– Create a packageName.deploy.xml in the packages directory
– The XML file contains the same entries for a deploy by the REST API
<deploy>
<useRule id="Liberty Docker Rule" />
<variable name="imageName" value="myImageName"/>
<variable name="containerName" value="myContainerName"/>
<variable name="clusterName" value=" myStackGroup.myClusterName"/>
<variable name="keystorePassword" value="thePassword"/>
</deploy>
 Add the scaling controller feature to the Collective Controller
<feature>scalingController-1.0</feature>
 Add the stack group definitions the Collective Controller for the HTTP and HTTPS ports
<stackGroup name="myStackGroup">
<deployVariable name="memberHttpPort" value="9080" increment="1"/>
<deployVariable name="memberHttpsPort" value="9443" increment="1"/>
</stackGroup>
18

19. Clustering Containers with Elasticity
 Add the scaling definition and scaling policies
<scalingDefinitions id="provisionPolicy">
<scalingPolicy enabled="true" max="3" min="1" name="vertical">
<bind clusters="myStackGroup.myPackageName"/>
<hostGroup tags="myHost1 myHost2"/>
<metric name="heap" min="30" max="85"/>
</scalingPolicy>
</scalingDefinitions>
 Scaling is based on the metrics, the number of minimum and maximum servers, and if the
policy is enabled
– Hosts must be tagged in metadata to use hostGroup
– Multiple scaling policies can be used in a scaling definition when bound to different
clusters
– Name of the Docker container that is used is the name placed in the
packageName.deploy.xml file suffixed by -#, where # is the instance number
19

20. Scaling Liberty in the IBM Cloud
 IBM Cloud uses Cloud Foundry as Platform as a
Service
– Deployment and scaling applications and
services
– Add services to applications
– Multi region possible with separate deploys
 Deploying a JEE or Web Application using Cloud
Foundry it is deployed to Liberty
 Ability to deploy the Liberty server directory with all
necessary features and configurations
 Deploy using IBM Cloud CLI or DevOps
– IBM Cloud Console can be used for adding
services and change characteristics of
applications and services
 Use Auto-Scaling to scale Liberty based on metrics
– Similar to those using the Scaling Controller20

21. Scaling Liberty in the IBM Cloud
 Push a Liberty application server with configuration to the IBM Cloud
ibmcloud cf push <appname> -m <memory amount>m -p </path/to/server>
 Check logs of launched app server
ibmcloud cf logs <appname> --recent
 Increase the amount of instances
ibmcloud cf scale <appname> -i <num of instances>
 Add the Auto-Scaling service
ibmcloud service create auto-scaling free <service name>
 Bind it to the application
ibmcloud service bind <appname> <service name>
 Create a policy for the Auto-Scaling
ibmcloud as policy-create
 Or Attach a policy and bind it to an application
ibmcloud as policy-attach <appname> -p <policy file name>
ibmcloud as policy-enable <appname>
21

22. Scaling Liberty in the IBM Cloud
 Sample policy file:
{ "instanceMaxCount": 2,
"instanceMinCount": 1,
"policyTriggers": [
{
"breachDuration": 600,
"instanceStepCountDown": 1,
"instanceStepCountUp": 1,
"lowerThreshold": 30,
"metricType": "ResponseTime",
"scaleInAdjustment": "changeCapacity",
"scaleOutAdjustment": "changeCapacity",
"statWindow": 300,
"stepDownCoolDownSecs": 600,
"stepUpCoolDownSecs": 600,
"upperThreshold": 100
}
]
}
22

23. Scaling Liberty in the IBM Cloud
23

24. Scaling Containers in the IBM Cloud
 Kubernetes is used in the IBM Cloud for orchestration
– Clusters that allow horizontal and/or vertical scaling of
containers in one or more virtual or physical machines
 Pod – contains one or more containers using Deployments
 Node – a worker machine, physical or virtual, that contains
one or more Pods
 ReplicaSet – controls the number of Pods that should be
running across Nodes
 Service – defines a logical sets of Pods and can expose
their endpoints
 Cluster – Contains one or more Nodes and a master that
controls the functions of Kubernetes
24

25. Scaling Containers in the IBM Cloud
 Add a namespace that will be used for the IBM Cloud Docker registry
ibmcloud cr namespace-add <namespace>
 Tag local Docker image
docker tag <imagename> registry.ng.bluemix.net/<namespace>/<imagename>
 Push the image to the IBM Cloud
docker push registry.ng.bluemix.net/<namespace>/<imagename>
 Create a Cluster (may take several minutes)
ibmcloud cs cluster-create --name <clustername>
 Configure the Cluster for local Kubernetes commands
bx cs cluster-config <clustername>
export KUBECONFIG=/path/to/file.yml
 Deploy a container
kubectl run <deploymentname> --
image=registry.ng.bluemix.net/<namespace>/<imagename>
25

26. Scaling Containers in the IBM Cloud
 Deployment instances will be defined on the worker Nodes
 Add a deployment and specify the number of replicas
kubectl run <deploymentName> --
image=registry.ng.bluemix.net/<namespace>/<imagename> --replicas=1 or
kubectl apply –f </path/to/deployment>
 Expose ports, if necessary
kubectl expose deployment/<deploymentName> --type=NodePort --port=<port> --
name=<serviceName> --target-port=<targetPort>
 Link a service to the deployment
kubectl apply –f </path/to/service>
 Without ingress or other load balancer, the workers must be targeted directly
 Show the recently added service to find the Node Port that is opened
kubectl describe service <serviceName>
 Show the workers’ public IP Address
bx cs workers –cluster <clusterName>
26

27. Scaling Containers in the IBM Cloud
 Access the container using the public IP:nodePort address
 Apply changes to any resource from a file
kubectl apply –f </path/to/file>
 Cluster information
kubectl cluster-info
 Examine configuration and metrics of all aspects of the Kubernets using the Kubernetes
Dashboard button on the cluster screen in the IBM Cloud or locally with a proxy
kubectl proxy <flags>
kubectl proxy --address=0.0.0.0 --accept-
hosts=^localhost$,^127.0.0.1$,^192.168.134.128$
 Examine container logs using the proxy or command
kubectl logs <resource>
27

28. Scaling Containers in the IBM Cloud
28