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
The JMeter GUI is great for creating and debugging test plans, however, as I have mentioned in a previous post it is not recommended for running your actual test plan. JMeter is simply not designed to produce high loads in GUI mode, as it can consume a lot of resources and potential produce unreliable load test results. While it is recommended you run your actual test in CLI mode, this means you have to wait until the test is complete before you can see the results. While this might be okay for short tests but for longer running soak tests you might want to examine the results while the test is running. In this post, I will show you how this can be achieved using InfluxDB and Grafana.
InfluxDB is a time-series database built for high-performance handling of time-stamped data. JMeter provides a backend listener InfluxdbBackendListenerClient to write the data to InfluxDB. Grafana is an open-source metric analytics and visualization suite. It is most commonly used for visualizing time series data for infrastructure and application analytics. 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
Often while working on projects, a team member may ask you to share your local Sitecore instance with them. Or you might even want to expose your local site to an external service for performance testing/analysis. There is a handy dandy tool that makes this really easy, ngrok. Using secure tunnels ngrok exposes local sites behind NATs and firewalls to the public internet. By connecting to the ngrok cloud service which accepts traffic on a public address and relays that traffic through to the ngrok process running on your machine and then on to the local address you specify.
There are various plans available including a free plan which supports:
- HTTP/TCP tunnels on random URLs/ports
- 1 online ngrok process
- 4 tunnels/ngrok process
- 40 connections / minute
With support for Sitecore 8.2 coming to an end 31st Dec 2019, several clients are planning their migration to Sitecore 9 if they have not done so already. This post describes the process and some of the tasks involved in upgrading from Sitecore 8x.
There are two main approaches when upgrading you might consider:
1. Upgrade existing instances – the upgrade is performed against the existing instances and rolled out to all environments.
- Additional infrastructure is not required for the upgrade
- Usually Requires a code freeze while the upgrade is rolled out to all environments.
- Unanticipated Issues can arise during the upgrade that can cause delays in the development lifecycle.
2. Clean Approach – setup a clean environment and clean Sitecore instances, migrate data.
- Upgraded and tested in isolation of the current production instance.
- Provides an opportunity to upgrade the OS & SQL.
- Easily rollback if issues occur.
- Code freeze to existing solution not required for the entire duration of the upgrade and bug fixes and new features can be rolled out and worked on in parallel to the upgrade.
- Additional Infrastructure is required for the new environments to run in parallel. We would need to spin up new servers to support the new environment as these would be running on different versions of the operating system and version of software to meeting the requirements of Sitecore 9.
- We will have the additional overhead of managing two sets of environments for a period of time while.
The clean approach effectively means you a Sitecore 8x environment – current site and a brand new Sitecore 9 environment – for the upgraded site.
Once you have switched over to 9 you can decommission the old environment. Continue reading