Gateway API

API Gateways

The Scigateway will need to get plugins and API requests from several locations, to avoid the CORS problem we need to use an API gateway

The Problem

The Scigateway application will route requests from the main application page to plugin UI elements and the plugin backend services, all of which may be hosted in different networks.

Kong

Kong is one potential open-source solution to this issue, providing a configurable API gateway.

Notes on configuration

• Kong requires a database backend which can be Cassandra or PostgreSQL.
• Documentation is quite clear on how the proxy should be configured: https://docs.konghq.com/1.0.x/proxy/, however configuration is NON TRIVIAL and made via REST API calls.
• Konga is third-party UI that has been developed for Kong configuration

Deployment

• A docker-compose configuration is available that starts both Kong and Postgres containers: https://github.com/Kong/docker-kong/tree/master/compose. This is NOT a production solution but useful for configuration testing
• Docker images for Kong are available as a more production ready solution via https://github.com/docker-library/docs/tree/master/kong
• Kong is also available to be deployed as a Kubernetes ingress controller. This would be a viable production solution if there is a Kubernetes instance available: https://github.com/Kong/kubernetes-ingress-controller

Developer Testing using the docker-compose image

Download the docker compose file from GitHub and start it with

  docker-compose up

This creates a running instance of Kong (admin on localhost:8001) which persists configuration between sessions. For safety, all configuration should be scripted so it can be managed and updated if the docker images are replaced.

Services are added, updated and removed through a straightforward REST API.

Configuration is via application/json or formated inline application/x-www-form-urlencoded and works as expected.

Basic configuration

1. Create the service pointing at the machine HOSTING the backend, host here can be a dns name or IP address

        $ curl -i -X POST http://localhost:8001/services -d 'name=plugin1-service' -d 'port=5001' -d 'host=<remote host IP>'

2. Create a route mapping to the service.id returned by the create service call. The paths[] block defines which routes to match, strip_path ensures the call is passed to <target>:<port>/tasks/<other stuff> not simply <target>:<port>/<other stuff>

        $ curl -i -X POST http://localhost:8001/routes/ -d 'paths[]=/tasks' -d 'service.id=0421e967-7816-4859-ab6d-832bfc84f2c4' -d 'strip_path=false'

Notes

• For the initial development an API Gateway has not been configured