The ability to monitor your Sitecore instances is essential. Knowing your application is available and performing in production as expected is critical. To be proactive and respond to changes in performance as opposed to reactive after an incident has occurred, you need a continuous overview of the state of the application and the underlying infrastructure. This involves gathering metrics like CPU, memory usage, and storage consumption as well as any application-related metrics. However, when monitoring a containerized Sitecore instance we cannot apply our usual methods and tools to provide us with all the data we need. In this post, I will show you some of the native tools to help you monitor Sitecore containers.
The docker stats command display a live stream (updated every second) of running containers resource usage statistics docker stats:
- CPU % – the percentage of the host’s CPU the container is using.
- PRIV WORKING SET – refers to the total physical memory (RAM) used by the process.
- NET I/O – the amount of data the container has sent and received over its network interface.
- BLOCK I/O – the amount of data the container has read to and written from block devices on the host.
In this post, I will show you some useful commands and tips for managing your Sitecore containers, images and other docker resources that get created when standing up your containers. The Docker documentation is awesome but it is fairly extensive so I’ll cover some useful commands you should be familiar with.
PS> docker container ls – lists running containers by default, you need to use -a flag to list all containers not just running containers. You can use -f flag to filter containers.
PS> docker container ls -f “name=93x*”
If you want to see the most recently created use -l flag.
If you have built your Sitecore container images and they reside locally and you want to share them with your team the recommended approach is a private registry and there are a few services available. However, Azure Container Registry (ACR) allows you to store docker images in repositories and can take advantage of the azure pipelines to automatically rebuild these images when they need to be updated. In this post, I will show you how to push your local images to a private ACR. This also works if you need to move your images from one private registry to another.
If you are running Sitecore in a container then you’ve most likely switched Docker desktop to Windows container mode. But what if you want to run a Linux container simultaneously? For example, you might want to fire up, JMeter and Grafana on Linux containers. It turns out this is possible in your local development environment and is fairly straightforward.
Don’t worry this is not another post about running Sitecore in a container! No this is a post about getting the Sitecore HabitatHome demo solution up and running quickly and I mean quickly without too much effort. I just happen to use docker in the process. HabitatHome is a solution built using SXA on Sitecore XP following Helix principles. It is extremely useful if you need to showcase SXA capabilities to an existing or a potential new customer.
This is where my good friend Andy Uzick found himself a few weeks ago but had already started down the path of standing up the SXA HabitatHome demo on a temporary Azure PAAS instance not using docker. I thought with docker surely this would be much easier.
Okay, so we all know the difference between Renderings and Final Renderings right? Final renderings were introduced in Sitecore 8 to make it possible to have different layouts for the various language and versions of an Item. Awesome!!
- __Renderings – a shared field where you specify the common layout for all languages and versions of the item.
- __Final Renderings – a versioned field where you specify individual layouts for languages and versions of the item.
I ran into an issue where I needed to modify the __Final Renderings for specific templates. A parameter of a component for a specific language in use on a site, needed to be updated. Continue reading
Okay, so we all love and appreciate something that has been packaged up nicely. There are some really useful features built into Sitecore package designer that can make a huge difference in the packages we create and even save us time.
Saving & Opening Existing Packages
If you have spent time creating a package you should save it so that if you need to modify it later, you can. After you have generated and installed the package but discover you have forgotten to include something rather than go through the pain of creating a new package you can simply open the existing package. Opening a package allows you to modify the items contained in the package or add new items. This is a no-brainer. Continue reading