Handling URL Redirects in a Headless Sitecore Multisite solution running in Kubernetes using NGINX

URL Redirection is a commonly used technique for redirecting website visitors from one URL to another, typically with appropriate HTTP status code as a response. Redirects are potentially important for maintaining good SEO scores of a website. In the context of Sitecore solutions hosted in Azure WebApps, there are couple of traditional approaches to handle the redirects.

One option is to use the Sitecore Redirect Module. While this Module provides user-friendly interface to manage and configure redirect within the Sitecore CMS, it is equally important to consider its potential pain points as well. For instance, as the amount of redirect grows, it could cause considerable performance issue. Another approach involves leveraging the normal IIS redirections. Since Azure WebApps uses IIS as their underlying web server, we can utilize this feature. However as the redirection entries grow exponentially, this approach can be bit complex for maintenance and the file size limitation could be a potential bottleneck.

Both of the above approaches are obsolete for a headless application where the application traffic is served by the head ( e.g., Next.js application) because these traditional solutions rely on the server-side capabilities of the hosting environment.

What is the solution for headless architectures?

To handle the redirections in a headless architecture, a common approach is to introduce a reverse proxy server before the request reaching the rendering host. And this reverse proxy server acts as an intermediary between the client and the rendering host to capture the request and do the redirect.

The plan involves using NGINX as reverse proxy that sits infront of the rendering host application. The overall architecture can be depicted as follow:

What is NGINX?

Nginx, an open-source light weight web server that acts as a Reverse Proxy, Load Balancer. Its ability to effectively handle larger number of concurrent connections makes it particularly suitable for high-traffic websites and applications.

Some of its notable key features are,

• Web Server:- Nginx can be used as a Web Server to directly serve some static contents like HTML, Script files etc.,

• Reverse Proxy:- By functioning as a Reverse Proxy, Nginx receives client requests and forwards them to the appropriate backend services.

• Load Balancer:- Nginx possesses load balancing capabilities, enabling it to evenly distribute the traffic across multiple backend services.

In our specific case, Nginx will be employed as a reverse proxy to manage the redirections.

Nginx Specifications Structure

We have opted for Kubernetes ConfigMap as they offer efficient way to manage configurations. Addtionally, using ConfigMap – dynamic update also possible ( like updating the main Nginx configurations during Blue/Green deployment with ease).

Here is a possible example of specification setup:

Now, let us deive into the structure of the Nginx-Configmaps. We will be utilizing Config Maps to store various configurations necessary for implementing redirections with Nginx, including Nginx configuration section. Let us check each of them individually.

Redirect Rules Configmap

The redirect entries for a specifc market are stored within this config map. To accommodate the requirements, we can create as many redirect config map as needed, such as separate config maps for EU and US, to conveniently manage the redirection configurations.

Here as an example, I created a config map that holds redirects entries for EU region and included couple of redirects.

Next step involves including this redirect config into the main Nginx config map as outlined below.

Ngnix Configmap

The config map holds the main Nginx configuration, which includes the redirect rule config maps discussed earlier, can be incorporated using include directives (line no 32). To ensure readability, only the essential sections relevant to handling the redirects are provided (line no 31-52), rather than including the entire Nginx configuration.

Nginx Maps Directive

Understanding the functionality of the Nginx map directive is crucial as it plays an integral role in redirect handling.

The Nginx’s map directives are defined within the http{} block and are executed only when referenced. They are primarily utilized to generate a variable based on the value of another variable (entries loaded via the include directive in this scenario).

To illustrate this concept, imagine the complete set of values from the include directive being incorporated into the map, as shown below. The variable $request_uri represents the current URL from the client’s browser. If a match is found, the corresponding value of $new_uri is assigned, and the redirection occurs based on this value when it is only referenced ( line no 22).

The Kustomization.yaml

To simplify the deployment process using kubectl commands, we can include the specifications of these two .yaml files within the main Kustomization.yaml file using the resources field. Here’s an example of how you can structure the Kustomization.yaml file:

Nginx-Ingress Spec

The Nginx ingress controller spec is given below and it deploys the Nginx Ingress Controller in the k8s cluster. It helps to manage the incoming traffic to our Nginx service. The NginxIngress specification is illustrated below:

Nginx Service Spec

Below is the complete Nginx Service specification, including the creation of volumes and mounting for the main Nginx config and the redirect config maps:

In the above spec,

• The Service section defines the Nginx service
• The deployment section specifies the Nginx deployment, with 1 replicas
• The Nginx container is configured to use the latest version of Nginx image
• Two volumes are defined: One is for ‘nginx-config' and other is 'eu-nginx-map-redirects‘. We can include as many redirect configmaps as our need. It enables us to maintain the redirects for different markets with ease in the multi site environment
• The nginx-config volume is mounted at /etc/nginx/nginx.conf and reads the nginx-configmap ConfigMap
• The eu-nginx-map-redirect volume is mounted at /etc/nginx/eu-nginx-map-redirects.map and reads eu-nginx-map-redirects ConfigMap

Deployment

Now we have all the necessary config maps for the Nginx to handle the redirects and the following kubectl commands can be used to deploy it.

Conclusion

In summary, NGINX makes it easy to handle the redirections in the headless architecture and it offers robusts set of features. Its performance, maintainability and wide configuration options makes it to be a popular choice for managing redirects in the modern web application.