Wednesday, November 13, 2019

Howto set TIBCO BusinessWorks Container Edition (BWCE) environment variables in AWS Fargate

When you want to run a Docker command in a new container, you use the -e flag for setting environment variables. Below you will find a list of Docker compatible environment variables that users can set during BusinessWorks Container Edition container (BWCE) deployment:

VariableDefault valuesDescription
BW_LOGLEVELERRORUsed to set a log level for the TIBCO BusinessWorks™ Container Edition application. The default value is ERROR. Supported values are:
  • INFO
  • DEBUG
  • WARN
  • ERROR
BW_ENGINE_THREADCOUNT8Used to set engine thread count for the TIBCO BusinessWorks™ Container Edition application.
BW_ENGINE_STEPCOUNT-1Used to set engine step count for the TIBCO BusinessWorks™ Container Edition application.
BW_APPLICATION_JOB_FLOWLIMITn/aUsed to set flow limit for TIBCO BusinessWorks™ Container Edition application.
APP_CONFIG_PROFILEdefaultName of the application profile that is to be used from a configuration management system such as ZUUL, Spring Cloud Config etc.
BW_PROFILEn/aUsed to set the name of the BusinessWorks profile from the application.
BW_JAVA_OPTSn/aUsed to set Java properties that are used at run time. The properties are specified using name-value pairs and are separated by spaces.
For example,
BW_JAVA_OPTS="-Dname=value -Dname=value"
In the AWS Fargate compute engine for Amazon ECS you can set environment variables in the Container Definition as part of your Task Definition. Below example shows how to set the loglevel to "DEBUG". 



Further reading:


  • A quick howto on deploying BWCE applications to AWS Fargate can be found here.
  • For more info on how to use other out-of-thebox logging capabilities of BWCE, check out this blog from Jurriaan Brandsma here

Friday, July 12, 2019

Deploy a TIBCO BusinessWorks Container Edition (BWCE) application to Amazon's cloud platform AWS Fargate



This article explains how to deploy applications, built with TIBCO's containerization offering TIBCO BusinessWorks Container Edition (BWCE), to Amazon's cloud platform AWS Fargate.

Introduction

When you want to launch a container on AWS Elastic Container Service (ECS) you need to choose the launch type: container instances (just EC2 under the hood) or Fargate. Fargate is the smart choice when you don't have the need to fiddle with IaaS-level stuff that EC2 instances bring. Each task that runs in Fargate comes with a dedicated Elastic Network Interface (ENI) with a private IP address. All containers of the same task can communicate with each other via localhost. Inbound and outbound task communication goes through the ENI. A public IP address can be enabled as well.

The premise of TIBCO BWCE is to simplify integration of backend APIs and systems, embrace native features of chosen container management platforms (like AWS Fargate) and speed up time to market.

With aforementioned tools you have enough ingredients to become dangerous in cloud land. Let's go!

Prerequisites

To get to know BWCE in a quick and digestiver manner, read this article "TIBCO on Docker: How to create, instantiate and start a TIBCO BusinessWorks Container Edition (BWCE) application Docker Image?" by Rubén Middlejans.

The thing you need to be aware with Fargate is that before creating the Docker image, you need to create a new hostname ModuleProperty and set it to value '0.0.0.0'. The reason why is because AWS Fargate only accepts AWS VPC networking. By using 0.0.0.0 the application will bind to the specific IP-address that's being used on your Fargate deployment.

Steps

Build the BWCE Docker image and push it to Amazon Elastic Container Repository (ECR).
  1. Login to ECR by running (choose your own region):
    aws ecr get-login --no-include-email --region eu-west-1 A long string will be returned like: docker login -u AWS -p ........ Copy the whole string and run it as a new command. Note: if aws ecr get-login doesn't work, you might need to configure AWS first. Perform a aws configure and enter your AWS Access Key ID and your AWS Secret Access ID (get them from the Security Credentials page on your profile).
  2. Create your Docker image by running a docker build command and using the AWS ECR repo URI as the tag.

    For Example:
    docker build -f DockerFargate -t 123456789012.dkr.ecr.eu-west-1.amazonaws.com/reponame:appnameNote 1: the URI value can be retrieved by logging in to AWS ECR and copying the value of the repo you want the image to be pushed to.

  3. Note 2: When your image is using other images that aren't present in your local Docker registry yet, you need to log in to Docker by using docker login.
  4. You are ready to push the image to ECR. Use command: docker push 123456789012.dkr.ecr.eu-west-1.amazonaws.com/reponame:appname And wait. Your Terminal will show a nice loader. First time can take a few minutes. When the loader is gone, your upload job is done! Refresh your ECR browser window to validate that your Docker image is there.
Define the AWS Fargate task
  1. Create an AWS Fargate Task. Select the Fargate Launch Type;
  2. Choose the image name of the image you just uploaded. Configure:
    * Set Task Memory to 1GB;
    * Set Task CPU to 0.5;
    * Add container and set memory limit to 512, set port mapping, CPU units top 100 and use out of the box logging from awslogs;
  3. Create a cluster. Create a separate VPC because you want to separate all your different types of applications in different VPCs.

    Note: if you care about auto-scaling, load balancing etc. create a Service which will then refer to youTask. If not, you can just create a Task itself. 
Run the BWCE application that you have just defined in your task.
  1. Choose Launch type Fargate;
  2. The task definition is Fargate compatible so no error message should be seen;
  3. Give Task group a name, eg bwce-fargate-group;
  4. Choose your created VPC;
  5. Auto-assign public IP: ENABLED;
  6. Security Group: expose your port(s);
  7. Validate that the status of your task is 'RUNNING'.



And you are done!








Friday, March 1, 2019

Install JMeter on macOS and configure a SOAP WebService Test Plan using HTTPS

Prerequisites


Installation steps

  • Install JMeter by running Terminal command: brew install jmeter
  • Test the install by running command jmeter -h
  • To run the app just type jmeter in Terminal

Additional configuration steps

Use a client-side certificate

  • Prepare a Java KeyStore file. Example command to create a jks file:
  • Cd to /usr/local/Cellar/jmeter/3.1/libexec/bin/ and open the system.properties file.
  • Go to your JMeter directory and open your system.properties file. In there, uncomment the following lines, and change the file to match your values:
  • javax.net.ssl.keyStore=<your_JKS_filename.jks>
    javax.net.ssl.keyStorePassword=yourJKSpassword

Create a Test Plan

We're going to create a SOAP WebService Test Plan from a template
  • Go to File / Templates and select the SOAP WebService Test Plan test plan. In the editor steps will be loaded
  • Click on HTTP Request Defaults. In Server Name or IP field fill in the hostname or IP address
  • Click on Soap Request (child of Number of Users step)
    • Protocol: https
    • Server Name or IP: hostname or IP address
    • Port Number: 443
    • Method: POST
    • Path: path or the URL. like /resource/123/v1
    • Body data tab: full SOAP request XML message
  • Click on HTTP Header Manager and create a SOAPAction header if applicable
  • Add step View Results Tree and configure in order to see the response message after starting the test. 
  • Done! 

References

  • https://jmeter.apache.org/
  • https://www.ubik-ingenierie.com/blog/using-homebrew-to-install-and-configure-jmeter-under-mac-osx/
  • https://www.blazemeter.com/blog/how-set-your-jmeter-load-test-use-client-side-certificates