Deployment Best Practices for WSO2 API Manager

WSO2 API Manager is a fully open-source full lifecycle API Management solution that can be run anywhere.

This article will cover the basics best practices that you should follow when deploying WSO2 API Manager on VMs or containerized environments for a production level use cases.

Introduction on Deployment Patterns

WSO2 API Manager distribution consists of 5 profiles.

1. Gateway
2. Key manager
3. Traffic manager
4. Dev portal
5. Publisher

We can either use all in one distribution or this profile modes to create the deployment.

Based on this, there are recommended pre-defined 5 deployment patterns to cater to different requirements.

Pattern 1 — Single Node (all-in-one) Deployment

Pattern 1 Deployment

This pattern consists of two all in one node to the server the API traffic. This is the basics HA deployment pattern you can use if you are working with low throughput.

Pattern 2 — Deployment with a separate Gateway and Key Manager

Pattern 2 Deployment

Pattern 2 deployment contains 2 gateway profiles to server gateway traffic and 2 key manager profiles to handle the key manager calls. This is ideal if you are working with high throughput with a high key manager workload. For example a scenario with low token life span.

Pattern 3 — Fully Distributed Setup

Pattern 3 Deployment

As you can see, pattern 3 has been broken down to profiles mode to handle major functionalities such as gateway calls, key manager functionalities and traffic management. This pattern provides flexibility and scalability in each layer.

Pattern 4 Internal and external (on-premise) API Management

Pattern 4 Deployment

Pattern 4 consists of two HA gateway deployment. This useful it is required to handle and manage for external and internal API traffic.

Pattern 5 — Internal and external (public and private cloud) API Management

Pattern 5 Deployment

Pattern 5 can be used to maintain a cloud deployment as an external API gateway layer.

Best Practices

VM Mode

1. Content Synchronization

Content synchronizing is maintaining the artefacts among multiple servers at the same level such that no server/node would consume artefacts in different levels.

With respect to WSO2, you need to synchronize API related artefacts resides in <APIM_HOME>/repository/deployment/server among available gateway nodes.

Similarly, you need to synchronize the traffic manager related artefacts in <APIM_HOME>/repository/deployment/server/ among traffic manager nodes.

The recommended way to do this is to use a “shared file system” such as NFS.

Note: As an alternative, you can use r-sync. Since r-sync happens only one-way, this can cause a single point of failure. Hence the best way is to use a shared file system.

Container Mode — Docker/Kubernetes/Openshift

1.Content synchronization

Similar to the above description in VM mode, you have to use a shared file system to content synchronization in container mode too. Please refer VM mode section for more info.

2.Maintaining image in a private docker repository

WSO2 API Manager image is available in Dockerhub. You can use the following command to pull that image.

docker pull wso2/wso2am:latest

Once you pull the image, you can use this as a base image and include relevant customization such as jars/ themes and burn a new image and push it to your own private registry.

3. Use volume mounts for solr directory and h2 databases

Solr directory(<APIM_Home>/solr) contains the frequently used API metadata to make API search faster in API store and API publisher.

H2 are used to keep node-specific details and etc.

This data needs to be persisted. Hence for these, we have to use volume mounts in containerized environments.

4. Key store and trust store

If you are using the functionalities where you will be adding certificates to the client trust store dynamically, then you can use a volume mount

But if you do not want to add certificates dynamically to the client trust store, then you can use k8s secrets/config maps or similar volume mount for these according to the availability of your containerized environment.

OR you can burn the key stores and trust store files to the image itself according to 1st point if you do not wish to add certificates dynamically.

There are the basics best practices which are common to any deployment pattern of WSO2 API Manager. Hope this article was helpful for you.

Please join with WSO2 API Manager slack channel for more details.