Sitecore Docker/Kubernetes best practices
Hello,
The way we host our Sitecore infrastructure is rapidly changing.
I remember the days when we hosted Sitecore instances on virtual machines and connected to them through RDP.
Then the Azure PaaS came, and we started to host Sitecore as a webapp.
And now we have Docker with Kubernetes came to our life with virtualization.
In this guide I’d like to cover the ways how you can make your Kubernetes/Docker setup easier to manage/debug in your solution.
And yes, probably in another 1–2 years even this guide would be outdated as we can see the Sitecore SaaS offerings coming with JAMStack and Experience Edge.
So let’s go!
Use Lens to connect to your cluster
If you are hosting your website in Kubernetes installing Lens would probably the first thing you’d like to do.
It would allow you to easily
- See the container logs in the environments
- Connect to containers with command line
- Delete the containers and see their health status
Literally time saver.
Preheat your Sitecore instances on initialize, configure healthchecks
Remember that your containers would be served as soon as their healthcheck would be passed.
By default your website healthcheck is making a web request to http://localhost/sitecore url.
You could extend that for example by adding your website url as well (keep in mind though that there is no dns inside docker container, so you’ll need to map it to localhost).
You could also configure pre-fetch cache here as described in Sitecore doc.
This would allow the website to pre-load the cache and make first request much faster.
Analyse your logs in the cloud
As Sitecore is hosted in Docker container now it becomes harder to analyse and browse the logs in the actual environment.
Yes, you can use Lens to connect and view the specific container, but with multiple CDs (each of which has its own file system) the process to browse the logs becomes too complicated.
How to fix this?
By using cloud-log collection providers, such as for example DataDog, or NewRelic.
This might mean some changes to the way how you write logs, as now you’ll need to write them in JSON format to allow easier processing.
Here is an example of great overview on this topic from Velir:
Collect Telemetry
Using telemetry providers, such as NewRelic or others (like AppInsights) is getting more important now as it’s harder to collect metric from Kubernetes.
Installation depends on the telemtetry provider, but usually is limited to few lines of code in Docker bootstrap file.
And in the end what you get is a comfortable way to browse the exceptions and long-running requests that happen on your side.
Useful command-line tools to install on your Docker images
By default your Docker instances would allow you to connect to them with command line.
What if you want to test change in config file on DEV env?
You can use VIM (or even better Neovim!) for that by adding this two lines into your Docker boostrap file:
And on top of that you can also configure Vim with extensions, such as file manager, color highlighting, search and more which would be very handy in your future debugging on actual environment.
Remember — editing in your container is NOT recommended way to write code, and instead the right approach should always be to try to reproduce it locally and fix it there. But if the issue is environment specific sometimes it could be a better way to debug than to make full deployment (which sometimes could take up to 30mins or more).
Did I missed anything?
Feel free to add your advice on tools that are must-have for Sitecore Kubernetes/Docker setup in the comments.
Have a nice day!
