This walkthrough provides step-by-step guidance to&nbsp;containerise and run&nbsp; BE applications&nbsp;on Microsoft&nbsp;Azure based Kubernetes&nbsp;cluster.

The goal of this walkthrough is to enable users to containerise their BE applications on Microsoft Azure seamlessly. The following BE applications are covered&nbsp; for containerisation in this guide -&nbsp;

The build tool used to containerize the BE applications covered in this walkthrough guide is <code class="inline-code">docker</code>. However, <code class="inline-code">buildah</code> tool can also be used for containerizing the BE applications.

Getting Started

As mentioned in the pre-requisites,&nbsp; create a Resource Group from the Azure UI or CLI. A Resource Group is a logical container into which the Azure resources are deployed and managed.

Azure Kubernetes Services (AKS) manages the Kubernetes environment and provides options to deploy the Kubernetes cluster.

The output of this command provides the&nbsp;<code><code class="inline-code">appId</code></code>&nbsp;which is the service principal and&nbsp;<code></code><code class="inline-code"><code>password</code>&nbsp;</code>which is the&nbsp;<code>client-secret</code>&nbsp;for creating the Kubernetes cluster.

Microsoft Azure creates a storage account when a Kubernetes cluster is created.

Microsoft Azure uses the Azure Container Registry for securely building and deploying your applications. To create an Azure Container Registry, you need to create an Azure Resource group

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.

Setup

Containerising 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&nbsp;cloud&nbsp;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 the&nbsp; 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 Azure Container Registry

Step 3: Run The BE Application on Azure using Helm

Helm Charts can be used to run the BE Applications on Azure.&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 = azure &lt;cluster provider value&gt; - cmType = unclustered &lt;cluster manager value&gt; - enableRMS = false (keep as false) - rmsDeployment = false (make true for RMS project)</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: (This can be obtained from the Azure Portal -&gt; Container Registry -&gt; Access Keys)&nbsp; - password: (This can be obtained from the Azure Portal -&gt; Container Registry -&gt; Access Keys)&nbsp;</code>

<code class="inline-code">name: inferenceagent PU:default set replicas: 1 (set this to 1 since this is in-memory application)</code> <code class="inline-code">name: cacheagent PU:cache replicas:0 (set this to 0 since this is in-memory application)</code>

Sample values.yml file is provided below.&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.

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;

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 for testing on the port(local) specified in the above command.&nbsp;&nbsp;

Containerising 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 Azure 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.

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 = azure &lt;cluster provider value&gt; - cmType = ignite &lt;cluster manager value&gt; - enableRMS = false (keep as false) - rmsDeployment = false (make true for RMS project)</code>

<code class="inline-code">update the image name: - image credentials: &lt;Name provided while creating the docker image&gt; - registry: &lt;Name of the ACR created earlier&gt; - username: (This can be obtained from the Azure Portal -&gt; Container Registry -&gt; Access Keys)&nbsp; - password: (This can be obtained from the Azure Portal -&gt; Container Registry -&gt; Access Keys)&nbsp;</code>

<code class="inline-code">name: inferenceagent PU:default set replicas: 1 (set this to 1 since this is in-memory application) name: cacheagent&nbsp;</code>

<code class="inline-code">PU:cache replicas:1 (set this to 1 since this is a cache OM application)</code>

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

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

Containerising 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 Application ( Bundled CreditCard example project) configured with AS2 Cluster and Cache as the Object Management and Persistence Option: None. 

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

Step 2: Push The Container Image To Azure Container Registry

Step 3: Run The RMS Application On Azure Using Helm

Helm Charts can be used to run the RMS Applications on Azure.

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

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

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

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

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

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

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

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

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

Containerize TIBCO BusinessEvents (BE) Applications on Azure

Arpita Sumedh Tirodkar

Overview

Goal

Assumptions

Pre-requisities