This repository includes a set of sample APIs and API-Gateway policy configurations, just as would be set up for customers if they wanted to automate control of the Axway API-Management platform based on DevOps pipelines, which is of course Axway's clear recommendation.
The following use cases/requirements are illustrated:
- API Design
- APIs as Code
- API Mockup with API-Builder
- API integration with API-Builder
- API Gateway Configuration
- API Gateway Updates
The DevOps pipelines run on top of GitHub actions, but are also implementable with any other technology such as Jenkins or Azure pipelines, as only standard tools such as the APIM CLI, kubectl, etc. are used. Some of the use cases, like API builder or API gateway updates, require the API management solution to run in a Kubernetes cluster.
This repository represents an example structure of how one might store the resources needed for the Axway API Management Platform in a version control system. It is primarily about individual APIs, the API gateway configuration incl. policies and settings. This GitHub repository uses GitHub Actions as the CI/CD platform, but can be modified accordingly to, for example, Jenkins.
Folder | Comment |
---|---|
.github | Contains GitHub-Action CI/CD workflows |
api-emr-catalog | Simple example API – Based on existing API-Specification |
api-emr-diagnostic | API that is automatically tested after each deployment using newman. |
gateway-config | API-Gateway configuration assets used to build API-Gateway Docker-Images |
helm | HELM-Examples to deploy solution on AWS or GKE |
lib | Contains postman environment variables to be used by Postman test suite |
setup | Test-Data to setup a new platform with APIs, Apps, Organizations, ... |
The steps listed here are necessary for the API service provider if they want to use all or some of the use cases. For example, if you want to register or modify APIs or change policies.
The following requirements
- Windows or Linux environment (Learn more System requirements)
- Git client for instance GitHub Desktop
- GitHub account
- Axway Policy Studio installed (Learn more Install Policy Studio)
- npm and Nodes.js installed (Learn more API Builder Getting Started Guide)
- axway cli
- apim-cli installed
- Access to npm repositories
- You may try to create an API-Builder project with
axway builder init my-project
, which will try to download required packages
- You may try to create an API-Builder project with
- an API-Design Tool for instance Stoplight
As a first step, the API service provider must check out the repository. The following example:
git clone https://github.com/Axway-API-Management-Plus/axway-api-management-automated.git
Then, the API service provider opens the checked-out repository in its desired development tool, such as Visual Studio Code.
This repository represents how the Axway API management platform can be fully automated based on version management and DevOps pipelines. This includes a number of use cases that are presented here.
The API as Code approach means that instead of manually configuring their APIs in the system, they define them in the version management system of their choice and register and keep them in sync through a DevOps pipeline in the API management platform.
Watch this video to see an illustration how to register an API base on version control:
Another apporach is to use the API-Manager Web-UI, configure an API and then use the APIM-CLI to export the configuration:
This use case is about creating a completely new API based on an API-first approach. To do this, you use an API design editor of your choice, design the first version of your API and then register it in the API management platform.
After you have designed an API, it is a convenient way of the API builder to quickly and easily mock APIs, separating the process between API service and API consumption.
Before using the API-Builder this video explains how to install and create a first API-Builder project:
And the following video is now using API-Builder to Mock an API:
Of course, the real strength of the API Builder is not mocking APIs, but various integration scenarios, customizing and optimizing APIs.
The API gateways are controlled by policies, which are configured in Policy Studio and then deployed to the API gateways completely automatically through the DevOps pipelines set up here without any downtime.
To update API Gateway policies, the Policy Studio project is pipelined into an FED file, which is downloaded through an Init container and thus made available to the API Gateway.
The following video demonstrates the process:
This video explains how to configure and use Mutual-SSL with Axway's API Management solution based on an AWS EKS.
This video explains how the internal OAuth service works in the Axway API Management solution and provides a brief overview of the capabilities.
You are welcome to fork this repository and customize it according to your own needs. In the default setup with a Kubernetes cluster (EKS) on AWS and using GitPackages as the repository, the following GitHub secretes are required and must be created accordingly in your fork.
Secret/Variable | Description |
---|---|
APIGATEWAY_LICENSE | The Axway API-Gateway License Base64 encode |
APIM_HOST | The host of the API-Manager used by the APIM-CLI |
APIM_PORT | The port of the API-Manager used by the APIM-CLI |
APIM_USER | System Account for the API-Manager System Account used by the APIM-CLI |
APIM_PASS | Password for the API-Manager System Account used by the APIM-CLI |
AWS_ACCESS_KEY_ID | Used to authenticate at AWS in oder to control the K8S-Cluster running at AWS-EKS |
AWS_SECRET_ACCESS_KEY | Used to authenticate at AWS in oder to control the K8S-Cluster running at AWS-EKS |
KUBE_CONFIG_DATA | The Base64 encoded Kubectl configuration. cat $HOME/.kube/config |
BASE_IMAGE | The Base Image to pull e.g. ghcr.io/cwiechmann/axway-api-management-automated/base:77-20220530-1 |
DOCKER_REGISTRY | The Docker Registry to push the build Images e.g. ghcr.io |
DOCKER_REPO | The Docker Repository to push the build Images e.g. mpentzek/ay-api-management-automated |
AWS_REGION | The AWS Region e.g. eu-west-1 |
EKS_CLUSTER_NAME | The Name of the EKS Cluster |