Kong Adventures — Running Sitecore behind Kong Gateway

Since Sitecore JSS it is possible to completely decouple the frontend application and the backend services. Sitecore is only exposing the required API endpoints for the Layout-, Dictionary- and GraphQl services:
(Although this has always been possible using the Item service, personalization was not a part of this).

The Layoutservice is used for the page structure, defining the layout and required components, including the data. Dictionary service is offering labels for Forms, Buttons, Tooltips, etc. The GraphQL service is used to get additional data for the page.

For being a Multi-site Content Management System, Sitecore is usually hosting sites for multiple brands. Additionally, brands are offering multiple applications resulting in a huge amount of APIs exposed through the Sitecore CD server. Managing and monitoring all these endpoints is quite a challenge.

There is also a huge risk indirectly linking applications to the Content Management System. The Sitecore CD server is not capable of adding request restrictions, request inspections, etc. It’s just offering the APIs and it’s up to the client to consume it.

Adding Control

A Gateway or Proxy must be added between the front-end application and the Sitecore CD instances to gain more control in this setup. By adding a Gateway, it is possible to restrict access to the Sitecore CD service which is only accessible by the Gateway:

Using this setup, we’ve gained control and improved security!

Running this set up in Azure, there are a couple of options for the Gateway:

1. Application Gateway
2. Azure API Management (APIM)

These are both excellent resources and offer a huge amount of possibilities. However, everything comes at a price. When using the Gateway only for the scenario above, the Azure Application is way overkill. Besides the complexity of the Gateway, lots of these build-in options will not be used.

APIM might be a better approach and will be the best setup in most cases and can be used at an affordable price. The downside of the APIM is the limitation in the number of hostnames that can be linked to the APIM. If you want to attach more than a single hostname, you can pay over 2k a month!

For just running an API Gateway, these resources might be too heavy. Thankfully, we’re not limited to the available resources in Azure only. Lots of other options are out there. One of these options is KONG API Gateway.

KONG API Gateway

Kong API gateway comes in 2 versions, an OSS version and a version that is part of the Kong Konnect Platform. We’re using the OSS variant because this has lots of options that suit our scenario perfectly.

Kong itself can run in 2 ways:

1. Using a database (PostgreSQL), iterative setup. Adding items to the Gateway is done by POST-ing data to the admin API.
2. DBLess mode, declarative setup. Adding items is done once by using a configuration file that contains all required data.

The most pragmatic method is the DBLess mode. It’s just a matter of configuration and the Gateway is running.

Setting up KONG

It is possible to run Kong in a Docker container which is perfect! This way, we only need to add the configuration file to make it work.

Because Kong is running in a Container, it is possible to use Azure Container Instances. If you need a more web-oriented setup (hostnames for example), WebApps for Containers is the best way.

To add the configuration to the Kong Container, a volume must be created to host the configuration file. In Azure this can be done by setting up a path mapping in the Webapp for Container to load the files (in the share) as a shared volume in the container itself:

As you can see, a new path mapping is created which is linked to an Azure File Share which hosts the Kong configuration file.

Now the path mapping is created, we need to tell the Container to use this ‘volume’ which is done by using the name of the path mapping in the volume:

All files in the kongshare are loaded in ‘/usr/local/kong/declarative’ and can be used in the Kong Container. We only need to tell the Container which file must be used. This is done by using an Environment Variable. Of course, this can be set in the compose file but to make it more dynamic, let’s define this variable as an Application Setting in the WebApp Configuration:

And that’s all there is to run Kong in Azure by using Containers, Azure File share, and a Path Mapping.

In the next article, I’ll take a deep dive into managing and using the configuration file, how to deploy the updates, etc.