####
Past years have proven that the headless approach becomes popular and evolves rapidly along with a number of technologies that we can use to build and run our front-end part of the solution which is also called “rendering host”. In this article I will primarily write about running a node.js based rendering host in Azure Kubernetes Services (AKS) and in windows based containers specifically.
Working with containerized solutions locally, in Docker, we utilize a simplified way to run our next.js application just mirroring a code stored in our locale into the container. So, during a build, we don’t copy the project code to image and it is not compiled to be run independently. This approach works only locally, where we store the code and run it on the same machine.
This post requires a basic docker knowledge on how to [build](https://docs.docker.com/build) and [compose](https://docs.docker.com/compose) the application.
**Docker-compose.yml** and **Dockerfile** for this setup looks like below:
| version: "2.4"
services:
# A Windows-based nodejs base image
nodejs:
image: ${REGISTRY}${COMPOSE\_PROJECT\_NAME}-nodejs:${VERSION:-latest}
build:
context: ./docker/build/nodejs
args:
PARENT\_IMAGE: mcr.microsoft.com/windows/servercore:1809
NODEJS\_VERSION: ${NODEJS\_VERSION}
scale: 0
rendering:
image: ${REGISTRY}${COMPOSE\_PROJECT\_NAME}-rendering:${VERSION:-latest}
build:
context: ./docker/build/rendering
target: ${BUILD\_CONFIGURATION}
args:
PARENT\_IMAGE: ${REGISTRY}${COMPOSE\_PROJECT\_NAME}-nodejs:${VERSION:-latest}
volumes:
- .\src\Project\DemoProject\nextjs:C:\app
environment:
SITECORE\_API\_HOST: "http://cd"
NEXTJS\_DIST\_DIR: ".next-container"
PUBLIC\_URL: "https://${RENDERING\_HOST}"
JSS\_EDITING\_SECRET: ${JSS\_EDITING\_SECRET}
depends\_on:
- cm
- nodejs
labels:
- "traefik.enable=true"
- "traefik.http.routers.rendering-secure.entrypoints=websecure"
- "traefik.http.routers.rendering-secure.rule=Host(`${RENDERING_HOST}`)"
- "traefik.http.routers.rendering-secure.tls=true" |
| --- |
In the *docker-compose* file we can see two services required for services (images) to be running in docker:
- **nextjs** - simple, windows base image where we install node.js server for further running our next.js app.
- **rendering** - I call it “pseudo-container” because it doesn’t include any code and uses volumes to mirror the code from the host machine to the image.
Dockerfile for nextjs is stored by the **./docker/build/nodejs** (as defined in docker-compose) path and looks like below:
| # escape=`
#
# Basic Windows node.js image for use as a parent image in the solution.
#
ARG PARENT\_IMAGE
FROM $PARENT\_IMAGE
ARG NODEJS\_VERSION
WORKDIR c:\build
RUN curl.exe -sS -L -o node.zip https://nodejs.org/dist/v%NODEJS\_VERSION%/node-v%NODEJS\_VERSION%-win-x64.zip"
RUN tar.exe -xf node.zip -C C:\
RUN move C:\node-v%NODEJS\_VERSION%-win-x64 c:\node
RUN del node.zip
USER ContainerAdministrator
RUN SETX /M PATH "%PATH%;C:\node"
USER ContainerUser |
| --- |
rendering Dockerfile is much simpler:
| # escape=`
#
# Development-only image for running Next.js in a containerized environment.
# Assumes that the Next.js rendering host source is mounted to c:\app.
#
ARG PARENT\_IMAGE
FROM ${PARENT\_IMAGE} as debug
WORKDIR /app
EXPOSE 3000
ENTRYPOINT "npm run start:connected" |
| --- |
We can see that the rendering Dockerfile doesn’t perform any build and only runs “**npm run start:connected**” when the container is mounted. But the image that we get as a result can’t be run in Kubernetes. Kubernetes only runs images and doesn’t perform builds. Which means we need to prepare all required images using CI/CD processes and push them to a Container Registry. In this case, we still need a docker-compose file. I usually create it separately for AKS and call it like **docker-compose.aks.yml** because it is quite specific for AKS:
| version: "2.4"
services:
# A Windows-based nodejs base image
nodejs:
image: ${REGISTRY}${COMPOSE\_PROJECT\_NAME}-nodejs:${VERSION:-latest}
build:
context: ./docker/build/nodejs
args:
PARENT\_IMAGE: ${NODEJS\_PARENT\_IMAGE}
NODEJS\_VERSION: ${NODEJS\_VERSION}
scale: 0
rendering:
image: ${REGISTRY}${COMPOSE\_PROJECT\_NAME}-rendering:${VERSION:-latest}
build:
context: ./src/Project/DemoProject/nextjs
dockerfile: Dockerfile
args:
PARENT\_IMAGE: ${REGISTRY}${COMPOSE\_PROJECT\_NAME}-nodejs:${VERSION:-latest} |
| --- |
In the code above we can still see two services. nodejs is exactly the same as for local setup and uses the same Dockerfile as I mentioned at the beginning of the article. The rendering Dockerfile, at the same time, represents a multi-stage build of next.js app. During the build we install npm packages, copy node\_modules to the image, perform next.js build and, finally, copy next.js artifacts:
| ARG PARENT\_IMAGE
FROM ${PARENT\_IMAGE} as dependencies
WORKDIR /app
COPY package.json ./
RUN npm install
FROM ${PARENT\_IMAGE} as builder
WORKDIR /app
COPY . .
COPY --from=dependencies /app/node\_modules ./node\_modules
ENV NEXT\_TELEMETRY\_DISABLED 1
RUN npm run build
FROM ${PARENT\_IMAGE} as runner
WORKDIR /app
ENV NODE\_ENV production
ENV NEXT\_TELEMETRY\_DISABLED 1
USER ContainerAdministrator
SHELL ["powershell", "-Command", "$ErrorActionPreference = 'Stop'; $ProgressPreference = 'SilentlyContinue';"]
COPY --from=builder /app/next.config.js ./next.config.js
COPY --from=builder /app/tsconfig.scripts.json ./tsconfig.scripts.json
COPY --from=builder /app/tsconfig.json ./tsconfig.json
COPY --from=builder /app/public ./public
COPY --from=builder /app/.next ./.next
COPY --from=builder /app/node\_modules ./node\_modules
COPY --from=builder /app/scripts ./scripts
COPY --from=builder /app/src ./src
COPY --from=builder /app/package.json ./package.json
COPY --from=builder /app/.graphql-let.yml ./.graphql-let.yml
RUN Remove-Item -Path C:\app\.next\static -Force -Recurse;
EXPOSE 80
EXPOSE 443
ENTRYPOINT "npm run start:production" |
| --- |
As a result of the above we will get an image with all javascript code precompiled. When image bounds in Kubernetes, "npm run start:production" command will be executed.
Now we have images ready to be run in Azure Kubernetes Services. In this article I don’t describe how to run the whole Sitecore in Kubernetes. It is pretty well described in Sitecore documentation that you can easily download from the site here. The rest of the article only explains how to add the rendering host to the default k8s specification. If you setup your cluster and deploy Sitecore by its documentation, your k8s specification looks like below: 
First thing that we have to do, is to add a new yaml file called “rendering” and put there the following configuration:
| apiVersion: v1
kind: Service
metadata:
name: rendering
spec:
selector:
app: rendering
ports:
- protocol: TCP
port: 3000
targetPort: 3000
---
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: [your project name]-rendering
image: #{CONTAINER-REGISTRY}##{COMPOSE\_PROJECT\_NAME}#-rendering
ports:
- containerPort: 3000
imagePullPolicy: Always
env:
- name: DEBUG
value: sitecore-jss:\*
- name: SITECORE\_API\_HOST
value: http://cd
- name: NEXTJS\_DIST\_DIR
value: .next
- name: PUBLIC\_URL
value: https://{YOUR-RENDERING-HOST-PUBLIC-URL}
- name: JSS\_EDITING\_SECRET
Value: {YOUR-JSS-EDITING-SECRET}
- name: SITECORE\_API\_KEY
valueFrom:
secretKeyRef:
name: [your project name]-global
key: [your project name]-global-api-key.txt
- name: JSS\_APP\_NAME
valueFrom:
secretKeyRef:
name: [your project name]-global
key: [your project name]-global-jss-app-name.txt
imagePullSecrets:
- name: regcred |
| --- |
In configuration above we can see the definition of k8s service which is used for communication between environment parties and definition of the rendering deployment which will finally represent our rendering host pod. Take into account that the configuration has environment variables and you need to replace some of them (or all) with your values. As for me, I replace these values during the CI/CD process.
And the last thing left, is to extend our nginx-ingress controller with one additional rule to forward traffic from you host to the rendering host:
| - host: your-host-name.com
http:
paths:
- path: /
pathType: Prefix
backend:
service:
name: rendering
port:
number: 3000 |
| --- |
###### 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 Sitecore Managed Cloud
August 3, 2022](https://www.brimit.com/blog/running-node-js-based-rendering-host-in-sitecore-managed-cloud)
###### 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)
