####
This article describes the infrastructure changes that you have to apply when you want to deploy a rendering host app into the Sitecore Managed Cloud containers environment.
The following steps need to be done to add a node.js based rendering host to Sitecore Managed Cloud:
- Prepare the Docker files
- Push the images to the Azure Container Registry (ACR)
- Define the Rendering host configuration files
- Create Rendering Host configuration overlays
- Add the image in the Application repository
- Register a domain name
- Extend the Front Door configuration
- Configure Ingress
- Enable the Rendering Host component
- Apply the changes
#### Prepare the Docker files
Refer to the [Running node.js based rendering host in AKS](https://www.brimit.com/blog/running-node-js-based-rendering-host-in-aks) guide for instructions on how to build corresponding custom images.
#### Push the images to the Azure Container Registry (ACR)
To push the images to the ACR:
- In PowerShell, [execute the docker push command](https://docs.docker.com/engine/reference/commandline/push). You must push all images to the pre-provisioned ACR: *{infrastructure\_id}acr*. Also, you can configure your Azure DevOps to push images in Sitecore Managed Cloud ACR.
#### Define the Rendering host configuration files
To create the Rendering configuration files:
1. Navigate locally to the Application repository folder and create a folder with the following path:
***Roles\sitecore-{topology}\bases\components\rendering***
2. Create the following Rendering Host configuration files into the folder that you created earlier:
- *rendering.yaml*, with the following content:
| apiVersion: v1
kind: Service
metadata:
name: rendering
spec:
selector:
app: rendering
ports:
- protocol: TCP
port: 80
---
apiVersion: apps/v1
kind: Deployment
metadata:
name: rendering
labels:
app: rendering
spec:
replicas: 1
selector:
matchLabels:
app: rendering
template:
metadata:
labels:
app: rendering
spec:
nodeSelector:
kubernetes.io/os: windows
containers:
- name: demo-rendering
image: demo-rendering
ports:
- containerPort: 80
imagePullPolicy: Always
env:
- name: SITECORE\_API\_HOST
value: http://cd
- name: NEXTJS\_DIST\_DIR
value: .next
- name: PORT
value: '80'
imagePullSecrets:
- name: regcred |
| --- |
- *kustomization.yaml*:
| apiVersion: kustomize.config.k8s.io/v1alpha1
kind: Component
resources:
- rendering.yaml |
| --- |
#### Create Rendering Host configuration overlays
To integrate any module configuration with the Managed Cloud Containers environment, you must define an overlay layer on top of the base configuration added above. It will simplify the upgrade process in the future as well as it is a good kubernetes practice in general.
To define the overlays:
1. Create the *roles\sitecore-{topology}\overlays\components\rendering\cm.yaml* file with the following content:
| ---
apiVersion: apps/v1
kind: Deployment
metadata:
name: cm
spec:
progressDeadlineSeconds: 3600
template:
spec:
containers:
- name: sitecore-xm1-cm
image: "{{ docker\_images.sitecore.cm }}"
env:
- name: JSS\_DEMO\_DEPLOYMENT\_SECRET
valueFrom:
secretKeyRef:
key: jss-deployment-secret
name: demo-common
- name: SITECORE\_JSS\_EDITING\_SECRET
valueFrom:
secretKeyRef:
key: jss-editing-secret
name: demo-common
- name: RENDERING\_HOST
valueFrom:
secretKeyRef:
key: rendering
name: sitecore-hostname
- name: RENDERING\_HOST\_PUBLIC\_URI
value: "https://$(RENDERING\_HOST)" |
| --- |
2. Create the *roles\sitecore-{topology}\overlays\components\rendering\rendering.yaml* file with the following content:
| ---
apiVersion: apps/v1
kind: Deployment
metadata:
name: rendering
spec:
progressDeadlineSeconds: 3600
template:
spec:
containers:
- name: demo-rendering
image: "{{ docker\_images.sitecore.rendering }}"
env:
- name: RENDERING\_HOST
valueFrom:
secretKeyRef:
key: rendering
name: sitecore-hostname
- name: SITECORE\_API\_KEY
valueFrom:
secretKeyRef:
key: demo-jss-api-key
name: demo-common
- name: JSS\_APP\_NAME
valueFrom:
secretKeyRef:
key: demo-jss-app-name
name: demo-common
- name: JSS\_EDITING\_SECRET
valueFrom:
secretKeyRef:
key: jss-editing-secret
name: demo-common
- name: PUBLIC\_URL
value: "https://$(RENDERING\_HOST)" |
| --- |
3. Create the *roles\sitecore-{topology}\overlays\components\rendering\kustomization.yaml* file with the following content:
| ---
apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization
resources:
- sitecore-roles.yaml
patchesStrategicMerge:
- cm.yaml
- rendering.yaml |
| --- |
4. To execute the overlays, navigate to *roles\sitecore-{topology}\tasks\main.yaml* and add the following:
| - name: Copy Sitecore roles configuration into Rendering Host overlay
template:
src: roles/sitecore-xm/templates/sitecore-roles.yaml
dest: roles/sitecore-xm/overlays/components/rendering/sitecore-roles.yaml
- name: Run Kustomization for Rendering Host integration
shell: |
kustomize build roles/sitecore-xm/overlays/components/rendering > roles/sitecore-xm/templates/sitecore-roles.yaml |
| --- |
#### Add the image in the Application repository
Now you need to add the rendering host image to the Application repository.
To change the images in the Application repository navigate to *config/docker-images* and edit the *docker-images.json* file as follows:
- Add the rendering property, and point it to the rendering image that we have pushed to the ACR on earlier steps.
For Sitecore XM, docker-images.json will look like below:
| {
"sitecore": {
"cm": "{infrastructure-id}.azurecr.io/xm1-cm:20221109.3-1.0.0",
"cd": "{infrastructure-id}.azurecr.io/xm1-cd:20221109.3-1.0.0",
"id": "{infrastructure-id}.azurecr.io/id6:20221109.3-1.0.0",
"rendering": "{infrastructure-id}.azurecr.io/rendering:20221031.4",
"mssql\_init": "{infrastructure-id}.azurecr.io/xm1-mssql-init:latest",
"solr\_init": "{infrastructure-id}.azurecr.io/xm1-solr-init:latest"
},
"external": {
"windowsservercore": "mcr.microsoft.com/powershell:lts-windowsservercore-1809"
}
} |
| --- |
#### Register a domain name
Because Rendering Host is a publicly available service, you must register a domain name for it.
To register a domain name:
1. Navigate to the portal where your DNS name is managed from.
2. Create an additional CNAME record for Rendering Host that points to Azure Front Door: *{infrastructure\_id}fdr.azurefd.net*,
where *infrastructureId* is your environment identifier that starts with mcc.
3. Navigate to the Azure Portal and create a secret within the Key Vault for the environment:
- Secret *name - sitecore-rendering-host-name*
- Secret value - the Rendering Host hostname that you created in the previous step.
#### Extend the Front Door configuration
You must extend the Front Door configuration with an additional public-facing service name.
To extend the Front Door configuration:
1. Navigate locally to the Application repository folder.
Open to edit the *frontdoor\backend-config.json* and define the rendering back-end config:
| {
"name": "rendering-ingress",
"probe\_path": "/api/healthz",
"backend\_list": [
{
"host\_header": "rendering.sitecore"
}
]
} |
| --- |
2. Navigate to *frontdoor\main.tf* and in the locals section, add a new variable to "*sitecore\_rendering\_host\_name*“:
| sitecore\_rendering\_host\_name = data.azurerm\_key\_vault\_secret.sitecore\_rendering\_host\_name.value |
| --- |
and
| sitecore\_rendering\_frontend\_endpoint\_name = replace("${local.sitecore\_rendering\_host\_name}-endpoint", ".", "-") |
| --- |
3. Define the data resource to retrieve the Horizon host name from the Key Vault:
| data "azurerm\_key\_vault\_secret" "sitecore\_rendering\_host\_name" {
name = "sitecore-rendering-host-name"
key\_vault\_id = data.azurerm\_key\_vault.this.id
} |
| --- |
4. In the "*azurerm\_frontdoor*" resource, define an additional *routing\_rule*:
| routing\_rule {
name = "HTTPS-rendering"
accepted\_protocols = ["Https"]
patterns\_to\_match = ["/\*"]
frontend\_endpoints = [local.sitecore\_rendering\_frontend\_endpoint\_name]
forwarding\_configuration {
forwarding\_protocol = "MatchRequest"
backend\_pool\_name = "rendering-ingress"
}
} |
| --- |
5. In the "*azurerm\_frontdoor*" resource, define the *frontend\_endpoint*:
| frontend\_endpoint {
name = local.sitecore\_rendering\_frontend\_endpoint\_name
host\_name = local.sitecore\_rendering\_host\_name
web\_application\_firewall\_policy\_link\_id = azurerm\_frontdoor\_firewall\_policy.front.id
} |
| --- |
6. Adjust HttpToHttps so that it covers the HTTPS-rendering routing rule:
7. You must now apply the changes with a pull request to the Infrastructure repository before you can continue with the next steps.
8. Run the [FrontDoor pipeline](https://doc.sitecore.com/xp/en/developers/102/managed-cloud/the-managed-cloud-standard-pipelines.html) to apply the changes and wait until the pipeline is executed successfully.
Define the “*azurerm\_frontdoor\_custom\_https\_configuration*” resource:
| resource "azurerm\_frontdoor\_custom\_https\_configuration" "rendering\_host\_https\_configuration" {
frontend\_endpoint\_id = azurerm\_frontdoor.this.frontend\_endpoints[local.sitecore\_rendering\_frontend\_endpoint\_name]
custom\_https\_provisioning\_enabled = true
custom\_https\_configuration {
certificate\_source = "AzureKeyVault"
azure\_key\_vault\_certificate\_secret\_name = data.azurerm\_key\_vault\_certificate.sitecore\_ingress\_certificate.name
azure\_key\_vault\_certificate\_vault\_id = data.azurerm\_key\_vault.this.id
azure\_key\_vault\_certificate\_secret\_version = data.azurerm\_key\_vault\_certificate.sitecore\_ingress\_certificate.version
}
depends\_on = [azurerm\_frontdoor.this]
} |
| --- |
9. Apply the changes to the environment with a pull request to the infrastructure repository.
10. Run the [FrontDoor pipeline](https://doc.sitecore.com/xp/en/developers/102/managed-cloud/the-managed-cloud-standard-pipelines.html) to apply the changes and wait until the pipeline is executed successfully.
#### Configure Ingress
Next you must define and apply the Ingress configuration and define the secrets.
To configure Ingress:
1. In the Application repository, navigate to the *roles\sitecore-{topology}\templates\* folder and create the *ingress-rendering.yaml* file with the following content:
| ---
kind: Service
apiVersion: v1
metadata:
name: rendering-external
spec:
type: ExternalName
externalName: rendering.{{ solution\_id }}.svc.cluster.local
ports:
- port: 80
---
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: sitecore-rendering-ingress
annotations:
kubernetes.io/ingress.class: "nginx"
nginx.ingress.kubernetes.io/force-ssl-redirect: "false"
nginx.ingress.kubernetes.io/rewrite-target: /
nginx.ingress.kubernetes.io/proxy-buffering: "on"
nginx.ingress.kubernetes.io/proxy-buffers-number: "4"
nginx.ingress.kubernetes.io/proxy-buffer-size: "256k"
spec:
rules:
- host: "rendering.sitecore"
http:
paths:
- path: /
pathType: Prefix
backend:
service:
name: rendering-external
port:
number: 80 |
| --- |
2. To define secrets, navigate to *roles\sitecore-{topology}\templates\secrets.yaml* and define the *sitecore-rendering-host-name* secret with *sitecore-secret-provider*. Extend the *sitecore-hostname* secret:
| - key: rendering
objectName: sitecore-rendering-host-name |
| --- |
3. Add sitecore-rendering-host-name as a secret-provider parameter:
| - |
objectName: sitecore-rendering-host-name
objectType: secret |
| --- |
4. Add the new task to *roles\sitecore-{topology}\tasks\main.yaml*:
| - name: Install external Rendering ingress service
k8s:
apply: true
namespace: "nginx"
state: present
definition: "{{ lookup('template', 'ingress-rendering.yaml') }}"
validate:
fail\_on\_error: yes |
| --- |
####
Enable the Rendering Host component
To enable the Horizon component:
- In the Application repository, navigate to the *roles\sitecore-{topology}\overlays\platform\kustomization.yaml* file and enable Rendering with the *components* element, pointing to the Rendering module configuration scripts folder.
| components:
- ../../bases/components/rendering |
| --- |
#### Apply the changes
To apply the changes:
- Apply the application changes to the environment with a pull request to the application repository.
###### More from author
[##### Deploy custom headless Sitecore solution in Sitecore XM Cloud
November 10, 2022](https://www.brimit.com/blog/deploy-custom-headless-sitecore-solution-in-sitecore-xm-cloud)[##### Running custom next.js editing host in Sitecore XM Cloud
September 29, 2022](https://www.brimit.com/blog/running-custom-next-js-editing-host-in-sitecore-xm-cloud)[##### Running node.js based rendering host in AKS
June 17, 2022](https://www.brimit.com/blog/running-node-js-based-rendering-host-in-aks)
###### Author
[!\[artsiom-photo\](https://www.brimit.com/-/jssmedia/feature/blogs/authors/artsiom-200.jpg?h=202&iar=0&w=200&hash=41797D2540DF6EB6FDF558360F6F62B8)
Artsem Prashkovich
Sitecore MVP/ Solution Architect](https://www.brimit.com/blog/author?authors=Artsem%20Prashkovich)
###### More by category
[#Events](https://www.brimit.com/blog?categories=#Events)[#How-to](https://www.brimit.com/blog?categories=#How-to)[#News](https://www.brimit.com/blog?categories=#News)[#Guides](https://www.brimit.com/blog?categories=#Guides)
###### More by platform
[DXP](https://www.brimit.com/blog?platforms=DXP)[Sales and marketing automation](https://www.brimit.com/blog?platforms=Sales%20and%20marketing%20automation)[Application innovation](https://www.brimit.com/blog?platforms=Application%20innovation)
#### More on Sitecore
[!\[How Vercel Will Help You Save Effort When Deploying Sophisticated Sitecore Projects\](https://www.brimit.com/-/jssmedia/project/brimit/blog/2024/vercel_cover-image.png)
#Guides#How-toDXPE-commerce
##### How Vercel Will Help You Save Effort When Deploying Sophisticated Sitecore Projects
Optimize and accelerate the development and deployment of complex multisite Sitecore projects.
Alexei Vershalovich on July 17, 2024](https://www.brimit.com/blog/how-vercel-will-help-you-save-effort-when-deploying-sophisticated-sitecore-projects)
[!\[Training Up Tomorrow's Sitecore MVPs: a Mentoring Success Story\](https://www.brimit.com/-/jssmedia/project/brimit/blog/2023/sitecore-mentoring---cover-image.png)
#How-toDXP
##### Training Up Tomorrow's Sitecore MVPs: a Mentoring Success Story
How to participate in the Sitecore Mentor program and help younger colleagues jump-start a career in Sitecore development.
Sergey Baranov on October 2, 2023](https://www.brimit.com/blog/training-up-tomorrows-sitecore-mvps)
[!\[Going Headless. Part 2: When a Headless CMS Is Your Best Bet (if you have Sitecore)\](https://www.brimit.com/-/jssmedia/project/brimit/blog/2022/headless/adobestock_456986731.jpg)
#How-toDXPE-commerce
##### Going Headless. Part 2: When a Headless CMS Is Your Best Bet (if you have Sitecore)
Discover how a headless CMS can benefit organizations that use Sitecore.
Daniil Raschupkin, Palina Trokhautsava on September 15, 2022](https://www.brimit.com/blog/going-headless-part-2-when-a-headless-cms-is-your-best-bet-if-you-have-sitecore)
