Introduction
We bring you exciting news from the forefront of innovation. We have recently released a comprehensive set of Helm charts for deploying webMethods components, including the API Gateway, Developer Portal, MyWebMethods Server, Universal Messaging, and Microservices Runtime, in a Kubernetes environment on GitHub (GitHub - SoftwareAG/webmethods-helm-charts: This repository contains a collection of Helm charts for various webMethods components.). Join us on this voyage of seamless deployment as we explore the power of Helm charts with clear and concise instructions.
Getting Helm-Ready
Before we embark on this journey, let’s ensure we have all the necessary tools at our disposal. Begin by installing Helm on your system. If you haven’t done so already, visit the Helm website (https://helm.sh) for installation instructions. Remember, Helm will serve as our trusted compass throughout this adventure!
Helm in 60 seconds
Helm is a package manager for Kubernetes that simplifies the deployment and management of containerized applications. It uses “charts” to package Kubernetes resources and configurations, allowing for easy installation, upgrades, and customization.
Helm repositories store charts and the Helm CLI helps users interact with and manage releases of these charts in Kubernetes clusters.
The workflow for using Helm is as follows:
- Create or obtain a Helm chart (like the webMethods helm chart library) that describes your application (1).
- Customize the chart’s configuration by creating a values file or specifying values on the command line.
- Use the Helm CLI to install the chart, specifying the values and release name (2).
- Helm generates Kubernetes manifests based on the chart and values, deploys them to your cluster, and tracks the release (3,4).
You can use Helm to upgrade, roll back, or uninstall releases as needed.
Installing Helm
Helm is available for Linux, macOS, and Windows. You can install Helm using a package manager or download the binary and install it manually. Install Helm on a Linux System via the following command:
curl https://raw.githubusercontent.com/helm/helm/master/scripts/get-helm-3 | bash
For Windows and macOS, visit the Helm website for installation instructions at Helm | Installing Helm.
Deploying webMethods with Helm
With our newly acquired webMethods Helm charts, deploying webMethods components becomes a breeze. Utilizing the Helm command, we can effortlessly deploy any webMethods component within our Kubernetes cluster. Let’s set sail by running the following commands in your terminal:
Adding the webMethods Helm repository
helm repo add webmethods https://open-source.softwareag.com/webmethods-helm-charts/charts
Listing the available webMethods Helm charts
You can view the available charts via:
helm search repo webmethods
Which should result in the following output:
NAME CHART VERSION APP VERSION DESCRIPTION
webmethods/mywebmethodsserver 1.0.0 10.15 My webMethods Server (MWS) Helm Chart for Kuber...
webmethods/apigateway 1.0.0 10.15 API Gateway Helm Chart for Kubernetes
webmethods/common 1.0.0 1.0.0 A Library Helm Chart for grouping common logic ...
webmethods/developerportal 1.0.0 10.15 webMethods Developer Portal Helm Chart for Kube...
webmethods/microservicesruntime 1.0.0 10.15 Microservices Runtime (MSR) Helm Chart for Kube...
webmethods/universalmessaging 1.0.0 10.15 Universal Messaging (UM) Helm Chart for Kubernetes
Install webMethods components
To install any of the webMethods components use the following command:
helm install <my-release> webmethods/<component-name>
Replace <component-name> with the specific webMethods component you wish to deploy, such as apigateway, developerportal, mywebmethods, universalmessaging, or microservicesruntime. And replace <my-release> with the name of your release.
Sit back and observe as Helm charts expertly handle the provisioning and orchestration of your chosen webMethods component.
Upgrading with Helm
In the ever-evolving realm of technology, it is vital to keep your webMethods components up to date. Helm charts simplify the process of upgrading your components to the latest versions. To upgrade a webMethods component, execute the following command:
helm upgrade <my-release> webmethods/<component-name>
By utilizing the upgrade command, you can ensure that your webMethods components remain current, benefitting from the latest features and improvements.
Please note, if you are using StatefulSets, you must use the helm upgrade --force command to force the upgrade - in this case, the upgrade will be performed one pod at a time. In some cases depending on your scenario, you may need to delete the StatefulSet and re-create it.
In CI/CD pipelines you may want to use the helm upgrade --install command to install the chart if it does not exist, or upgrade it if it does exist.
Configuring Helm Charts
Helm charts offer an array of configuration options to tailor your deployments according to your specific requirements. Customization is made simple by overriding default settings or specifying custom values. For instance, to modify the number of replicas in your webMethods component deployment, use the --set flag:
helm upgrade <my-release> webmethods/<component-name> --set replicaCount=3
With this capability, you can adapt the scale and behavior of your webMethods components to suit your needs effectively.
Rollback and Recovery
While sailing these technological waters, we may encounter rough patches and unforeseen challenges. Fear not, for Helm charts provide a rollback mechanism, allowing us to revert to previous versions and restore stability to our deployments. In the event of a failed upgrade, execute the following command to initiate a rollback:
helm rollback <my-release> 1
This powerful command allows us to navigate away from troubled waters and regain a solid foundation for our webMethods components (in this case back to revision 1).
A word of caution, however, the rollback command will only work if the chart has not changed between the current and previous versions. If the chart has changed, you will need to use the --force flag to force the rollback (in our webMethods chart library we will ensure that versions are not altered and new versions are released in case of changes - however, if you fork or copy the charts you will need to consider versioning also).
Also in some cases, a rollback may not be possible, for example, if you have dependent backing services such as databases that have been updated and are no longer compatible with the previous version of the webMethods component. In this case, you will need to restore the database to a previous backup (or attach Helm Chart Hooks (see Chart Hooks), that perform specific rollback jobs to support you with this), keep this in mind when handling with stateful components.
Uninstalling with Helm
If you wish to remove a webMethods component from your Kubernetes cluster, you can use the uninstall command:
helm uninstall <my-release>
This command will remove all Kubernetes resources associated with the release, including pods, services, and persistent volumes. Helm does this by deleting all resources associated with the release, except for Secrets, ConfigMaps, and PersistentVolumeClaims. These resources are not deleted by default because they may contain valuable data that you may wish to preserve. If you wish to delete these resources, you can use the --purge flag:
webMethods Helm Chart Library
The webMethods Helm Chart Library is a collection of Helm charts for deploying webMethods components in a Kubernetes environment. Chart sources, documentation, and examples are available on the Software AG Github repository at: GitHub - SoftwareAG/webmethods-helm-charts: This repository contains a collection of Helm charts for various webMethods components.
Our helm charts have been designed to offer a consistent and intuitive experience for deploying webMethods components in Kubernetes. The charts are based on our official Software AG container images from https://containers.softwareag.com or if required, provide information on how to build your custom webMethods images) for each component and are configured to use Kubernetes resources such as StatefulSets, Deployments, Services, ConfigMaps, Ingresses, Secrets, etc. The charts also support the use of persistent volumes for storing data if required.
If you need to extend certain components, the charts provide a mechanism for adding also additional Kubernetes resources to the deployment like additional ConfigMaps, Secrets, or Services, Jobs, initContainers, lifecycle hooks, etc.
Example Deployment of Microservice Runtime
Let’s take a look at an example deployment of the Microservices Runtime component. Begin by adding the webMethods Helm repository:
helm repo add webmethods https://open-source.softwareag.com/webmethods-helm-charts/charts
To pull images from the Software AG Containers Registry (sagcr.azurecr.io → https://containers.softwareag.com), create an “Image Pull Secret” with your registry credentials. Should you prefer to use your private registry, replace the details accordingly to ensure secure image retrieval.
kubectl create secret docker-registry regcred --docker-server=sagcr.azurecr.io --docker-username=<your-name> --docker-password=<your-pwd> --docker-email=<your-email>
Before you can install the Microservices Runtime you will need to install a valid license for the Microservices Runtime component:
kubectl create configmap microservicesruntime-license-key --from-file=licensekey=<your path and filename to Microservices Runtime license file>
Next, install the Microservices Runtime component:
helm install my-msr webmethods/microservicesruntime
This command will deploy the Microservices Runtime component in your Kubernetes cluster under the default namespace (you can use a separate namespace by providing -n <namspace> if required). You can verify the deployment by running the following command:
kubectl get pods
You should see the following output:
NAME READY STATUS RESTARTS AGE
my-msr-microservicesruntime-57c7bcb8f4-gv24c 0/1 ContainerCreating 0 3m11s
You can also list the Helm releases in your cluster by running the following command:
helm list
which should produce the following output:
NAME NAMESPACE REVISION UPDATED STATUS CHART APP VERSION
my-msr my-msr 1 2023-09-21 15:57:29.79356 +0200 CEST deployed microservicesruntime-1.1.0 10.15
Congratulations! You have successfully deployed the Microservices Runtime component in your Kubernetes cluster. Now, let’s take a look at the various configuration options available for this component.
Configuration Options
The Microservices Runtime Helm chart offers a variety of configuration options to customize your deployment. You can override default settings or specify custom values to tailor your deployment according to your specific requirements. For instance, to modify the number of replicas and the default ingress in your deployment, use the --set flag:
helm upgrade my-msr webmethods/microservicesruntime \
--set replicaCount=3 \
--set "ingress.hosts[0].host=my-msr.mydomain.com" \
--set "ingress.hosts[0].paths[0].path=/" \
--set "ingress.hosts[0].paths[0].pathType=Prefix" \
--set "ingress.hosts[0].paths[0].port=5555"
With this capability, you can adapt the scale and behavior of your Microservices Runtime deployment to suit your needs effectively as well as deploy automatically ingress rules to access your microservices runtime through the URL my-msq.mydomain.com.
For more complex settings it is recommended to provide your own values.file and use the --values flag to specify the file:
helm upgrade my-msr webmethods/microservicesruntime --values my-values.yaml
Example values.yaml
The following example values.yaml file shows how to configure the Microservices Runtime component:
# values.yaml
image:
repository: "store/softwareag/webmethods-microservicesruntime"
tag: "10.15.0.10"
Using a Custom Container Image
In reality, you will most likely want to use your own custom images for your Microservice Runtime image, as we have basically just deployed an empty Microservices Runtime with no solutions in it.
To do this, you will need to build your own images and push them to a container registry. You can then use these images as your base image in the Helm chart. There are two ways to do this:
Extending from the Software AG base image
FROM store/softwareag/webmethods-microservicesruntime:10.15.0.10
# copy your solutions to the image
COPY --chown=1724:1724 ./solutions /opt/softwareag/IntegrationServer/packages
Build and push the image to your container registry:
docker build -t <image-name>:<image-tag> .
docker push <image-name>:<image-tag>
Where the image tag uses your private container registry, for example:
docker build -t myregistry.io/myrepo/my-msr:10.15.0.1
To use the new image simply specify the image name and tag in the values.yaml file:
image:
repository: "myregistry.io/myrepo/my-msr"
tag: "10.15.0.1"
Building a custom image via the SAG Installer
To build a custom image via the SAG Installer, you will need to download the Software AG Installer for Linux and execute the following command:
./SoftwareAGInstaller202103.001_Linux_x86_64.bin create image -i <image-name> -l <license-key>
This will create a custom image with the name and the license key in your local Docker registry.
Once you have tagged the image and pushed it to your container registry, you can use it as your base image in the Dockerfile:
FROM <image-name>:<image-tag>
# copy your solutions to the image
COPY --chown=1724:1724 ./solutions /opt/softwareag/IntegrationServer/packages
In upcoming releases, the webMethods Package Manager (wpm) will streamline containerization by eliminating the need to create base images manually. Instead, users will be able to leverage the official base images directly from the containers.softwareag.com registry. The process will be simplified to adding necessary Adapters and Solutions atop the base image within a Dockerfile, facilitating a more efficient and straightforward integration.
More Examples
Please check the Microservices Runtime Helm Chart Readme for a complete list of configuration options.
Additional examples for configuring the Microservice Runtime component for specific scenarios such as Process Engine, Client-side Queuing (CSQ), Service Auditing and others can be found in the Microservices Runtime Helm Chart Examples
Conclusion
Congratulations once again, intrepid sailors of the webMethods seas! Equipped with the latest Helm charts for webMethods components, you can confidently deploy and manage these powerful tools within your Kubernetes environment. But remember, Helm charts are just one part of a larger ecosystem.
If you need expert guidance or assistance with your journey into modern cloud infrastructures, such as Kubernetes and OpenShift, our Professional Services teams are ready to assist you. With their extensive experience and expertise, they can provide invaluable support in optimizing your infrastructure and ensuring a seamless integration of webMethods components. Please also check our service offerings from here: Digital Transformation: Software AG Professional Services
Set sail with confidence, knowing that expert help is just a reach away. Embrace the power of webMethods in Kubernetes seas with Helm charts as you navigate the ever-changing tides of technology.
Fair winds and expert guidance on your magnificent voyage!
Disclaimer
Note, the Software AG Github Helm Charts provided are samples from field experiences from the Software AG Professional Services team, without any warranty or official support. Feel free to fork and adopt the github helm repository to your needs or use them as library charts directly as described in this article. We are happy to take pull requests and improvements from the community.
References
#Integration-Server-and-ESB#API-Management#webMethods#Developer-Portal#Universal-Messaging-Broker#API-Gateway#BPM#tutorial