Working with Sitecore 10 Docker Containers and Kubernetes

The most common challenge when onboarding a new customer on the Sitecore Experience Platform (XP) is the preparation of the vanilla set-up and cloud integration with its respective deployment/release pipelines.

Even if you have a template or blueprint process, configuration can be a challenge, as you’ll have the onboarding of new developers spending time setting up the solution locally, as well as member rotation if it’s a dynamic team. This will affect delivery.

Deploying Sitecore XP in Docker containers helps sync the process. It ensures everyone understands how the release is going to work in a production environment starting from the development phase, so there’s almost no difference between environments.

You can also easily implement blue-green deployments if the strategy around content items is correct when introducing breaking changes or features closely coupled with a new Sitecore 10 setting.

Below are some pointers of what I encountered during the process of testing Sitecore in Docker Containers and Kubernetes:

• All provided versions worked on deploying Docker containers locally (development environment) in XP0, XP1 and XM1. From experience, previous versions of Sitecore when using SIF scripts (using scwdp) caused the newer version to initially not work because a parameter wasn't updated. This issue won’t arise if you deploy using containers.

• Deploying to AKS (Azure Kubernetes Service) was overall successful. When adding the Helm repo the latest stable charts, use: helm repo to add stable.  Follow the documentation and wait until external and init completes running the kubectl apply. This is important as the Sitecore roles must be healthy. If they’re not, they'll cascade to unhealthy roles.

• Check you have the most recent version that matches your server version when using the kubectl by running kubectl version -client. Docker Desktop comes with the Kubernetes CLI tool. If you haven’t installed one look at the “About Docker Desktop”. I experienced an issue of having multiple versions of the kubectl, and one of them was a pre 1.14 version. To help, use the SecretGenerator. 

• Bear in mind that if your Kubernetes server is going to be hosted in Azure Kubernetes Service (AKS) and you use a version newer than 1.17.x, the command to open the Kubernetes dashboard won’t work because in newer versions of AKS, this add-on has been removed in favour of the resource preview sections for which you can use a Kubernetes portal.

For this to work you need to provision a Windows node. If you don't, the NGINX ingress controller deploys on the primary (default) Linux node available.

The documentation mentions that for the real production deployment in AKS, the external services such as SQL Server/Databases (mssql), Solr/SolrCloud (solr) and Redis (redis) must use the PaaS offerings from Azure such as, SQL Elastic Pools, Azure Cache for Redis, and if required, SearchStax, for your SolrCloud.

The images from the official Sitecore registry even contain the name nonproduction in the path. This categorically states it must not be used for the production environment. It is only for testing purposes.

If you need to customise your Kubernetes components, you can use the well-known minikube tool.

I highly recommend you watch a series of videos from Master Sitecore related to:

Which tools should you use?

Below are four essential tools you should use when working with containers:

• Visual Studio Code: Docker extension

• Visual Studio Code: Kubernetes extension

• Docker Desktop

• Enable Hyper-V on your Windows 10 machine

The Docker extension displays running and non-running containers. To help read the logs stream, the container logs files can be inspected.

You can also navigate directly to the docker\data\cm. Please note that the provided vanilla instance only maps to CD, and CM for the logs. If you want to see logs files of other roles you need to configure the mapping accordingly.

When running the Docker containers be sure you stop the IIS service, so Traefik can take ownership of listening on ports 80 and 443.

Traefik will display an error if the related roles are unhealthy. Again, inspect the logs to see any errors like a misconfigured connection string (URL). Many of the Sitecore roles make use of the /healthz/live and /healthz/ready to check for the container health status.

To conclude, adopting Sitecore containers improves Sitecore implementations and deployments.

However, as with anything in Sitecore, any customisation outside the provided vanilla instance will require a lot of effort in testing and training developers to implement such changes, as they need to fully understand how Docker and Kubernetes work. When an understanding is established, you’ll have a blueprint for a new client/implementation.

Working with Codehouse

As Sitecore experts we specialise in developing Sitecore websites from the ground up, onboards and upgrades. If you're considering Sitecore as your preferred your solution then get in touch.