So I’ve been involved in several projects where I’ve had to setup geo-distributed Sitecore environments and/or scale the Sitecore Content Management and Content Delivery roles along with the plethora of roles XP Scaled provides. I’ll share some of those experiences here and some hurdles and how to overcome them.
Geo-Distributed Content Delivery
You can configure one or more content delivery servers for improved scalability and better performance. If you expect to have high numbers of visitors or want to configure servers in different geographic locations, ideally nearest to your customers.
In order to reduce latency you will want your web database in the same region as your CD. If you have multiple clusters in different regions you will need to consider how you plan to keep these web dbs up-to-date. Normally you would implement multiple publish targets, however Sitecore also supports geo-replication of the web database. See my post on Publish Targets vs Azure Geo replication for more details.
What other services and or roles do you need to support Content Delivery and where should these be located? More on this later… Continue reading
Performance tools, like dotTrace profiler are really useful when trying identify potential bottlenecks in your Sitecore application. Normally, attaching to the w3wp.exe process and profiling your local Sitecore instance is relatively straightforward, however now that we are taking advantage of Docker and running our instances in containers the process is slightly different. In this post I’ll show you how to profile your Sitecore instance running in containers.
When designing for a Geo-Distributed Sitecore implementation you have a decision to make on how you are going to handle updates to your Web databases located in different regions.
Traditionally you would set up a multiple publishing targets – one for each region and publish to each target. However, Sitecore supports Azure Active Geo-Replication of the read-only web database for Sitecore 9.0 and above. Which means you only need to publish to one web database and let Azure SQL replication update the other regions.
While this still experimental it offers faster publishing as you only publish to one target and let Azure handle the updating to the other regions.
Shared Web System DB
For this to work you need to setup a shared web system database to contain a copy of the EventQueue and Properties table, as these cannot be shared and must remain common amongst each Content Delivery role.
Sitecore provides information on how to configure the Content Delivery roles for separate EventQueue and Properties tables.
In part 1 of this series, I introduced Prometheus and lay some foundations for monitoring a Sitecore container environment using Prometheus. In this post, I will show you how to collect and monitor the Host OS and container metrics exposed by Docker.
Why should we care about Docker the Host OS Metrics?
To monitor your containerized Sitecore application effectively you need to understand the health of the underlying system your containers are running on. To achieve this, you have to monitor the system metrics like CPU, memory, network, and disk also docker is starting and stopping containers so you need to know the state of your docker resource.
How to collect Docker performance metrics
Docker supports Prometheus OOTB and provides performance metrics you can collect and monitor, however it is disabled by default.
1. Enabling Docker Metrics.
First things first lets enable the metrics. Open the daemon.json file and add the metrics-address setting:
“metrics-addr” : “127:0:0:1:9323”
Apply and restart docker. Now you should be able browse to the docker metrics 127.0.0.1:9323/metrics and verify metrics are exposed.
In a previous post I provided you with some techniques to help you monitor your Containerized Sitecore instance using native tools. Over the next few posts, I will show some of the common tools and techniques used for monitoring applications running in containers. When I initially started thinking about this I considered using InfluxDB as my time series DB to store the performance metrics and Grafana for visualizing and alerting. As both of these were already in my tool-set for load testing. However, the more I dug into monitoring container performance I quickly realized, Prometheus has established itself as the leading tool in this space and Docker also provides support for Prometheus – more on that later. So let’s start with an introduction to Prometheus and lay some foundations for a monitoring platform.
What is Prometheus?
Prometheus is an open-source application for monitoring systems and generating alerts. It can monitor almost anything, from servers to applications, databases, or even a single process. Prometheus monitors your defined targets by scraping metric data in a simple text format that is exposed by the target. Prometheus stores this metric data in a multi-dimensional data model by metric name and key/value in its timeseries database which can then be queried and retrieved using its own query language PromQL, in a nutshell.
Let’s take a quick look at the the main components and architecture that comprise of the Prometheus platform.
Occasionally you may need to connect to the Sitecore SQL instance and inspect the databases when running in docker. This is relatively straightforward.
Using SQL Manager
1. Identify the IP address of your SQL Instance
PS> docker inspect container [options] <container id/name>
NOTE: IP address changes every time you run docker-compose up.
If you are not sure of the name of your container name or id you can use the following command to get list of running containers
PS> docker container ls Continue reading
Over the course of several months I have had the opportunity to introduce the use of docker within development teams as an alternative approach for developing with Sitecore. Developing with Sitecore on Docker requires a bit of a mind shift from your normal way of working with Sitecore. But if offers many benefits like the ability to stand up a fully scaled instance of Sitecore in seconds rather than hours. This blog provides a introduction to docker and getting started developing with Sitecore on Docker.
What is Docker
Docker is a platform that enables you to develop, ship, and run applications as containers. The Docker Daemon process (or engine) runs on your host OS which manages images and containers.
The Command Line Interface (CLI) communicates with the docker daemon via rest API.
Containers vs VMs
Containers are an abstraction at the app layer that packages code and dependencies together. Multiple containers can run on the same machine and share the OS kernel with other containers, each running as isolated processes.
- take up less space.
- more portable and efficient.
- require fewer VMs and Operating systems.
- reduce cost as fewer licenses are required.
- start in seconds.
- are ephemeral – treated like cattle in your DevOps service model.
VMs are an abstraction of physical hardware turning one server into many servers. The hypervisor allows multiple VMs to run on a single machine.
- includes a full copy of an operating system, the application, necessary binaries and libraries – are much larger in size.
- VMs can also be slow to boot.
- start in minutes
- tend to hang around longer – treated more like pets in your DevOps service model.
By combining Containers and VMs in your infrastructure provide a great deal of flexibility in deploying and managing your application.
Sitecore Docker Repo
The Sitecore Docker Repo contains docker files for a plethora of Sitecore versions and their variants including: JSS, SXA, SPE. Also necessary scripts, tools and supporting documentation to help you build Sitecore Docker images and ultimately run a containerized instance of Sitecore.
Lets backup for those of you that may not be familiar with some of these terms:
- Dockerfile – is a text document that contains all the commands you would normally execute manually in order to build a Docker image.
Docker can build images automatically by reading the instructions from a Dockerfile.
- Docker Images – are the basis of containers. An Image is an ordered collection of root filesystem changes and the corresponding execution parameters for use within a container runtime. An image typically contains a union of layered filesystems stacked on top of each other. An image does not have state and it never changes.
- Docker Container– is a runtime instance of a docker image.
Thanks to the hardwork and dedication to the individuals in our community that contribute to the Sitecore Docker repo. Which is continually evolving.
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.