This article focus on some of the best practices while running Datapower (DP) Gateway in cloud native world (containers) vs. in traditional deployments. Assumptions
The content of this article are in context of Cloud Pak for Integration 2020.2.1 or later environment where IBM Datapower Gateway can be deployed as Operator.1. IBM Deployment Gateway deployment considerations - When to use what?
IBM Datapower Gateway Operator is installed as part of the IBM API Connect Operator (as the gateway subsystem) or can be directly installed from the Operator Hub in the Redhat Openshift cluster.
2. Approach for Persistence for DP in containers
- When you create API connect cluster instance inside API Connect Operator, API Gateway or Datapower Gateway subsystem is automatically deployed as Gateway subsystem or API Gateway. API gateway should be used when APIs need some specific Multi Protocol Gateways or port opening to run, that is tied directly to the APIs lifecycle. And hence all Datapower-specific configuration should be sent from the API Management subsystem as gateway extensions.
- If its a bunch of Multi Protocol Gateways/Web Services Provider (non-apic related) and/or that can be called as a back-end from APIs then its recommended to deploy it on another datapower instance and not API gateway.
The gateway configuration is not persisted and not supposed to be (by design). You shouldn’t need to persist anything and you should not change any config directly into a running gateway instance.
Persistence with API Gateway (Deployment type 1a above)
For API gateway, all configuration should be sent from the Management subsystem to the gateway as gateway extensions
. API manager will be in charge of deploying them into the gateway without need of Datapower gateway manual configuration. If you need to create some objects or configuration, you can do it in a running datapower (physical or k8s) then export the CFG file for that configuration, set and create a Gateway Extension in APIC with it. Persistence with Standalone Gateway (Deployment type 1b above)
For standalone deployment of Datapower gateway (non-apic deployment) you could persist datapower configuration by creating storage and mount /drouter/config and /drouter/local dirs on a PVC as explained here.
However the suggested/preferred way is to not persist the configuration in mounted storage and pass it via ConfigMaps and Secrets that will get deployed on container. This is because datapower is typically stateless, business data is not stored but only configurations and in k8s the best way is to use Secrets + ConfigMaps for certificates and configurations respectively. This is a more cloud-native way of working and also by doing that you can tie it to a CI/CD pipeline as well (explained in later section).3. Handling Configuration and Certificates with DP in containers
explains how to define the DP configuration in Config Maps and Certificates as Secrets in k8s environment.
- You can provide one or more Datapower CFG files as ConfigMaps to configure one or more Datapower domains.
- Certificates can be configured by using Secrets.
- Additional files to be stored in datapower's folders can be provided by creating ConfigMaps as well.
Here is an example of creating the ConfigMaps, Secrets for each of the above 3 categories:
Once you create the ConfigMaps and Secrets in the k8s environment you can point the DP instance to the same as shown below or via CI/CD:
4. CI/CD approach for Datapower Gateway in containers
is an example of setting up CI/CD with Tekton pipeline for DP in containers with DP configuration defined as ConfigMaps and Secrets. Examples are available in dp folder in the same git repo.
In this article we've covered the deployment considerations for Datapower Gateway in containers, persistence approach for DP configuration in containers and Setup DevOps for DP in containers.#Containers#DataPower#gateway