This post details how the Delivery Platform registers endpoints in the Central API Gateway. It is recommended to read Handling the SDLC for Databricks Notebooks and Workflows and Delivery Platform and Automatic Creation of API Endpoints posts so that you can get a better understanding of the context of API Endpoints.
Delivery Platform & API Endpoints
We will follow the usual structure:
- Background – API Endpoints
Background – API Endpoints and Pipelines
As we explained in related posts, Central API relies on endpoints exposed to the public through an API Gateway. We have chosen Kong as API Gateway technology and we decided to integrate the publish procedure in our delivery pipelines so that we can have E2E access right after completing the deployment.
The main challenge was to define the naming conventions, the URL patterns and the progression through delivery stages so that there is consistency when it comes to:
- Exposing a canonic URL per endpoint/environment so the automated test run accordingly with the proper results.
- Addressing the endpoint upstream URL so it can be accessed from Kong to the endpoint prototype deployment.
- Create a set of Jenkins pipelines to run Kong registration at the appropriate moment (typically the end of the stage).
- Create a set of Jenkins templates to reuse Kong registration for other components that may need it.
Kong consists of two APIs, the first one is the actual API Gateway where all the endpoints will be served from and the second one is the Administration API that allows us to manipulate services and routes.
The following code is the pipeline code to trigger our CI build stage for an endpoint. When the pipeline succeeds, the API publishing process is started. API publishing consists of two combined steps, the first one is Apiary publish process (refer to the following post of my colleague Daniel where it is well explained The Merge Swag!) and the second one is Kong publish.
As soon as the Apiary part is completed, Kong publish is triggered. Here is part of the Jenkins Pipeline that handles this process:
As we can see, there is a method from the groovy class KongManager called ‘register’ that actually runs the register process. Let’s take a detailed view:
Register in kong process requires the registration of a service in kong admin API and after that, the registration of a route associated to the service Id already created. As we can see, Jenkins pipeline handles the whole process in a templated way so we can add different endpoints with different upstream URLs, paths and protocols.
The following JSON is the response to the Kong Admin URL: https://kong-host/services/
And the next JSON is the routes response (https://kong-host/routes/)
This post describes the integration of Kong API Gateway in FTS Computing Platform Delivery Platform pipelines. This is not a complex thing to do from the technical perspective but the whole integration in the pipelines in a seamless way it’s really powerful removing a lot of manual intervention from the actual delivery flow.