The TIBCO Platform is a real-time, composable data platform that will bring together an evolving set of your TIBCO solutions - and it's available now!
A chart showing the TIBCO Platform vision
Jump to content
Articles
Read more about TIBCO use cases, product features, capabilities and more
  • Upgrading TIBCO BusinessWorks Container Engine Runtime in Docker


    Dave Winstone

     

    1. Summary

    2. Building the BusinessWorks Container Edition Base Image

    3. Building the Application Container Image

    4. Updating the Base Image

    5. Conclusion

    Summary

    I considered an alternative Title ? ?How Containerisation massively reduces your upgrade process?, as this is applicable for any technology that you containerise, but I wanted to show you how to do this specifically with TIBCO BusinessWorks Container Edition as it removes one of the biggest costs/effort of upgrading a BusinessWorks infrastructure.

    Let?s consider a scenario with ?classic? BusinessWorks ? either version 5.x or 6.x. Here, you will have a set of servers (deployed on either physical/virtual/cloud) where you deploy the applications that you build. These applications are tested, running and scaled to the right level to cope with your peak demand.

    Let?s say you have BusinessWorks 6.7.0 running and things are nice and stable (as all things TIBCO are of course!). TIBCO release 3 new versions of BusinessWorks over the next 2 years, let?s call them 6.8.0, 6.8.1 and 6.9.0. This means that you are now 3 versions behind and TIBCO?s support policy means that they will announce an end of support date for 6.7.0 in due course. Once that happens ? if you raise a Support Call ? you are quite likely to be asked to perform an upgrade before support is provided.

    So ? to keep up with support you need to upgrade your TIBCO platform to the most appropriate version in order to stay current and make sure that TIBCO will provide support for your version.

    The above policies are valid for most Enterprise Software Vendors in the market today ? so you can replace TIBCO with any other vendor name to suit your environment.

    What it means though, is that you and your development team must build into your plans the appropriate time and effort as part of your BAU process alongside building new projects and providing maintenance for existing projects to ensure you can upgrade the platform.

    Unfortunately, this doesn?t always happen and it can come as an unwelcome surprise that you are going to have to plan an unscheduled upgrade.

    As TIBCO BusinessWorks runs many of the world?s core businesses ? upgrading a classic BusinessWorks infrastructure means a lot of planning. I know of organisations that process Billions of $ orders EVERY DAY on TIBCO ? so your upgrade can?t go wrong. There?s a lot of planning, testing, re-testing and potential downtime too.

    Alongside this ? you?ve also decided to move to Containerisation as part your digital transformation planning and that includes moving your TIBCO BusinessWorks applications to Container Edition.

    If you are already on BusinessWorks 6.x ? moving those applications to Container Edition is pretty straightforward, from BusinessWorks 5.x TIBCO provide tooling to help as well as a migration factory for large projects ? but I want this article to focus on what it means to upgrade the container runtime for a deployed container edition application as there are other resources and blogs that cover migrating to Container Edition.

    If you?ve seen some of my previous blogs ? you?ll recognise my simple Greeting microservice that is a simple REST API that responds with a message and the container hostname:

     

    Screenshot2023-01-10at1_25_02PM.png.bcda39f2bd70da8e6d19da8a047443ce.png 

    This application is built using the following Docker File:

     FROM bwce:latest LABEL maintainer="Dave Winstone" ADD greeting_1.0.0.ear / EXPOSE 8081 7777

    You?ll notice the first line tells the docker build command that I?ll be using the latest version of my TIBCO BusinessWorks Container Edition (bwce) base image. Best practice though is to specify a specific version to ensure you are pulling the right image for your deployment. It also means that you should be maintaining your Docker files in source code control too.

    It goes without saying (almost) that you should also be building and deploying your applications with a DevOps pipeline to automate everything and remove human error ? but I want to show you how you would upgrade the runtime manually.

    The greeting application itself is the ?greeting_1.0.0.ear? file. In this example I?ve changed the output very slightly to include the BusinessWorks runtime engine version as part of the output.

    Building the BusinessWorks Container Edition Base Image

    There?s lots of instructions and different examples of how to do this at TIBCO?s official github repo here that I?d recommend you take a look at.

    I?m going to start with my application built using version 2.7.3 of BusinessWorks Container Edition, then upgrade the runtime to 2.8.0.

    Once you?ve followed the instructions from the TIBCO GitHub to clone the BWCE repo. and downloaded the BWCE runtime from TIBCO?s download site you are ready to build the base image using a command similar to the following from the cloned bwce repo:

     ./createDockerImage.sh ~/bwce-runtime-2.7.3.zip bwce:v2.7.3

    The first argument is the BWCE runtime zip file that you downloaded from TIBCO, and the second argument is the tag we?ll be using.

    Building the Application Container Image

    I?ll adjust my application Dockerfile to include the correct base image tag as follows:

     FROM bwce:v2.7.3 LABEL maintainer="Dave Winstone" ADD greeting_1.0.0.ear / EXPOSE 8081 7777

    Now to build the application:

     docker build -f Dockerfile -t greeting-app:1.0 .

    And to run the application:

     docker run -p 8081:8081 greeting-app:1.0

    To see the results, I can issue a simple Curl command and see the response:

      height=

    So all good.

    But now we have a new version of the BusinessWorks Container Edition Runtime that we want to use ? but I don?t want to rebuild the original EAR file, as that would result in a code change ? leading to regression testing, UAT etc. Plus usually it means that the whole platform needs to be upgraded ? but we only need this single microservice to be updated as there?s a bug that?s been fixed by TIBCO that we need for this single microservice.

    In this instance, all we need to do is rebuild the base image for BusinessWorks Container Edition, alter the Dockerfile of my application to use that new image and then rebuild the container image and re-run.

    Update the Base Image

    To rebuild the base image to use v2.8.0 of BusinessWorks Container Edition, we first need to remove the bwce-runtime-2.7.3.zip from the resources folder under the cloned bwce repo, then run the command (assuming I have downloaded the bwce-runtime-2.8.0.zip file from TIBCO):

     ./createDockerImage.sh ~/bwce-runtime-2.8.0.zip bwce:v2.8.0

    Make a small change to our Dockerfile to use this new version (tag is bwce:v2.8.0):

     FROM bwce:v2.8.0 LABEL maintainer="Dave Winstone" ADD greeting_1.0.0.ear / EXPOSE 8081 7777

    And to rebuild the application:

     docker build -f Dockerfile -t greeting-app:1.0 .

    And to run the application:

     docker run -p 8081:8081 greeting-app:1.0

    And using my Curl command I can test the new version of the application to see if the BusinessWorks Container Edition runtime has been upgraded:

      height=

    Conclusion

    As you can see ? we have successfully upgraded the BWCE runtime within our container for our Greeting microservice.

    This is a huge benefit to containerisation ? particularly where your microservices utilise other frameworks or integration frameworks like TIBCO for your API strategies.

    What?s even more interesting is that this approach does not force you to upgrade every microservice to the same runtime version all at the same time? different versions can co-exist at the same time, which allows you to better plan upgrades alongside existing development and maintenance activities rather than having to plan a separate activity just for upgrading the platform. Co-Existence of containers running different versions of the core run-time is actually a better way of making the best use of developers and operations time.

    If you think about the time, resources and money that you would normally spend on performing this type of upgrade and comparing that to what you save using this approach, I think you?ll agree that taking this approach is well worth the effort.


    User Feedback

    Recommended Comments

    There are no comments to display.



    Create an account or sign in to comment

    You need to be a member in order to leave a comment

    Create an account

    Sign up for a new account in our community. It's easy!

    Register a new account

    Sign in

    Already have an account? Sign in here.

    Sign In Now

×
×
  • Create New...