If you’ve never used the publishing service before it’s an awesome opt-in for Sitecore to provide blazingly fast publishing by performing bulk publish operations. If you are needing to improve performance over your existing Sitecore publishing or reduce load on your Content Management Role then you should consider looking into setting up Publish service available since Sitecore 8.2. In this post I’ll share some discoveries while setting up Publish Service v4.2 on Sitecore 9.3 on Azure PaaS. It was pretty straightforward and painless! It just works really well!
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
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.
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.