DEV Community

Kenneth McAndrew
Kenneth McAndrew

Posted on

Sitecore Managed Cloud Containers: An Introduction

So, back to the beginning. What is Sitecore managed cloud containers?

First, let's back up a bit more. Sitecore started a managed cloud service, where they would set up the infrastructure of your Azure environment for you, leaving you to manage your solution more than the ins and outs of Sitecore. It's not truly software-as-a-service (SaaS) in that you still need to handle upgrades and patches; Sitecore is preparing a SaaS offering in the near future, however. But the idea is they'll handle architecture, alerts, watch performance, etc.

This splits into the platform-as-a-service (PaaS) camp and the containers (Kubernetes) camp. The PaaS side, to be honest, is very much like you can set up with the Azure marketplace today, but with Sitecore backing it and adding alerting to help you, and them, out. The containers side is more robust and "modern" and what we'll discuss here at a high level.

What You Get Out of the Box

When you set up a new containers instance with Sitecore (done via a service request in the support portal), you're given the following assets:

  • Azure Kubernetes Service (AKS): The place that will run your containers, equivalent to the app services of the PaaS world.

  • Container registry: This is where you will upload custom images to use for AKS. We'll discuss this a bit more below.

  • FrontDoor/Web Application Firewall (WAF): The routing tool that exposes your front-end addresses, such as the CM, CD, identity server, and others you might add in (like Horizon). The advantage here is that unlike a PaaS setup, your xConnect services aren't publicly exposed. The WAF helps protect you from malicious attack, and by default is set for the CD only, but you can create a WAF to use for IP restrictions on your CM. (That's another blog post!)

  • Azure SQL: All of the databases you need for Sitecore. But in this containers world, Sitecore got wiser and is making use of elastic pools, allowing resources to be shared between databases, so if your master database needs more "oomph" but your xConnects don't right away, you can rob Peter to pay Paul, so to speak.

  • Key Vault: A secure place to store your secrets and certificates. By default you'll find SQL usernames and passwords, Sitecore's admin password, and a host of other information. This gets read into the containers but not written there, keeping the data protected if someone cracks your pod. Of course, you can add your own secrets and wire them in. (Yep...that's another blog post...)

  • Azure Dev Ops repository: Wait...you get another one?!? Well, read on...

The Managed Cloud Dev Ops Repository

First, let's be clear, this is not for your solution code! You'll maintain your custom code in your own repository, and as part of your build process, you'll create a custom image that'll be sent over to the container registry. (You guessed it, another blog post!)

Sitecore provides two repositories: infrastructure and application. The infrastructure repository sets up the guts of your environment, and if you look through there you'll see things like FrontDoor clear as day. This is the repository you're less likely to change, but if you need to add an endpoint (like for Horizon) or WAF to FrontDoor, this is where you'd do it.

The application repository is what establishes the containers, identifies the images to be used, connects the secrets via Key Vault, etc. By default, you get an out-of-the-box Sitecore instance. As time goes on, you'll replace at least the CM and CD images with your own, and if you customize other images, this is where you'll do that as well. When you push a new image up, you'll update the tag and run the application pipeline, which will deploy your changes for the world to see.

Now That You've Seen It From 10,000 Feet...

Future blogs will dig into some of these processes more, as well as some practices I've helped put together that helped us get going. But you can get started with Sitecore's Docker examples...in fact, our upgrade project started out from their "custom-images" folder. From little acorns, mighty oaks grow.

Now, am I saying to do it my way? Nope! But managed cloud containers is a bit of a "wild west" at the moment, and anything we can do to provide guidance is helpful. I'd encourage you to join Sitecore Slack, the Docker channel will be good to help you get going, whether with this or Sitecore containers in general. For now at least, this is the direction Sitecore is moving in, so becoming familiar with Docker/Kubernetes/containers is important.

Good luck!

Top comments (0)