How to manage your ACE application lifecycle in CP4I using Jenkins

How to manage your ACE application lifecycle in CP4I using Jenkins

By Raghavendra Nayak

This blog is a detailed version of a video blog that we have produced. Both blogs walk you through the lifecycle management of an IBM App Connect Enterprise (ACE) application using Jenkins. Watch the YouTube video, if you dislike reading. For this demo, we have adopted the DevOps model as mentioned in our “Deploy ACE integrations automatically onto CP4I” blog.

We are going to use a simple HealthCheck application as shown below. The application responds with the current timestamp and a status message.

Figure 1: Sample application message flow

 

As a prerequisite, you need to create an ACE dashboard in CP4I to visualise the deployed ACE applications in the OpenShift cluster. You can refer to the below links on this topic:

High level sequence

  1. Build and push ACE container image with Version 1 of the application to the image registry
  2. Deploy to CP4I and verify
  3. Build and push ACE container image with Version 2 of the application to the image registry
  4. Update application in CP4I using Jenkins and verify
  5. View tracing and flow statistics
  6. Rollback to Version 1
  7. Delete the application from CP4I

Detailed Steps

STEP 1 - BUILD AND PUSH ACE CONTAINER IMAGE WITH VERSION 1 OF THE APPLICATION TO THE IMAGE REGISTRY

To build and push the container image to the internal OpenShift image registry we have built a Jenkins pipeline as shown below:

Figure 2: Jenkins pipeline

 

We have already developed this application using the ACE toolkit and committed the source code to a git repository. To generate a deployable artefact, this pipeline was triggered manually. You could configure a webhook to trigger it automatically. The pipeline performed the following activities:

  1. Checkout source code from Git;
  2. Build and override the application bar;
  3. Upload the bar file to a Nexus repository;
  4. Create a deployable ACE (docker) container image based on IBM certified ACE base container image;
  5. Tag and push the container image to the OpenShift internal registry.

Upon completion, we saw the output (below) using OpenShift cluster (oc) command. The tag name “v7.0.0.0-amd64” represents Version 1 of the application image.

STEP 2 - DEPLOY TO CP4I AND VERIFY

We have configured a Jenkins job to manage our deployment to the CP4I platform. This job created the necessary access controls, secrets and leveraged the IBM supplied helm charts to deploy the ACE container image into the cluster.

Figure 3: Deploy application Jenkins Job

 

Figure 4: Helm install command

 

We have enabled the tracing capability as part of the application install, the trace enablement created a registration request as part of the deployment process. We must approve the registration request in order to complete the pod deployment.

Figure 5: Tracing registration approval process

 

The ACE dashboard showed the integration server and the application message flow running once the deployment is completed.

Figure 6: Application and message flow in the ACE dashboard

 

We used cURL to test the deployed application. The application returned a successful response as shown below.

Figure 7: Test result

 

STEP 3 - BUILD AND PUSH ACE CONTAINER IMAGE WITH VERSION 2 OF THE APPLICATION TO THE IMAGE REGISTRY

We have updated our application to include the backend status in the application response and pushed the change to the git repository. The pipeline is executed again as described in STEP 1.

Figure 8: Updated source code

 

The new image was pushed to the OpenShift registry with the tag name “v7.0.0.1-amd64”.

STEP 4 - DEPLOY THE APPLICATION UPDATE IN CP4I USING JENKINS AND VERIFY

We executed the same Jenkins job to perform an upgrade of the application runtime by changing the container image name and helm deploy type.

Figure 9: Upgrade application Jenkins job

 

Figure 10: Helm upgrade command

 

Retested the application to verify “BackendStatus” element in the response once the deployment is completed.

Figure 11: Test result

 

STEP 5 - VIEW TRACING AND FLOW STATISTICS

In order to view tracing and flow statistics information, we submitted a constant number of requests to the application for a period of time.

Figure 12: Tracing - Span of a single request to application message flow

 

Figure 13: Grafana - Multiple dashboards showing flow statistics

 

CP4I is pre-configured with the following open source tools for monitoring, logging, visualisation and tracing.

STEP 6 - ROLLBACK TO VERSION 1

To rollback the application update, we performed a helm upgrade using the Version1 container image. You could also choose “helm rollback” command to rollback to a previous revision of the application.

STEP 7 - DELETE THE APPLICATION FROM CP4I

To delete the application, we executed a job which removed the pods and their dependencies from CP4I. The job used the “helm delete” command to clear the resources from the cluster environment.

Figure 14: Delete application Jenkins job

 

Figure 15: Helm delete command

 

TO KNOW MORE


Get in contact to book a workshop to see how Syntegrity can help you.

Raghavendra Nayak is a Senior Integration Specialist with Syntegrity Solutions with a wide range of experience in integration, microservices, automation and hybrid cloud.

Have a question?