Sitecore PaaS/AKS blue-green deployments
With modern and mature DevOps, we all want smooth, sleek and painless automated deployments with zero-downtime. Sitecore deployments are no exception. Have you embraced zero-downtime deployments? This is not a new topic. If you look around Sitecore community, you see an odd question popping here and there regarding this topic.
The journey towards achieving zero-downtime deployments for any application in fact starts with your code base. So, in this series of blog posts, we will refresh ourselves on concepts like “Code Freeze” and the CI/CD process before deep diving into implementing Sitecore zero-downtime deployments.
- Sitecore Zero-downtime deployments – Part 1 (Do we need code or content freeze?)
- Sitecore Zero-downtime deployments – Part 2 (Sitecore Container CI/CD process)
- Sitecore Zero-downtime deployments – Part 3 (Blue-Green deployments)
- Sitecore Zero-downtime deployments – Part 4 (this post)
Sitecore XP PaaS Blue-Green architecture
The infographic above shows a typical Azure PaaS architecture for Sitecore XP scaled topology. In summary we have:
- our Sitecore XP application roles such as CM, CD, ID among others
- these role have access to Sitecore databases (master, web, core among others)
- access to rest of the services such as Azure Key Vault, Azure Redis cache, App Insights, Azure Search among others
You will notice in this architecture, we have Blue-Web and Green-Web databases, which are corresponding to the BLUE-GREEN deployment slots for the CD App Service. We need separate web databases to enable us achieve content-safe deployments
The CM App Service also has BLUE-GREEN deployment slots specifically for code deployment, but with a shared master database. There is no compelling reason to have BLUE-GREEN master databases purely on basis of complexity introduced by such architecture (although it is not impossible to implement if you prefer this approach).
The rest of our XP scaled topology resources are shared
The Azure DevOps organisation typically will have access to run the CI/CD pipelines, is also included in the architecture.
How to manage settings
App Service Settings section can be leveraged to manage your Sitecore configuration settings including Sitecore connections Strings
Sitecore XP PaaS CI/CD process summary
Required steps:
- Tigger CD process
- Make copy of your web-db – this is for content safe deployment. Both CM and BLUE CD pointing to original web-db at this point. BLUE CD still in production with our live users accessing it
- Now deploy your new version to both CM instance and GREEN CD Staging slot instance – pointing them to use copy of web-db. Perform content deployment as usual, publish, rebuild the Sitecore indexes and perform any tests. This will not affect your BLUE CD at this stage.
- Once happy with deployment, then Swap CD production and staging slots. The GREEN CD with our new version is now production and our live users accessing it now. Zero down time achieved! Our previous version is still running in BLUE CD. If we have issues, we swap again to roll back.
Some notes:
This example doesn’t have BLUE-GREEN for the CM instance, as I want to keep it simple – This though means your content editors will have to wait for deployment to finish to use the CM. If you really need CM zero down time, then you need to deploy CM BLUE-GREEN deployment slots as well. Alternatively, you can keep the deployment time to CM to a minimum and avoid BLUE-GREEN
You can be more also be creative with your Sitecore templates changes such that your changes are always backward compatible between successive releases (e.g. don’t delete fields immediately, mark them as obsolete) This means you can safely rollback your changes without breaking the application
Sitecore XP AKS Blue-Green architecture
Sitecore using Containers makes use of Azure Kubernetes Service. This infographics shows a very simplified AKS blue-green strategy allows us to achieve zero downtime deployments.
How does it work?
- You will define a blue deployment for v1 and apply it to your desired state of your cluster.
- When version 2 comes along, you define a green deployment, apply it to your cluster, test and validate it without affecting blue deployment
- You then gradually replace V1 with V2
- Version 1 can be deleted if no longer needed.
Below we have a typical Sitcore XP Azure Kubernetes Service architecture for Sitecore XP scaled topology – the AKS cluster containing various pods running our containers.
You can see the scaled out Sitecore XP application roles running as individual Pods within this AKS cluster backed by a Windows Node Pool.
We also have access to Sitecore databases as well as other services such as Azure Key Vault, Azure Redis cache, App Insights among others.
I am showing our Azure DevOps organisations which will typically have access to run the CI/CD pipelines
Similar to the Azure PaaS architecture, AKS zero downtime deployments will make use of BLUE-GREEN deployment strategy for CD or CM instance
AKS Zero downtime deployments process
How do we do that? we don’t need to provision a separate cluster for GREEN environment. Instead, we define an additional GREEN deployment with its corresponding service and then label it accordingly, alongside our BLUE deployment.
For content-safe deployments, we will also be pointing to a copy of web database (Green) as shown.
Once we have tested and are happy with our new GREEN deployment, we switch traffic or routing to point to GREEN. We do this by updating our Ingress controller specification
In the above infographic, you can see now our end-users can access V2 in the GREEN deployment
BLUE deployment is on stand-by in case of roll back. And can be deleted if no longer required.
Note as previously discussed in PaaS deployments, you can implement BLUE-GREEN for the CM if required
Sitecore XP AKS CI/CD process
Steps summary
- Trigger release pipeline process
- Make copy of your web-db – this is for content safe deployment. Both CM and BLUE CD pointing to web-db at this point. BLUE CD still in production with live users accessing it
- Apply your green deployment desired state onto the cluster. This creates the green pods with new version of docker images, and our Sitecore deployment including content deployment. This will use the copy of web-db we created earlier. Publish and Rebuild indexes as usual and test and verify the deployment
- Once happy with deployment, Update traffic routing in Ingress Controller and live users can now access our new Sitecore version. In event of roll-back, update traffic routing in Ingress controller. If BLUE deployment no longer needed, clean it up to save on resources
Next steps
An this is a wrap. This post concludes this series of blog posts where we looked into implementing Sitecore Zero Downtime deployments. I hope you found this useful and can start your own journey towards achieving Zero Downtime deployments with your Sitecore workloads. If you have any comments or queries, please leave me a comment at the end of this post.
