Mariela Dimitrova for Software AG Tech Community

Posted on Sep 1, 2021 • Originally published at tech.forums.softwareag.com on Aug 19, 2021

Deploying a Microgateway Kubernetes Sidecar using Helm Charts

#kubernetes #microgateway #helm #tutorial

Introduction

A Microgateway Kubernetes sidecar deployment can be established by creating a pod containing two containers; one container runs the native service, and the other container runs the Microgateway protecting the native service.

The native services are accessed by consumers through the Microgateway endpoint.

To access the native service from the Microgateway container, Microgateway has to use localhost as URL together with the port exposed by the native service as both the containers are treated as being within the same host.

There are two types of sidecar deployment models:

A stand-alone Kubernetes sidecar deployment ( For more details please refer the article Microgateway Stand-alone Kubernetes Sidecar Deployment - Knowledge base - webMethods - Software AG Tech Community & Forums )

A Kubernetes sidecar connected to API Gateway ( For more details please refer the article Deploying Microgateway as Kubernetes Sidecar Connected to API Gateway - Knowledge base - webMethods - Software AG Tech Community & Forums)

In this article we will see how we can deploy Microgateway as Kubernetes sidecar connected to API Gateway using Helm charts.

Helm is a package manager for Kubernetes. It helps you manage Kubernetes applications — Helm Charts help you define, install, and upgrade even the most complex Kubernetes application. For more details refer Helm | Docs

Audience

This document is intended for users who wants to deploy Microgateway as Kubernetes sidecar connected to API Gateway using helm charts.

Pre-Requisites

Basic Knowledge on Docker, Kubernetes, Helm
The native service Docker images are pushed to a Docker registry to make them available for the Kubernetes environment
Create API in API Gateway
Understanding on Microgateway
Docker and Kubernetes environment setup
Helm installation

Use Case

In this article we will see how we can deploy the microgateway as Kubernetes sidecar using Helm charts.

We will be using PostalCode native service docker Image which is a simple Java based application which will return the postalCode when queried with the specific latitude and longitude.

Deploying a Microgateway Kubernetes Sidecar connected to API Gateway using Helm Charts

Before you start with the deployment ensure you have done the following:

Ensure you have a running Kubernetes environment with Helm installed
There is an API Gateway instance running in a dedicated Kubernetes service.
There is a native service Docker image in the Docker registry

Below are the steps about how we can achieve microgateway Kubernetes sidecar deployment using helm charts

1. Create a Microgateway Docker image

Navigate to the Microgateway installation directory

<InstallationDir>\Microgateway

Create the configuration file pull-postalcode-service.yml that holds the configuration for pulling the definition of the PostalCode API from API Gateway.

Below is the snippet of the configuration file used for pulling the PostalCode API

Where,

<<APIGatewayISHost>> is the Host IP of the Integration Server where the API Gateway is hosted.

<<APIGatewayISPort>> is the Port of the Integration Server where the API Gateway is hosted.

Run the below docker command to create docker file

./microgateway.bat createDockerFile -c pull-postalcode-service.yml --docker_file DockerFilePostalCode -dod

Add the below environment variables to your docker file

ENV mcgw_api_gateway_url http://<<host>>:<<port>/rest/apigateway

ENV mcgw_api_gateway_user <<API Gateway Username>>

ENV mcgw_api_gateway_password <<API Gateway Password>>

Where,

<< host>> is the IP of the system where the API gateway server is hosted.

<< port>> is the Integration server port where the API gateway is installed.

Run the below command to create a docker image

docker build -t mg-postalcodeimg -f DockerFilePostalCode .

2. Push the image to the docker repository

Tag the image created in the Step 1 and push it to docker registry.

docker tag mg-postalcodeimg <<dockerRepo>>/mg-postalcodeimg

docker push <<dockerRepo>>/mg-postalcodeimg

3. Create new namespace in Kubernetes

Below command creates new namespace in Kubernetes.

kubectl create namespace postalcode

4. Set Kubernetes context

Below command sets the Kubernetes context to the namespace created in step 3.

kubectl config set-context --current --namespace= postalcode

5. Create Helm Chart

Run the below command to create helm chart structure

helm create mg-helmchart

This will create the below folder structure

6. Replace deployment template data

Edit deployment.yaml file present under mg-helmchart/templates folder and replace with the below content.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: {{ .Release.Name }}
  labels:
    app: {{ .Release.Name }}
    category: microgateway
spec:
  replicas: {{ .Values.replicaCount }}
  selector:
    matchLabels:
      app: {{ .Release.Name }}
  template:
    metadata:
      labels:
        app: {{ .Release.Name }}
      annotations:
        prometheus.io/scrape: "{{ .Values.metrics.prometheus }}"
    spec:
      containers:
        - name: {{ .Release.Name }}
          image: "{{ .Values.image.repository }}"
          env:          
            - name: "mcgw_api_gateway_url"
              valueFrom:
                secretKeyRef:
                  key: mcgw_api_gateway_url
                  name: {{ .Release.Name }}-auth
            - name: "mcgw_api_gateway_user"
              valueFrom:
                secretKeyRef:
                  key: mcgw_api_gateway_user
                  name: {{ .Release.Name }}-auth
            - name: "mcgw_api_gateway_password"
              valueFrom:
                secretKeyRef:
                  key: mcgw_api_gateway_password
                  name: {{ .Release.Name }}-auth
          livenessProbe:
            exec:
              command:
              - /bin/sh
              - -c
              - /opt/softwareag/Microgateway/files/k8s-lifenesscheck.sh
            initialDelaySeconds: 10
            periodSeconds: 10
            timeoutSeconds: 5
            failureThreshold: 3
          readinessProbe:
            exec:
              command:
              - /bin/sh
              - -c
              - /opt/softwareag/Microgateway/files/k8s-readinesscheck.sh
            initialDelaySeconds: 10
            periodSeconds: 10
            timeoutSeconds: 5
            failureThreshold: 3
        - name: "{{ .Values.sidecarimage.name }}"
          image: "{{ .Values.sidecarimage.repository }}:{{ .Values.sidecarimage.tag }}"

7. Replace and adapt the values data

Replace the content of values.yaml file present under mg-helmchart folder with the below content for having the values substituted in the deployment file created in Step 6

# This is a YAML-formatted file.
# Declare variables to be passed into your templates.

replicaCount: 1

mcgw_api_gateway_url: http://<<SystemIP>>:32580/rest/apigateway
mcgw_api_gateway_user: Administrator
mcgw_api_gateway_password: manage

# The Microgateway Docker image
image:
  repository: <<dockerRepo>>/mg-postalcodeimg
  tag: latest
  containerPort: 9090
  pullPolicy: IfNotPresent

# The sidecar Docker image of the native service (if used, uncomment and adapt values)
sidecarimage:
  repository: <<dockerRepo>>/apiserver
  tag: latest
  name: sidecar-node
  pullPolicy: IfNotPresent

metrics:
  prometheus: true

ingress:
  enabled: false
  paths: []
  hosts: []
  tls: []

resources: {}
  # We usually recommend not to specify default resources and to leave this as a conscious # choice for the user.

nodeSelector: {}

tolerations: []

affinity: {}

8. Add the Environment Variables definition in secrets.yaml

Notice the tag secretKeyRef under env of deployment.yaml file, which is the place holder for environment variables.

In order to have environment variables substituted, create secrets.yaml under templates folder of mg-helmchart. Add the below content.

apiVersion: v1
kind: Secret
metadata:
  name: {{ .Release.Name }}-auth
data:
  mcgw_api_gateway_url: {{ .Values.mcgw_api_gateway_url | b64enc }}
  mcgw_api_gateway_user: {{ .Values.mcgw_api_gateway_user | b64enc }}
  mcgw_api_gateway_password: {{ .Values.mcgw_api_gateway_password | b64enc }}

Notice the values are coming from the {{ .Values. <<VariableName>> | b64enc }} which in turn getting from values.yaml file created in Step 7

9. Deploy the Helm Chart

Run the below command to create the deployment by making use of helm chart and configurations created in the earlier steps

helm install mg-test ./mg-helmchart

If the deployment is successful you should see 2 out of 2 containers running under mg-test deployment

10. Expose Microgateway sidecar deployment as a Kubernetes service.

Run the below command to expose the deployment created in Step 9

kubectl expose deployment mg-test --type=NodePort --port=9090

Note : Here we can also expose the deployment with type LoadBalancer and access using localhost

11. Check Microgateway service and Invoke the API using the exposed IP and port

Once the deployment is exposed as service, we can check the Microgateway server status with the below.

Here am using system IP and Node Port as I have exposed the deployment as type “NodePort”

GET http://<<SystemIP>>:32171/rest/microgateway/status

We can also invoke the API with the below endpoint.

GET http://<<SystemIP>>:32171/gateway/PostalCode/1.0/postalCodes?latitude=333&longitude=444444

Note here since the native services are not exposed by the Kubernetes configuration the Microgateway can’t be by-passed. Consumer requests are routed by the Microgateway to the native services.

From API Gateway, we can check the details of microgateway under Microgateways tab.