A valuable update to our boilerplate

This blog post is part of a series about building a production ready Continuous Integration setup for Sitecore using K8s containers on AKS. For more information and other articles on this subject check out the series index.

As you might have read in my previous blog post, we are aiming to automate the entire provisioning process of a Sitecore K8s deployment to AKS as far as possible. The initialization pipeline is an important part of that process, but it still contained a few rather tedious manual tasks: configuring the Redis connection string in the AKV secret after its provisioning, and configuring the network access for the AKS cluster to both the Solr Cloud and the SQL instances.

Allow AKS access to EDS

In my blog post about provisioning the External Data Services (EDS) I described what needs to be done to allow AKS to access the External Data Services on a networking level. I showed the manual tasks to perform in the Azure portal to accomplish this. Within the entire provisioning process, this is done at step 18, which is part of the initial provisioning DevOps pipeline.

The networking configuration needed for Solr and SQL cannot be included in the ARM script because it needs to communicate with the node resource group created by the AKS deployment. Hence, my colleague Erik Jeroense and I have developed a PowerShell script that performs this configuration fully automatic. That script is now also part of my PaaS to AKS boilerplate.

This allow-aks-access-to-eds.ps1 script contains two functions for each EDS to configure:

The heart of the Solr configuration being to add a network security rule configuration for the IP address of the RG of the AKS node cluster:

And the access to SQL is set by adding an Virtual Network rule:

The script also performs a check if the desired rule doesn’t exist yet, so it can update instead of add the rule configuration. This allows for running the script multiple times safely, just like the ARM templates, creating a state configuration rather than a repeated creation.

Note that this script uses Azure PowerShell commands. If you do not yet have that module, you can download and install from here.

Update Redis AKV secret

As mentioned here, the Redis connection string is currently hard-coded in the K8s spec file of the CD Role. I have filed a Pull Request and sent the change request to Sitecore so hopefully in newer versions this manual adjustment to the spec files is no longer needed. Still though, you need to store the connection string of your Redis Cache instance into the appropriate secret.

The Redis connection string cannot be configured or determined before its provisioning, because it contains the randomly generated primary key of the Redis instance. The script needed for this is a bit simpler than the previous one: retrieve the Primary Key from the Redis Cache instance, form a connection string based on that key and the Redis Cache name, and store this connection string in the corresponding Azure Key Vault secret.

So in essence, this is what update-redis-akv-secret.ps1 is doing:

Check out my PaaS to AKS repository for the full script and all the accompanying templates.

The YAML initialization pipeline

We now have all the ingredients to fully automate our initial provisioning, which concerns step 17 to 24 from our provisioning and deployment overview. I will not go over each step again, as I have already explained what you need to do in which order, and because the pipeline uses all of the earlier developed scripts and ARM templates. If you did not catch up with the earlier articles of this series, check out the Init pipeline chapter of my PaaS to AKS overview blog post for an explanation of all the steps in this pipeline.

My colleague Erik Jeroense has transformed all of the required steps into Azure DevOps tasks in the form of a YAML pipeline. You can find the source code on my PaaS-to-AKS repository on GitHub: https://github.com/robhabraken/paas-to-aks/blob/main/azure/pipelines/init-pipeline.yaml.

We want our pipeline to be re-usable and thus configurable. So, additional to the KeyVault secrets mentioned earlier, this pipeline requires configuration through a number of DevOps variables, pointing towards the correct paths in your repository and resources names in Azure:

This rounds up the vanilla installation of Sitecore 10 on AKS using the K8s specification files as provided by Sitecore. With the boilerplate we’ve created you can easily set up a production ready Sitecore XP installation using Azure PaaS resources for your External Data Services! Everything is automated as far as possible and scripted in a way that facilitates re-use. In the next blog posts we will look into (re)deploying your custom Sitecore implementation and topics like scaling and monitoring to keep your Kubernetes Sitecore deployment healthy and up-to-date.