where tibco experts share, learn, and collaborate. - tibco ......innovation. learn how tibco makes...

TIBCO Software Inc. Global Headquarters

3307 Hillview Avenue

Palo Alto, CA 94304

Tel: +1 650-846-1000

Toll Free: 1 800-420-8450

Fax: +1 650-846-1005

www.tibco.com

TIBCO fuels digital business by enabling better decisions and faster, smarter actions through the TIBCO Connected Intelligence Cloud. From APIs and systems to devices and people, we interconnect everything, capture data in real time wherever it is, and augment the intelligence of your business through analytical insights. Thousands of customers around the globe rely on us to build compelling experiences, energize operations, and propel innovation. Learn how TIBCO makes digital smarter at www.tibco.com.

TIBCO Enterprise Message Service™ on AKS This document describes how to run TIBCO Enterprise Message Service servers in an Azure Kubernetes Service (AKS) environment.

Version 1.2 March 2020 Updated for EMS 8.5.x updated AKS services

©2020 TIBCO Software Inc. All Rights Reserved. 2

Copyright Notice COPYRIGHT© 2020 TIBCO Software Inc. All rights reserved.

Trademarks TIBCO, the TIBCO logo, TIBCO Enterprise Message Service, TIBCO FTL, Rendezvous, and SmartSockets are either registered trademarks or trademarks of TIBCO Software Inc. in the United States and/or other countries. All other product and company names and marks mentioned in this document are the property of their respective owners and are mentioned for identification purposes only.

Content Warranty The information in this document is subject to change without notice. THIS DOCUMENT IS PROVIDED "AS IS" AND TIBCO MAKES NO WARRANTY, EXPRESS, IMPLIED, OR STATUTORY, INCLUDING BUT NOT LIMITED TO ALL WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. TIBCO Software Inc. shall not be liable for errors contained herein or for incidental or consequential damages in connection with the furnishing, performance or use of this material.

For more information, please contact:

TIBCO Software Inc. 3303 Hillview Avenue Palo Alto, CA 94304 USA


Table of Contents

1 Overview ........................................................................................................................................ 5 1.1 Supported Versions ............................................................................................................................. 5 1.2 Excluded TIBCO EMS Features ............................................................................................................ 5 1.3 Prerequisites ....................................................................................................................................... 6 1.4 Prepare Local Environment ................................................................................................................. 6 1.5 Prepare Preliminary Azure Account and Kubernetes Configuration ................................................... 6

2 Fault Tolerance and Shared Folder Setup ..................................................................................... 7 2.1 Shared Storage .................................................................................................................................... 7 2.2 Create the Azure Storage Account and File System ............................................................................ 7

3 The EMS Docker image ................................................................................................................ 10 3.1 Creating the Base Docker Image ....................................................................................................... 10 3.2 Extending the Base Docker Image ..................................................................................................... 12

3.2.1 Provisioning FTL Client Libraries to Use the Corresponding Transports ........................................ 12 3.2.2 Provisioning Custom JAAS Authentication or JACI authorization Modules ................................... 12

3.3 Hosting the Docker Image ................................................................................................................. 13 3.3.1 Configure the Azure Container Registry .......................................................................................... 13 3.3.2 Push the EMS Docker Image to ACR ................................................................................................ 13

4 Azure AKS Setup ........................................................................................................................... 14 4.1 Create a New Azure Kubernetes Service (AKS) ................................................................................. 14 4.2 Configuring Kubectl to connect to Azure Kubernetes Service .......................................................... 15

4.2.1 Configure Kubectl to connect to AKS ............................................................................................. 15 4.2.2 Create a New Namespace ............................................................................................................. 16 4.2.3 Create a Kubernetes Secret to Access the Azure Storage Account ................................................ 16 4.2.4 Create a Kubernetes Secret to Access the Azure Container Registry ............................................ 16

4.3 EMS Server Template ........................................................................................................................ 17 4.3.1 Adjusting the Services Port Range (Optional) ............................................................................... 17 4.3.2 TIBEMSD Template ....................................................................................................................... 17 4.3.3 Creating a Deployment and Service .............................................................................................. 20 4.3.4 Stopping or Deleting an EMS Server ............................................................................................. 20 4.3.5 EMS Server Configuration ............................................................................................................. 21 4.3.6 Connecting to the EMS Server Container via Kubectl .................................................................... 21

4.4 Central Administration Server Template .......................................................................................... 21

5 Accessing the EMS Server ............................................................................................................ 23 5.1 Accessing the EMS Server ................................................................................................................. 23 5.2 Modifying the Connection Factories in the EMS Server .................................................................... 23

Appendix A: TLS Configuration ........................................................................................................ 25 B.1 Creating a Secret ............................................................................................................................... 25 B.2 Adjusting the Template ..................................................................................................................... 26 B.3 Adjusting the tibemscreateimage EMS Docker image build script .......................................... 27 B.4 Applying the Adjustments ................................................................................................................. 27


Table of Figures FIGURE 1 - CREATE STORAGE ACCOUNT ...................................................................................................................................... 7 FIGURE 2 - STORAGE ACCOUNT INPUTS ...................................................................................................................................... 8 FIGURE 3 - AZURE STORAGE ACCOUNTS ...................................................................................................................................... 9 FIGURE 4 - CREATE ACR REPOSITORY ....................................................................................................................................... 13 FIGURE 5 - LOGIN INTO THE ACR ............................................................................................................................................. 13 FIGURE 6 - TAG AND PUSH EMS DOCKER IMAGE ........................................................................................................................ 13 FIGURE 7 - KUBERNETES CLUSTER CREATION .............................................................................................................................. 15 FIGURE 8 - CONFIGURE KUBECTL ............................................................................................................................................. 15 FIGURE 9 - VERIFY CONNECTING TO THE KUBERNETES CLUSTER ...................................................................................................... 16 FIGURE 10 - CREATE TIBEMS NAMESPACE .................................................................................................................................. 16 FIGURE 11 - GET STORAGE ACCOUNT KEY ................................................................................................................................. 16 FIGURE 12 - CREATE THE SECRET KEY FOR THE ASA .................................................................................................................... 16 FIGURE 13 - GET ACR CREDENTIALS ........................................................................................................................................ 16 FIGURE 14 - CREATE THE SECRET KEY FOR ACR .......................................................................................................................... 17 FIGURE 15 - CHECK DEPLOYMENT RESULTS ............................................................................................................................... 20 FIGURE 16 - TO STOP, START, AND DELETE THE DEPLOYMENT ...................................................................................................... 21 FIGURE 17 - ACCESSING THE RUNNING CONTAINER ..................................................................................................................... 21 FIGURE 18 - APPLY THE EMSA TEMPLATE ................................................................................................................................ 22


1 Overview

Running TIBCO Enterprise Message Service (EMS) on Azure AKS involves:

• Configuring the Azure Kubernetes Service (AKS) for TIBCO Enterprise Message Service (EMS).

• Configuring an Azure Storage Account - File for the EMS shared storage • Configuring an Azure Container Registry (ACR) for the Docker® image registry • Creating a Docker® image embedding EMS and hosting it on ACR • Configuring and creating EMS Kubernetes containers based on the EMS Docker image

1.1 Supported Versions

The steps described in this document are supported for the following versions of the products and components involved:

• TIBCO EMS 8.5.1 • TIBCO FTL 5.4 and later (static TCP transports only) • Docker Community/Enterprise Edition should be the most recent version (19.03.5), to

address recent security vulnerabilities • Kubernetes 1.13 or newer

1.2 Excluded TIBCO EMS Features

As of March 2020, TIBCO EMS on AKS supports all EMS features, with the following exceptions:

• Excludes transports for TIBCO Rendezvous® • Excludes transports for TIBCO SmartSockets® • Excludes stores of type dbstore • Excludes stores of type mstores


1.3 Prerequisites

The reader of this document must be familiar with:

• Docker concepts • Azure console and the Azure CLI (az) • Kubernetes installation and administration • TIBCO EMS configuration • SMB3

1.4 Prepare Local Environment

The following infrastructure should already be in place:

• A Linux or macOs machine equipped for building Docker images • JRE installation package (.tar.gz) • TIBCO EMS 8.5.1 installer (.zip) • TIBCO Enterprise Message Service 8.5.1 for Linux downloaded and installed to access the

$TIBCO_HOME/ems/8.5/samples/openshift directory and files • The tibems_aks_files.zip has been downloaded from

https://community.tibco.com/wiki/tibcor-messaging-article-links-quick-access • Tibems_aks_files.zip (EMS Kubernetes yaml files)

Create a directory, place tibems_aks_files.zip in the directory. Unzip tibems_aks_files.zip. Place the TIBCO EMS installer zip, and the JRE (or JDK) tar file in the newly created tibems_aks_files directory. All configuration will be done from this directory.

1.5 Prepare Preliminary Azure Account and Kubernetes Configuration

Use the following to prepare the preliminary environment to install EMS on AKS.

• An Azure account is required. If necessary, create an account at http://portal.azure.com and follow the on-screen instructions.

• Install the Azure CLI on the workstation used.

• Install Docker on the workstation to build the TIBCO EMS images.

• Install the kubectl command-line tool do manage and deploy applications to Kubernetes in AZURE from a workstation.


2 Fault Tolerance and Shared Folder Setup

2.1 Shared Storage

A traditional EMS server configured for fault tolerance relies on its state being shared by a primary and a secondary instance, one being in the active state while the other is in standby, ready to take over. The shared state relies on the server store and configuration files to be located on a shared storage device. The fault tolerance model used by EMS on Kubernetes/AKS is different in that it relies on Kubernetes restart mechanisms. Only one EMS server instance is running and, in case of a server failure, will be restarted inside its container. In case of a failure of the container or of the corresponding cluster node, the cluster will recreate the container, possibly on a different cluster node, and restart the EMS server there. Within the container, the health of the EMS server can be monitored via the probe port. See the EMS 8.5.1 documentation for more information on the probe port. In any case, the server still needs its state to be shared. In Azure, this can only be accomplished with an Azure Storage Account and file setup.

2.2 Create the Azure Storage Account and File System

This section outlines creating the Azure Storage Account (ASA) and accompanying file system. Though the ASA and file system can be created through the Azure CLI, the following will create the file system through the Azure Console. Use the following to setup the Azure Storage Account:

• From the main Azure Dashboard, select the "Storage Accounts" button on the left of the screen. Then, select Add.

Figure 1 - Create Storage Account


Figure 2 - Storage Account Inputs

o Under "Create storage account" § Select the Subscription and Resource group. These must be the same as the

three VMs. § Select the Storage Account name § Select either Standard or Premium for Performance. Standard provides less

performance, but is suitable for development or test environments. Premium provides higher throughput, but at a higher cost. Only select premium for production level environments.

§ Select Account kind. If standard performance was selected, then select either general purpose (v1 or v2). If premium performance is selected, then FileStorage must be selected.

§ Select the Replication method desired. Since this is for EMS, and changes consistently, either local or zonal replication is recommended.

§ Select Hot for the default Access tier. § Select Network Connectivity based on requirements. § Under Advanced, select either Disabled or Enable for Secure transfer

required based on requirements. o Click on Review and Create. o If validation passes, click on Create.


• Once the new Storage Account is created: o Should still be on the storage account page in the dashboard

§ Refresh the page § Select the newly created storage account - Will need this name later for the

mount command in Linux.

Figure 3 - Azure Storage Accounts

§ Click on File shares § Click on the + at the top of the screen to add a new file share § Use the name share - this name is required. § Select the size for the share file share in GB. Note: a larger file share can

provide better performance, but costs increase, especially for premium performance. Select the size based on needs.

o Click Create to create the new File Share


3 The EMS Docker image

3.1 Creating the Base Docker Image

The content of the container that will run on AKS derives from a Docker image that first needs to be created and then hosted in the Azure Container Registry (ACR). To create the Docker images, use the following: To create an EMS Docker image, use the tibemscreateimage script on a machine equipped for building Docker images.

Use the following steps to prepare the environment:

• Change directory to the tibems_aks_files directory previously created. • Copy the $TIBCO_HOME/ems/8.5/samples/docker/tibemscreateimage script to the

tibems_aks_files directory. • Ensure the following have been copied to tibems_aks_files:

o EMS 8.5 installation package o Optional EMS hotfixes o Optional Java package (JRE or JDK)

Once all files are located to tibems_aks_files, tibemscreateimage script can be used to create the EMS Docker image. The script will also let you choose whether to save the image as an archive and create a user and group set to the required uid and gid values.

For example: > tibemscreateimage TIB_ems_8.5.1_linux_x86_64.zip \ -j .tar.gz \ -u 1000 \ -g 1000

This example creates a Docker image based on the EMS 8.5.1 Linux installation package, adding a JVM, the 1000 uid and the 1000 gid. If you are curious to run this image stand-alone: > docker run -p 7222:7222 -v `pwd`:/shared ems:8.5.1 tibemsd

creates a sample EMS server folder hierarchy and configuration in the current directory and starts the corresponding server. > docker run -p 8080:8080 -v `pwd`:/shared ems:8.5.1 tibemsca

creates a sample Central Administration server folder hierarchy and configuration in the current directory and starts the corresponding server.

You can override the creation and use of the sample configuration with your own setup:


> docker run -p 7222:7222 -v :/shared \ ems:8.5.0 tibemsd -config /shared/

starts an EMS server using the / configuration.

The tibemscreateimage script can be modified to meet your specific needs.


3.2 Extending the Base Docker Image

The base Docker image can be extended to include FTL client libraries and custom JAAS authentication and JACI authorization modules.

3.2.1 Provisioning FTL Client Libraries to Use the Corresponding Transports

1. Copy the FTL client library files to a temporary folder. 2. From the temporary folder, use a Dockerfile based on the example given below to copy

these files into the base Docker image: FROM ems:8.5.1 COPY --chown=tibuser:tibgroup . /opt/tibco/ems/docker/ftl

> docker build -t ems:8.5.1_ftl .

3. Upon customizing your EMS configuration, make sure to include /opt/tibco/ems/docker/ftl in the Module Path property.

3.2.2 Provisioning Custom JAAS Authentication or JACI authorization Modules

NOTE: If using EMSCA on Azure, this step should be followed to ensure EMSCA is secure! See the JAAS module section in the EMS Users Guide as well as the EMS Central Administration Guide on details for setting up JAAS in EMS. 1. Copy your custom JAAS or JACI plugin files, including the static configuration files they

may rely on, to a temporary folder. 2. From the temporary folder, use a Dockerfile based on the example given below to copy

these files into the base Docker image: FROM ems:8.5.1 COPY --chown=tibuser:tibgroup . /opt/tibco/ems/docker/security

> docker build -t ems:8.5.1_security .

3. Upon customizing your EMS configuration, make sure to include the relevant paths to those files in the Security Classpath property. Note: The other required files are in their usual location: /opt/tibco/ems//bin and /opt/tibco/ems//lib For example: /opt/tibco/ems/docker/security/user_jaas_plugin.jar:/opt/tibco/ems/8.5/bin/tibemsd_jaas.jar:/opt/tibco/ems/8.5/lib/tibjmsadmin.jar, etc.


3.3 Hosting the Docker Image

3.3.1 Configure the Azure Container Registry A new ACR repository must be created to host the EMS Docker image.

• Create a new ACR repository, such as tibems. The repository can be created via the Azure CLI or via the console. Please note the loginServer of your ACR repository.

> az acr create --resource-group --name tibems --sku Basic Figure 4 - Create ACR Repository

• Login into the newly created Azure ACR from the Azure CLI. > az acr login --name

Figure 5 - Login into the ACR

3.3.2 Push the EMS Docker Image to ACR • Tag the image and push the Docker image to the ACR repository using the loginServer

name noted above. Note: Name of Docker image may differ depending on setup.

> docker tag ems:latest /ems:latest Figure 6 - Tag and Push EMS Docker image

• Push the EMS Docker image to ACR. Replace the name of the loginServer > docker push /ems:latest


4 Azure AKS Setup

4.1 Create a New Azure Kubernetes Service (AKS)

A new Kubernetes cluster must be created in AKS. Use the following to build a new Kubernetes Service in Azure. This can be created via the Azure Portal of the Azure CLI. This document will outline building the cluster via the Azure portal.

• Sign into the Azure portal at https://portal.azure.com/ • In the top left-hand corner of the Azure portal, select Create a resource > Kubernetes

Service. • Select a Subscription and Resource group. These should be the same subscription and

Resource group used for the Storage Account created previously. • Provide a new Kubernetes Cluster Name, Region (use the same as for the SA and ACR),

Kubernetes version (must be at least 1.13), and a DNS name prefix, such as ems. • For Scale, select the node size. Recommend the default for size for development or testing.

Select a larger size, such as DS3_v2 for production. • Select a node count of 3. • Set virtual nodes and VM scale sets to disabled, if desired, since autoscaling is not required

with EMS. • Click on Next: Authentication • Select to create a new service principal • Click on Yes to Enable RBAC • Click on Next: Networking • Choose either Yes or No for application routing • Choose either Basic or Advanced for Network configuration. Recommend using Basic. • Use the defaults for monitoring • Wait for the Running the Validation to complete, with validation passed. Fix any issues

before continuing! • Click on Create. It will take several minutes to complete.


Figure 7 - Kubernetes Cluster creation

4.2 Configuring Kubectl to connect to Azure Kubernetes Service

With AKS, the Kubernetes command line tool, kubectl, is used to configure the Kubernetes cluster for EMS on AKS.

4.2.1 Configure Kubectl to connect to AKS After the Kubernetes cluster has been built, kubectl must be configured to connect to the cluster on AKS. Use the following example to set the credentials for kubectl.

> az aks get-credentials --resource-group --name

Figure 8 - Configure Kubectl

Use kubectl get nodes as shown in the following example to verify connecting to the cluster.


Figure 9 - Verify connecting to the Kubernetes Cluster

4.2.2 Create a New Namespace Create a new namespace in Kubernetes, if desired. This is optional. The default namespace can be used. Note: If the namespace tibems is not used, ensure the provided yaml files are modified to use the correct namespace or default. The examples shown below will use the tibems namespace.

> kubectl create namespace tibems Figure 10 - Create tibems namespace

4.2.3 Create a Kubernetes Secret to Access the Azure Storage Account Kubernetes needs credentials to access the Azure Storage account used for EMS shared storage. The credentials are stored in a Kubernetes secret. The secret key will be referenced in Section 4.3. This is created through the Azure CLI.

• Use the following to get the Azure Storage Account key.

> az storage account keys list --resource-group --account-name --query "[0].value" -o tsv

Figure 11 - Get Storage Account Key

• Create the azure-secret with kubectl with the namespace (if used).

> kubectl -n tibems create secret generic azure-secret --from-literal=azurestorageaccountname= --from-literal=azurestorageaccountkey=

Figure 12 - Create the Secret Key for the ASA

4.2.4 Create a Kubernetes Secret to Access the Azure Container Registry Kubernetes needs credentials to access the Azure Container Registry used for the Docker images. The credentials are stored in a Kubernetes secret. The secret key will be referenced in Section 4.3. Use the Azure CLI to get the credentials.

• Use the following to get the ACR credentials. Use the username, and either password1 or password2.

> az acr credential show --resource-group --name tibems -o json Figure 13 - Get ACR Credentials

• Create the acr-secret with kubectl with the namespace (if used).


> kubectl -n tibems create secret docker-registry acr-secret --docker-server=.azurecr.io --docker-username= --docker-password= --docker-email=

Figure 14 - Create the Secret Key for ACR

4.3 EMS Server Template

EMS server containers are created in a Kubernetes cluster through the provided tibemsd-template.yaml sample template. A deployment and a service will be created. This template includes sections that define a limited set of parameters, ports, and names for the deployment and the service, which can be changed to meet the environment. Note: The template creates the EMS server with TCP access. This maybe suitable for development and testing environments. However, for production environments, a TLS configuration is highly recommended. See Appendix A: for details for configuring the EMS server with TLS in Kubernetes on AKS.

4.3.1 Adjusting the Services Port Range (Optional) Services of type NodePort or LoadBalancer are used to expose EMS server listen ports outside the cluster. The range of allowed values defaults to 30000-32767. If you intend to use port numbers outside this range for the EMS server or Central Administration server, you can alter the range by using a load balancer in Kubernetes. See the Kubernetes documentation for details.

4.3.2 TIBEMSD Template The tibemsd-template.yaml has several sections that may need modification. The deployment section includes the names of the Kubernetes deployment, ports, and location/name of the ACR repository. The service section contains the port numbers. The default values in the example below can all be used, except for the name and location of the ACR repository, image, and the runAsUser. These must be updated for the environment. Only modify the values marked. Changes to other values may prevent the TIBEMS deployment/service from being created or running. apiVersion: apps/v1 kind: Deployment metadata: labels: name: emstest01 (1) name: emstest01 (1) spec: replicas: 1 selector: matchLabels: name: emstest01 (1) strategy: type: Recreate template: metadata:


labels: name: emstest01 (1) name: emstest01 (1) spec: containers: - name: tibems image: .azurecr.io/ems:latest (2) imagePullPolicy: Always (3) env: - name: EMS_NODE_NAME valueFrom: fieldRef: fieldPath: spec.nodeName - name: EMS_PUBLIC_PORT value: "30722" (4) - name: EMS_SERVICE_NAME value: emstest01 (1) - name: EMS_PROBE_PORT value: "7220" args: - tibemsd livenessProbe: httpGet: path: /isLive port: probe-tcp initialDelaySeconds: 1 (7) timeoutSeconds: 5 periodSeconds: 6 readinessProbe: httpGet: path: /isReady port: probe-tcp initialDelaySeconds: 1 (7) timeoutSeconds: 5 periodSeconds: 6 ports: - containerPort: 7222 (5) name: tibemsd-tcp protocol: TCP - containerPort: 7220 name: probe-tcp protocol: TCP resources: {} securityContext: runAsUser: 1000 (6) terminationMessagePath: /dev/termination-log terminationMessagePolicy: File volumeMounts: - mountPath: /shared name: tibemsd-volume dnsPolicy: ClusterFirst imagePullSecrets: - name: acr-secret (12)


restartPolicy: Always schedulerName: default-scheduler securityContext: {} terminationGracePeriodSeconds: 30 volumes: - name: tibemsd-volume azureFile: secretName: azure-secret (10) shareName: share (11) readOnly: false --- apiVersion: v1 kind: Service metadata: labels: name: emslb (8) name: emslb (8) namespace: tibems (9) spec: externalTrafficPolicy: Cluster ports: - nodePort: 30722 (4) port: 30722 (4) protocol: TCP targetPort: 7222 (5) selector: name: emstest01(1) sessionAffinity: None type: LoadBalancer loadBalancerSourceRanges: - < your trusted IP range> (13) status: loadBalancer: {}

(1): The name of the EMS deployment. If modifying, change ALL locations. (2): The name and location of the Azure Container Repository (ACR) where the TIBCO EMS

Docker image is located. Ensure the proper permissions are set. The image maybe something different for latest, depending on how it was tagged in Docker.

(3): Determines if the EMS Docker image should be pulled from ACR prior to starting the container. Use Always to download the Docker image every time, or Never to use the existing image.

(4): Throughout the template, 30722 is used for the external EMS port. If 30722, is not used, change the value accordingly.

(5): Throughout the template, 7222 is used for the internal EMS port. If 7222, is not used, change the value accordingly.

(6): The uid the container will run as. The default is 1000. Change runAsUser to the uid the EMS server container must run as. Note: The uid provided here must match that used when creating the EMS Docker image.

This constraint should be removed in a future version of Kubernetes.


(7): The initialDelaySeconds determines the delay before the probes become active. This is set for 1 second.

(8): The name of the EMS Load Balancer service. If modifying, change all locations. (9): The name of the Kubernetes namespace used in the cluster. If no namespace is used, changer

to default. (10): The name of the secret created previously to access the Azure Storage Account. Only needs

to be changed if azure-secret was not used. (11): The name of the file shared created previously in the Azure storage account. Only needs to

be changed if share was not used. (12): The name of the secret created previously to access the Azure Container Registry. Only

needs to be changed if acr-secret was not used. (13):The trusted IP range to connect to the external load balancer. If 0.0.0.0 is used, any external

IP can connect (not recommended).

4.3.3 Creating a Deployment and Service Create a deployment and service with an EMS server using the corresponding template. For example: > kubectl apply –f tibemsd-template.yaml –n tibems

The kubectl operation transforms the tibemsd-template.yaml template into a list of resources using the default and overridden parameter values. That list is then passed on to create process for creation. In this particular case, it results in the creation of a deployment, a ReplicaSet, a pod and a service. Three of the four objects can be selected through the emstest01 label. The service will have the label emslb. The service exposes itself as emslb inside the cluster and maps internal port 7222 to port 30722 both inside and outside the cluster. Check the results using the following: > kubectl –n tibems get --selector name=emstest01 all > kubectl –n tibems describe deploy/emstest01 > kubectl –n tibems describe svc/emslb

Figure 15 - Check Deployment Results

or in the Kubernetes Web Console (not documented).

4.3.4 Stopping or Deleting an EMS Server To stop an EMS server without deleting it, use the kubectl scale operation to set its number of replicas to 0.

For example: > kubectl scale --replicas=0 deploy emstest01 –n tibems

To start it again, set its number of replicas back to 1: > kubectl scale --replicas=1 deploy emstest01 –n tibems


To delete an EMS server deployment and service entirely, use the kubectl delete operation. To delete the service, substitute svc for deploy, and emslb for emstest01. For example: > kubectl delete --selector name=emstest01 deploy -n tibems

Figure 16 - To Stop, Start, and Delete the Deployment

The corresponding pod and ReplicaSet will also be deleted. However, the data in the Storage account will not be deleted. This must be manually deleted from the Azure console.

4.3.5 EMS Server Configuration As mentioned in Section 3.1, running a container off of the EMS Docker image creates a default EMS server folder hierarchy and configuration. In an AKS cluster, the configuration will be created under /shared/ems/config/.json. The Central Administration server works in a similar way. This is handled by the tibems.sh script embedded in tibemscreateimage and is invoked through the Docker image ENTRYPOINT. It can be overridden by altering the args entry in the template and is provided only for illustration purposes. Feel free to alter tibems.sh or to directly provision your own configuration files to suit your needs.

4.3.6 Connecting to the EMS Server Container via Kubectl The EMS server logs and configuration can be accessed directly through the following command. Substitute the name of the running EMS pod for . This can be useful for viewing the logs or configuration file. Accessing the pod will be necessary to modify the EMS Connection Factories discussed in Section 5.

> kubectl -n tibems exec -it emstest01- /bin/bash Figure 17 - Accessing the running Container

4.4 Central Administration Server Template

A Central Administration server container is created in the Kubernetes cluster through the tibemsca-template.yaml sample template. The structure of this template is almost identical to that of the EMS server template. Most of the concepts described in the previous section also apply to the Central Administration server. Note: Ensure to update the Docker image location from the ACR, and the external port number. The default is 30088. Note: The Central Administrator is not secure. The following is for example only! JAAS must be implemented in both the EMS server and CA before use. Example of deployment and service creation with a Central Administration server: > kubectl apply -f tibemsca-template.yaml –n tibems


Figure 18 - Apply the EMSA Template


5 Accessing the EMS Server

The EMS server is configured so that access from an EMS client can be internal to Azure, or accessed externally. The section will outline how to connect to the EMS Server.

5.1 Accessing the EMS Server

The EMS Server running in the Docker Container on the node in Azure is externally accessed via the External-IP address and Port created via the emslb service. To get the load balancer External-IP address and Port, use:

> kubectl -n tibems get svc To access the EMS Server within the Kubernetes cluster, use the Cluster-IP and Port associated with the emslb service. To test external access to the EMS Server running the Docker Container on the node in Azure use the EMS tibemsadmin CLI. In the following example, 13.118.90.27 is the IP address if the load balancer, and 30722 is the external port.

> $TIBCO_HOME/ems/8.5/bin/tibemsadmin -server tcp://13.118.90.27:30722

5.2 Modifying the Connection Factories in the EMS Server

The EMS server running in the Docker Container on the node in Azure must be modified for the Connection Factory URLs. The EMS Connection Factories must be updated from the Node Name to the load balancer External-IP address. If not done, the external EMS clients will not be able to reconnect to EMS after a fail-over of the EMS Server deployed in AKS. Note: If external access is not required, the URL should be changed to the Cluster-IP associated with the emslb service. Optionally, an internal and external Connection Factories can be created and used.

The approaches to use to modify the tibemsd json configuration file being used in the container are:

• The tibemsadmin CLI for another machine (can be external) o Use the command shown above to access the EMS Server o Use the setprop option and modify all Connection Factories for the URL o Commit your changes o Exit out of tibemsadmin Note: a script can be created and used to make the modifications via tibemsadmin

• Logging into the Kubernetes node, and modifying the configuration file. o Use kubectl exec –it -n tibems -- /bin/bash o Edit ems/config/emstest01.json and modify all Connection Factories for the URL. o Exit out of the Kubernetes node o Stop and re-start the deployment as defined in Section 4.3.4

• The EMS Central Administrator, if so configured.


o Easiest approach. o Must ensure the Central Administrator is secured. o Modify the Connection Factories for the URL in EMSCA o Save and deploy the new configuration


Appendix A: TLS Configuration

This appendix takes you through the steps of modifying the EMS server template and Docker image build script so that EMS clients can connect to the server through TLS (formerly SSL). Whether an EMS listen port is configured for TCP or TLS makes no difference in terms of exposing it through a Kubernetes service. However, you need to decide how to provision the corresponding certificate files. While these could be placed in the AFS shared folder or embedded in the EMS Docker image, the standard practice in the Kubernetes world consists of using secret objects. These are meant to decouple sensitive information from the pods and can be mounted into containers as volumes populated with files to be accessed by programs. In this example, we will assume we want the EMS server to be authenticated by EMS clients. This involves providing the server with its certificate, private key and the corresponding password, which we will store inside a secret. We will mount that secret into the container, point the EMS server configuration to the certificate and private key files and pass the corresponding password to the server through its -ssl_password command-line option. Based on the sample certificates that ship with EMS, the files will eventually be made available inside the container as follows: /etc/secret/server.cert.pem /etc/secret/server.key.pem /etc/secret/ssl_password

A.1 Creating a Secret

To store the server certificate, private key and the corresponding password in a secret, based on the sample certificates available in the EMS package under ems//samples/certs: > cd …/ems//samples > kubectl create secret generic tibemsd-secret \ --from-file=server.cert.pem=certs/server.cert.pem \ --from-file=server.key.pem=certs/server.key.pem \ --from-literal=ssl_password=password –n tibems

You can check the result this way: > kubectl describe secret tibemsd-secret –n tibems


A.2 Adjusting the Template

The tibemsd-template.yaml template needs to be adjusted to mount the secret as a volume. This involves adding one new entry to the volumes section and another one to the volumeMounts sections. We also need to alter the livenessProbe and the readinessProbe to connect to the server through ssl. kind: Deployment … spec: … template: … spec: containers: - name: tibemsd-container … livenessProbe: … - ssl://localhost:7022 … readinessProbe: … - ssl://localhost:7022 … volumeMounts: - mountPath: /shared name: tibemsd-volume - mountPath: /etc/secret name: tibemsd-secret-volume readOnly: true … volumes: - name: tibemsd-volume azureFile: secretName: azure-secret shareName: share readonly: false - name: tibemsd-secret-volume secret: secretName: tibemsd-secret


A.3 Adjusting the tibemscreateimage EMS Docker image build script

In the tibemsd-configbase.json section: Modify the primary_listen to use ssl: "primary_listens":[ { "url":"ssl://7222" } ],

Add an ssl section pointing to the certificate files: "tibemsd":{ … "ssl":{ "ssl_server_identity":"/etc/secret/server.cert.pem", "ssl_server_key":"/etc/secret/server.key.pem" },

In the tibems.sh section: The tibemsd_run() function needs to be modified to launch the EMS server with the proper value for its -ssl_password command-line option: … if [[ \$# -ge 1 ]]; then PARAMS=\$* else tibemsd_seed PARAMS="-config /shared/ems/config/\$EMS_SERVICE_NAME.json -ssl_password \`cat /etc/secret/ssl_password\`" fi …

A.4 Applying the Adjustments

• Regenerate the EMS Docker image, tag it and push it to the Registry (see section 3.1). • Create a new deployment and service (see section 4.3.2).

Check the results by connecting to the EMS server with one of the EMS TLS sample clients: > java tibjmsSSL -server ssl://13.118.90.27:30722 \ -ssl_trusted ../certs/server_root.cert.pem \ -ssl_hostname server

where tibco experts share, learn, and collaborate. - tibco ......innovation. learn how tibco makes...

Documents