Sitecore 10 was launched, and it was great to see that Docker, Kubernetes and other technologies enable the Sitecore Deployment on Docker Containers and Kubernetes.
Table of Contents
Preparing the default setup and cloud integration with the respective deployment/release pipelines is the most challenging part of onboarding a new customer to the Sitecore Experience Platform (XP).
Configuration can be complicated even if you have a template to replicate. You’ll need to onboard new developers and have them spend time setting up the solution locally. This can impact delivery timelines.
Sitecore XP can be deployed in a Docker container to help sync the process. This ensures that everyone knows how the release will work in a production environment, starting with the development phase.
Blue-green deployments can be easily implemented if you have a strategy around content items that is consistent with the new Sitecore setting.
Testing Sitecore in Docker Containers or Kubernetes
Here are some tips and tricks based on the experience of testing Sitecore in Docker Containers or Kubernetes.
- All versions were working ok when deployed in Docker containers locally(development environment), in XP0 , XP1and XM1. Earlier versions of Sitecore when using SIF scripts (using scwdp) caused the newer version to initially not work because a parameter wasn’t updated. If you deploy using containers, this issue will not occur.
- Overall, deployment to AKS (Azure Kubernetes Service) was. Successful.When adding the Helm repo to the latest stable charts, use: the helm repo to add stable. Wait until external and init finish running the Kubectl Apply. Sitecore roles need to be healthy. They’ll eventually be promoted to more unhealthy roles if they aren’t.
- You can verify that you are using the latest version of kubectl to match your server version by running kubectlversion -client. Docker Desktop includes the Kubernetes CLI tool. You can find out more about Docker Desktop. Use the SecretGenerator to help.
- Keep in mind that if you have a Kubernetes server running in Azure Kubernetes Service (AKS), the version is newer than 1.17.x, then the command to open the Kubernetes dashboard will not work. AKS has removed this add-on in favour of resource preview sections, for which you can use the Kubernetes portal.
This will only work if you have a Windows node. The NGINX ingress controller will deploy on the primary (default) Linux node.
According to the documentation, external services like SQL Server/Databases and Solr/SolrCloud must be deployed in AKS using the PaaS offerings of Azure. These include SQL Elastic Pools and Azure Cache for Redis. You can also use SearchStax for SolrCloud.
Images from the Sitecore registry include the name nonproduction in their path. It cannot be used in a production environment. It’s only used for testing.
You can customize your Kubernetes components using the well-known Minikube tool.
What tools should you use to get the job done?
Here are four tools that you must use when handling containers.
- Visual Studio Code: Docker extension
- Visual Studio Code: Kubernetes extension
- Docker Desktop
- Set up Hyper-V on Windows 10
The Docker extension shows running and non-running containers. The container logs files can also be inspected to help you read the log stream.
You can also go directly to docker\data\cm. The default instance provided only maps to CD and CM for logs. You will need to set the mapping to allow you to view log files from other roles.
It would help if you stopped IIS when running Docker containers. This will allow Traefik to control listening on ports 80 & 443.
If the roles in question are not healthy, Traefik will show an error. Inspect the logs for errors, such as a misconfigured URL connection string (URL). Sitecore roles often use the /healthy/live or /healthy/ready functions to determine the container’s health.
Sitecore containers are a great way to improve Sitecore Deployment on Docker Containers and Kubernetes and implementations.
As with all Sitecore customizations, however, it will take a lot of time to train and test developers to make such changes. They need to be able to understand the workings of Kubernetes and Docker. You’ll have a blueprint for a new client/implementation when an understanding is established.