This walkthrough provides step-by-step guidance to&nbsp;containerize&nbsp; TIBCO BusinessEvents (BE) applications on AWS EKS.

The goal of this walkthrough is to enable users to containerize their BE applications on AWS EKS seamlessly. The following BE applications are leveraged in this guide.&nbsp;

You can configure the credentials in the command prompt (which can then be used for other operations like build/push image) using the <code class="inline-code">aws configure</code> command as shown below -&nbsp;

<code class="inline-code">aws ecr get-login-password --region &lt;&lt;&gt;&gt; | docker login --username &lt;&lt;&gt;&gt; --password-stdin &lt;&lt;&gt;&gt;</code>

<code class="inline-code">eksctl create cluster --region us-east-2</code>

The cluster currently used (denoted by *) can be checked using the command -&nbsp;

<code class="inline-code">kubectl config get-contexts</code>

Various steps that are used to run a containerized BE application have been listed below and explained in details in the later sections.

These steps have&nbsp; been covered in details in the subsequent sections for the different types of BE applications as listed above.

Getting Started

Containerizing an in-memory BE Application

Once all the prerequisites (as mentioned earlier) are met, we can build the container image for a BE application, push the created docker image on AWS and run the application using Helm Charts. 

Based on the BE application type - In Memory OM/ Cache OM/ RMS, the steps would differ and are covered in detail in the subsequent sections of this walkthrough.

This section covers the steps for containerizing an In-Memory BE application.

The cloud folder provides&nbsp;<code class="inline-code">build_image</code>&nbsp;script file to build a container image of the BE application by using bundled Dockerfiles. Dockerfiles are available in&nbsp;<code class="inline-code">BE_HOME/cloud/docker/dockerfiles</code>&nbsp;folder.

In this section, let's cover the steps for building a BE application image using BE cloud tools, the downloaded software installers/installed BE product, and the application artifacts -&nbsp; which consists of the BE Application EAR, CDD, and any 3rd Party JAR files.

Syntax -&nbsp;

Step 2: Push The Container Image to AWS Cloud

Once the container image for the BE application is created,&nbsp; it needs to be tagged and pushed to AWS.&nbsp; For this, we use the docker tag and docker push commands. 

Make sure to login to the AWS account using the awscli.

After the container image for the BE application is tagged,&nbsp; it needs to be pushed to AWS. 

For this, we use the docker push command. Make sure to login to the AWS account using the awscli.

Step 3: Run The BE Application on AWS using Helm

Helm Charts can be used to run the BE Applications on AWS.&nbsp;

Helm refers to the Values.yml file for the project configurations.&nbsp; Values.yml file is present at&nbsp;&lt;be_tools_master&gt;\cloud\kubernetes\helm directory. Update the file for the project specific configurations.

<code class="inline-code">- cpType = aws &lt;cluster provider value&gt; &nbsp;- cmType = unclustered &lt;cluster manager value&gt;&nbsp; - enableRMS = &lt;false&gt; (keep as false) - rmsDeployment = &lt;false&gt; (make true for RMS project)</code>

<code class="inline-code">update the image name: - image credentails:&nbsp; - registry: - username: - password:</code>

<code class="inline-code">name: inferenceagent PU:default set replicas: 1 (set this to 1)</code>

<code class="inline-code">name: cacheagent&nbsp; PU:cache replicas:0</code>

Sample values.yml file is provided below.&nbsp;

Once the configurations are updated in the yaml file, run the helm install command as below to run the application -&nbsp;

helm upgrade command can be used if any changes are made to the existing application and it needs to be deployed.

Step 4: Access logs of the deployed BE Application

Logs of the deployed BE application can be accessed via the kubernetes pod on which the application is deployed and running.

Get the pod details on which the application is deployed and running using the below command -&nbsp;

This command displays the&nbsp; the apps deployed/running in the environment with their Pod name. 

To get the specific podname for the desired application, the following command can also be used -&nbsp;

Verify the application logs for the application pod using the below command-&nbsp;

You can access the deployed application if it needs input from the user as below :

Get the details of the services, pods along with their port and IP details using the below command:

Once you get the service details, you can use the below command to access the endpoint locally -&nbsp;

The application can then be accessed locally on the port(local) specified in the above command.&nbsp;&nbsp;

Containerizing an In-Memory BE Application

Once all the prerequisites (as mentioned earlier) are met, we can build the container image for a BE application, push the created docker image on AWS and run the application using Helm Charts.

This section covers the steps for the BE applications configured with Ignite Cluster and Ignite Cache as the Object Management and Persistence Option: None.

In this section, we will cover the steps for building a Cache OM BE application image using BE cloud tools, the downloaded software installers/installed BE product and the Application artifacts -&nbsp; which consists of the BE Application EAR, CDD and any 3rd Party JAR files.

Step 2: Tag and Push The Container Image to AWS Cloud

Helm refers to the Values.yml file for the project configurations.&nbsp; Values.yml file is present at&nbsp;&lt;be_tools_master&gt;\cloud\kubernetes\helm directory. Update the file for the project specific configurations:

<code class="inline-code">- cpType = aws &lt;cluster provider value&gt; &nbsp;- cmType = ignite &lt;cluster manager value&gt; - enableRMS = &lt;false&gt; (keep as false) rmsDeployment = &lt;false&gt; (make true for RMS project)</code>

<code class="inline-code">name: cacheagent&nbsp; PU:cache replicas:1 (set this to 1 for Cache OM)</code>

Ensure the values for the Cloud Provider and Cluster Manager are updated correctly as configured in the project. The image details with the appropriate tag as given in the above commands also needs to be populated. 

Cache and Inference agents are updated correctly in the values.yaml file -&nbsp;

Once the configurations are updated in the yaml file, run the helm install command as below to run the application -&nbsp;

helm upgrade command can be used if any changes are made to the existing application and it needs to be deployed.

Step 4: Access Logs Of Deployed BE Application

Logs of the deployed BE application can be accessed via the kubernetes pod on which the application is deployed and running using the below command -&nbsp;

This command displays the&nbsp; the apps deployed/running in the environment with their Pod name. To get the specific podname for the desired application, the following command can also be used -&nbsp;

You can access the deployed application if it needs input from the user (as in case of the FDCache bundled example) as below :

Containerizing a Cache OM BE Application

Once all the prerequisites (as mentioned earlier) are met, we can build the container image for a BE RMS application, push the created docker image on Azure and run the application using Helm Charts.

For a BE Application with RMS, we need to have both the RMS and the BE Application container images running.&nbsp; The&nbsp; BE application container is for any non-RMS BE applications - it can be the bundled example like the CreditCardApplication or any other custom application. The shipped RMS EAR/CDD has the&nbsp; samples bundled - so you can edit rules or check deployment. But you would need the corresponding BE Application running for hot-deploying the rules. Without the BE application running, the rule changes cannot be hot deployed.

This section covers the deployment steps for RMS and also the BE RMS application ( Bundled CreditCard example project) configured with AS2 Cluster and Cache as the Object Management and Persistence Option: None.&nbsp;

For RMS Project, we need to build and run 2 Container Images - One for RMS and the other for the Webstudio BE application.

Step 1: Building The Container Image&nbsp;

Step 3: Run The RMS Application on AWS using Helm

Helm Charts can be used to run the RMS Applications on AWS.&nbsp;

Helm refers to the Values.yml file for the project configurations.&nbsp; Values.yml file is present at&nbsp;&lt;be_tools_master&gt;\cloud\kubernetes\helm directory. We need to update the values.yaml file for the RMS deployment as well as the BE Application deployment.

Update the values.yaml file for the RMS specific configurations.

<code class="inline-code">- cpType = aws &lt;cluster provider value&gt; &nbsp;- cmType = AS2 &lt;cluster manager value&gt; - enableRMS = false (keep as false for RMS application) - rmsDeployment = true (make true as this is for RMS application)</code>

<code class="inline-code">update the image name: - image credentials: &lt;Name provided while creating the docker image&gt;&nbsp; - registry: &lt;Name of the ACR created earlier&gt; - username: &lt;username&gt;&nbsp; - password: &lt;password&gt;&nbsp;</code>

<code class="inline-code">name: inferenceagent PU:default set replicas: 1 (set this to desired value )</code> <code class="inline-code">name: cacheagent&nbsp; PU:cache replicas:1 (set this to desired value)</code>

for Dynamic Provisioning : <code class="inline-code">storageClass:efs-sc</code>

Sample values.yaml file configured for RMS Application deployment -&nbsp;

Once the configurations are updated in the yaml file, run the <code class="inline-code">helm install</code> command as below to run the application -&nbsp;

<code class="inline-code">helm upgrade </code>command can be used if any changes are made to the existing application and it needs to be deployed.

<code class="inline-code">- cpType = aws &lt;cluster provider value&gt; &nbsp;- cmType = AS2 &lt;cluster manager value&gt; - enableRMS = true (keep as true for BE-RMS application) - rmsDeployment = false (make false as this is for BE-RMS application project)</code>

for <code class="inline-code">rmsSharedPVS: "RMSDEPLOYMENTNAME-rms-shared</code>" —&gt; replace with the value for RMSDEPLOYMENTNAME. This is required for the communication between the RMS Server and the BE Application.

<code class="inline-code">- scSupportsReadWriteMany: true</code>

Sample values.yaml file configured for BE Application deployment -&nbsp;

Step 4: Access logs of deployed BE Application

Application logs can be verified using the below command -&nbsp;

You can access the deployed application if it needs input from the user (as in case of the FDCache/ CreditCard - RMS bundled example) as below :

Containerize TIBCO BusinessEvents (BE) applications in AWS EKS

Arpita Sumedh Tirodkar

Hitesh Nembhwani

Overview

Goal

Assumptions

Pre-requisites

Steps