Aceik

Sitecore Specialists

Category: Sitecore 10

Sitecore 10 Content Serialization and best practices – Part 3

Posted by on in Sitecore, Sitecore 102 Comments

SCS is pretty new, and there are a few basic recommendations while doing the first setup, In this blog, we will discuss those settings and options.

This blog has split into three parts, and this is part 3.

  1. Configure the relative serialization path correctly. In Microsoft NTFS the maximum length is 240. In SCS the content serialization path size limit is defined in the settings, by default, the value is 100.
{
  "$schema": "./.sitecore/schemas/RootConfigurationFile.schema.json",
  "modules": [
    "src/*/*/*.module.json"
  ],
  "serialization": {
    "defaultMaxRelativeItemPathLength": 100,
    "defaultModuleRelativeSerializationPath": "items"
  }
}

The maximum relative item path length = the file system maximum path and file name length – (the base path length + the serialization path length). for more details, please follow this link – Configure the maximum relative item path length

2. Define the hash and alias for relative serialization path – Hashing to shorten paths and aliases and to make it human readable.

It’s super important for two purposes. One is to mitigate the risk of serialization path, and second is define the structure of the project like we can define common aliases for the site.

Relative path is combination of four section (Base path + serialization path +include path content item path) , for example

C:\Users\jsoni\Sitecore\Project\src\Sites\ +  serialization\ + content\ + Home\Products\P1\test.yml

define the alias 

"rules": [
  {
    "path": "/Home/Products/P1/test",
    "alias": "alpath"
  }
]

3. Sequence is most important while defining the module.json – As a rule of thumb with Sitecore, all the dependencies should be defined first, for example before defining the content we have to define the templates, layout and rendering etc.

for example

{
  "namespace": "Feature.Hero",
  "items": {
    "includes": [
      {
        "name": "templates",
        "path": "/sitecore/templates/Feature/Hero",
        "allowedPushOperations": "createUpdateAndDelete",
        "scope": "itemAndDescendants"
      },
      {
        "name": "layouts",

        "path": "/sitecore/layout/Renderings/Feature/Hero",
        "allowedPushOperations": "createUpdateAndDelete",
        "scope": "itemAndDescendants"
      }
    ]
  }
}

4. Don’t forget first-match-wins principle while defining the IA or base principle of the content sync strategy – this rule says when a content item matches a rule, all subsequent rules are ignored:

first-match-wins principle

As per the Sitecore recommendation, we need Keep the following things in mind when we configure rules:

  • No path overlapping, If you follow the Helix principles I’m sure it will be much easier, otherwise it can be very hard to identify any path overlaps.
  • Again, Parent rules will override the child rule, example if you have mentioned a rule on parent item node, It will override any child rule configuration.
  • Rule scopes cannot be more inclusive than the root scope. For example, if the root scope is ItemAndChildren, the rule scope cannot be ItemAndDescendants.
  • The alias property in a rule replaces the root name property (the folder name in your file system) for this particular rule.
  • If you have configured an alias property and a scope property with an ignored value, the scope is used. Content items scoped to be ignored are not influenced by aliases.

For more details, please follow below links

I hope this blog will help you to think of a few fundamental considerations while starting to work with SCS on Sitecore.

Sitecore 10 Content Serialization and best practices – Part 2

Posted by on in Sitecore, Sitecore 102 Comments

Unicorn was the most popular plugin for content serialization. It was very straightforward and well managed; all the documents were very descriptive and easy to understand. Now we have Sitecore Content Serialization (SCS), I think we must understand what has changed. Are we losing or gaining any functionality? what changes are required to our existing setup? Re there any changes in terminology etc?

This blog has been split into three parts, and this is part two.

Below is the high-level comparison between Unicorn and SCS.

  1. SCS has an additional Visual Studio plugin to manage Content.

VS plugin provides the below options –

1. Option to push and pull changes
2. Differences between disk and database content
3. Option for selected item sync

SCS has Sitecore command line (CLI) Interface and Unicorn has it’s own page.

SCS configuration is based on JSON files and Unicorn configuration is based on XML.

The configuration file naming convention is different. The SCS configuration file names contain modules for identification and Unicorn configuration contains serialization – Although this is configurable.

The initial setup is different. For SCS we have to setup the package and to enable the CLI it’s required to install the packages.

Difference in global/shared configuration

Difference in project level configuration.

Difference in feature/module level configuration.

SCS provides more flexibility for rule based configuration, for each feature we can define a rule and each rule has the option to define the path, scope and allowed PushOperations etc.

There are changes in the configuration.

When using Unicorn we used to define the dependencies and extends options

<configuration name="Feature.Demo" description="Feature Demo" dependencies="Foundation.*" extends="Helix.Feature">

With SCS, we need to handle it while defining the feature itself and any overlap, for example if there is any specific overlap we need to make sure to put the most specific rule first.

Rule of Parent’s path override rule of children’s and dependent path.

Overall, I can see the SCS configuration is much easier and more flexible. However, I’m still looking for an option for pattern-based formats in SCS.

I hope this comparison will provide a basis to understand the difference between Unicorn and SCS.

Sitecore 10 Content Serialization and best practices – Part 1

Posted by on in Sitecore, Sitecore 102 Comments

Sitecore has introduced Sitecore Content Serialization (SCS) as part of version 10. In this blog, I will explain the basic concept of serialization and compare all Unicorn features, followed by steps for the basic setup and best practices.

This blog has split into three parts, and this is part 1.

Part 1 – Sitecore 10 SCS- Basic concept

Let’s first try to understand the definition, Serialization is the process of translating a data structure or object state into a format that can be stored (for example, in a file or memory data buffer) or transmitted (for example, across a computer network) and reconstructed later (possibly in a different computer environment) – Wikipedia

Sitecore Content Serialization (SCS) is a system for serializing, sharing, and deploying content items, as well as keeping them in version control – Sitecore

Now, we know the definition of serialization. I remember with the Sitecore 6.X Serialization guide we had an option to serialize the item tree and restore it, there were additional options to configure the serialization based on the events like item saved, created, deleted etc. and we were using SVN to store those serialized files.

Growing of TDS (Team Development for Sitecore) foundation

TDS was beneficial to manage the project and item files. I used TDS a lot with Sitecore 6.X versions. We were also using this as part of the deployment process as the underlying TDS was using the MSBuild project file to group the Sitecore items into a deployable project. Additionally to that, it has the below features which are not part of SCS.

  • File deployment into a local Sitecore instance
  • Web Deployment Package (WDP) generation
  • Code generation
  • Validators
  • Environment Validation

Note – Paid license is required for TDS and the cost was around USD 400

In my opinion it’s the end of the TDS era.

Growing of Unicorn (/unicorn.aspx)

Unicorn is a Sitecore utility and it is open source. It solves the issue of moving templates, renderings, and other database items between Sitecore instances. TDS is a monolithic product with commercial support, and marketing does a lot more than just serialization. Unicorn is relatively simple, free and open-source, and does one thing well.

I prefer using Unicorn instead of TDS. Generating the TDS code was not that easy and always needed to take care of the partial class, unnecessary field generation, etc. We can set up the template class following the helix principals.

For more details about the setup, Here is my blog post – Sitecore – Unicorn setup, patterns and tips.

In my opinion Sitecore content serialization would be a replacement of Unicorn.

Sitecore Content Serialization – Future with Sitecore 10 and current focus

SCS will do the out-of-the-box item serialization that lets you automate the synchronization of item changes. It has two options one is using the command-line interface (CLI) and the second Sitecore for Visual Studio (SVS)

Note – for using SVS it’s required to get the license and TDS and SVS are both offered under the same license.

Basic Settings and configurations

Out of the box there are three options to serialize content, The default serialization format (.Item)

  • Manually serialize, update, and revert items in the Content Editor.
  • Use Sitecore event handlers to automatically serialize items.
  • Use the Sitecore service page to serialize, update, and revert a whole database.

Item format

YAML format – using Unicorn and Sitecore content serialization.

This article is the first part to explain the basics of serialization, in the next Part 2- Compare SCS with Unicorn, I will explain the difference between Unicorn vs SCS setup.

I hope this article will help you to understand the basic concept of serialization.

Sitecore Power with ASP.NET Core and why it’s important.

Posted by on in Sitecore, Sitecore 10Leave a comment

Sitecore has recently introduced a development SDK with ASP.NET Core. In this blog, I will explain why it’s super important for the Business to start thinking about it and how it will change the way of Sitecore development.

In my view, technology is an essential part of running a successful business, and it keeps changing for a better purpose. It’s tough for the Business to make the right decision to choose the right technology and plan for the investment as there are a lot of factors involved like cost, technology choice, stability, future, support, extension, security, machine learning, AI, robotics etc.

Off Couse, every Business would prefer to make a one-time investment and to reuse that investment to cater to any new technology.

Is it possible today to make a one-time investment? I think it’s not, but a company like Microsoft and Sitecore they have been putting all efforts to make it happen and the release of Sitecore with ASP.NET core SDK is a big step towards that dream. In my opinion, The secret of success is to make the right choice at the right time, and don’t devote all energy in fixing the old guys.

Before getting into more details, Let’s understand the key part of the puzzle..

Why Sitecore with ASP.NET Core is so important?

Microsoft has started moving all the focus from the previous development framework (.NET Framework) to .NET Core, Why?, Okay, because .NET Framework 4.8, which was announced on 18th April 2019 will be the last major version of .NET Framework. The visual studio which is the primary IDE for the most of the development is itself is built-in .NET Framework, Although Microsoft will continue to provide the support, as I said in my first few lines, It’s a matter of making the right decision at the right time. below are some key features and needs for the changes.

  • Cross-platform & container support
  • High performance
  • Asynchronous via async/await
  • Unified MVC & Web API frameworks
  • Multiple environments and development mode
  • Dependency Injection
  • WebSockets & SignalR and  Cross-Site Request Forgery (CSRF) Protection
  • “Self hosted” Web Applications
  • Globalization and Localization
  • Swagger OpenAPI built in

Sitecore – ASP.NET Core rendering SDK enables SItecore headless development with ASP.NET core. This rendering SDK is in addition to the already existing Javascript Service rendering SDKs of React, Angular, Vue and JavaScript libraries. below is the flow diagram and it makes Sitecore solutions faster and easier to develop, maintain, scale, and upgrade by splitting them up into a Sitecore backend and a ASP.NET rendering host frontend. And we can build rendering hosts with the Sitecore ASP.NET Rendering SDK. That’s a fantastic option. here is a high level flow diagram.

Microsoft has already planned roadmap until 2023 releases, so this shows how important it’s that Sitecore goes with the .Net Core platform.

Source – https://dotnet.microsoft.com/platform/support/policy/dotnet-core

The most important part is, there are a lot of front end technology like Angular, React, Vue.jS, Flutter, Microsoft has launched the new platform called Blazor which will allow C# developer (Sitecore technology) stack to write the web interactive UI through the same language, WOW that’s really amazing, Microsoft has already unified the infrastructure with Azure Cloud provider, development technology with .Net Standard and front end technology through Blazor, so now to develop any complex code that includes Azure, backed like Machine learning , AU and front end all can be done through the same technology and Sitecore has release official SDK for that, so that’s the reason is very important for the business as well as for the development.

Let’s talk about the development and architecture

There are two main parts, One is rendering host front end and second is Sitecore instance backend.

  • Rendering Host – The rendering host front end is a web app made up of the Sitecore ASP.NET Rendering SDK code and static resources. The job of the rendering host is to respond to visitor requests.
  • The Sitecore instance– exposes a set of endpoints like web based native rendering hosts or third party integration
Source – https://doc.sitecore.com/developers/100/developer-tools/en/sitecore-headless-development.html

1. Setting up the sample project-

Below are the prerequisites for the installation.

Follow these steps in case of any error, Please see the reference in Troubleshooting section in the below page.

Below are simple command to setup the local environment.

dotnet new -i Sitecore.DevEx.Templates --nuget-source https://sitecore.myget.org/F/sc-packages/api/v3/index.json (Install template)

dotnet new sitecore.aspnet.gettingstarted -n MyProject (Create a new project)

.\init.ps1 -InitEnv -LicenseXmlPath "<path to your license.xml file>" -AdminPassword "<your Sitecore administrator password>“  (Prepare the container)

.\up.ps1 – (Download the Sitecore Docker images and install the containers)
Docker-compose up –d and Docker ps -a

Once you follow above steps, You should be able to see the working Sitecore instance running inside docker with ASP.NET core.

2. Below are the steps to setup the JSON rendering.

Setup the template in the project and add the standard value, As example below, Ref – https://doc.sitecore.com/developers/100/developer-tools/en/walkthrough–creating-a-simple-rendering-with-a-data-source.html

Add JSON rendering and placeholder settings As mention below.

Add a new component in the solution, A new model, View and register it.

Verify Traefik

  1. Reverse proxy
  2. Traefik provides the friendly URL for each of the instances.
  3. Low configuration setup.
  4. SSL termination

Benefit of using ASP.NET core with Sitecore.

  • Super fast.
  • Fully integrated with Visual Studio.
  • Sitecore headless development is based on ASP.NET Core, there are also fewer problems when doing the native integration

Below features are not supported.

  • Horizon
  • Edit frames
  • Sitecore Forms
  • Invocation of xConnect events, goals and outcomes from c#
  • Managed Cloud Standard and Managed Cloud Premium do not currently offer headless topologies for rendering hosts.

Helper

Set-ExecutionPolicy -Scope Process -ExecutionPolicy Bypass

Troubleshooting

  • First issue while the setup was ‘Invoke-WebRequest’ is not recognized as an internal or external command

Root cause analysis and Solution.

Need to update the default shell to PowerShell for dotnetsdk –

C:\Projects\RenderingSDK\MyProject\docker\build\dotnetsdk\Dockerfile

SHELL ["powershell", "-Command", "$ErrorActionPreference = 'Stop'; $ProgressPreference = 'SilentlyContinue';"]
  • C:\Program Files\dotnet\sdk\5.0.100\Sdks\Microsoft.NET.Sdk\targets\Microsoft.PackageDependencyResolution.targets(241,5): error NETSDK1005: Assets file ‘C:\build\src\rendering\obj\project.assets.json’ doesn’t have a target for ‘netcoreapp3.1’. Ensure that restore has run and that you have included ‘netcoreapp3.1’ in the TargetFrameworks for your project. [C:\build\src\rendering\renderinghost.csproj]

Initially, I thought it’s related to version, As I had installed both dotnetcore SDK 3.1 and 5.0, but finally had to update above command.

Extension – In case if need any extension like xConnect events and to trigger a goals, there are always a way, We can Instantiate client in a non-Sitecore context, Reference Link and can add interaction like to trigger a goal

Finally, A few development tips.

  • How to check the files running inside the containers through the VIsual Studio.
  • Dotnet Sitecore Help command
 dotnet sitecore --help
  • Sitecore login command
  dotnet sitecore login
  • Push the serialized items command – SCS (Sitecore content serialization)
 dotnet sitecore ser push
  • SCS (Sitecore content serialization) Publish command
 dotnet sitecore publish

Git link for the ASP.NET core Helix 

https://github.com/Sitecore/Helix.Examples/tree/master/examples/helix-basic-aspnetcore

I hope this will help to start the development with ASP.NET core with Sitecore 10

Video reference –

I have also presented in Sitecore User Group Pune – Nov 2020 and explain these details.

Chapter 4: Deploy Sitecore into Kubernetes (AWS EKS)

Posted by on in Sitecore 10Leave a comment

Sitecore now has official support of deployments into kubernetes. This is a guide of what’s involved in deploying Sitecore into kubernetes (Tested with AWS). Download the Sitecore container deployment and extract the relevant (xp / XM) configuration files to a working folder.

Prepare certificates

Prepare the certificate (.crt) and private key (.key) files for content management, Content Delivery and Identity Server roles and copy them into the relevant folders as per below screenshot.

Mutli-Site configuration

If you have a multi site implementation you might need to create a separate folder for each domain name under the tls folder and copy the relevant cert and key files and update the Kustomization.yaml

Update the ingress configuration (ingress.yaml) with the domain names to content delivery as per below

Prepare and deploy secrets

  1. Update the database passwords in secrets folder text files and change the usernames if you have modified the database usernames.
  2. Generate 64 character keys for telerik encryption, identity secret and reporting api key and update the relevant text files
  3. Create a x509 certificate for identity server to be used for signing credentials and update the identity certificate and password text files. (sample)
  4. Update the license text file with base64 encoded string of the license file (sample)

Once the secret files are all prepared, run the following command to push the secrets into kubernetes environment.

kubectl apply -k ./secrets

Deploy external services (optional)

There is a option to use services like SOLR, Redis and SQL in containers for a non-prod environment. It is not recommended/supported to use these in a production environment. To deploy these external services run the following command

kubectl apply -f ./external/

Wait for the new pods to be in Running status. Use kubectl get pods -o wide -A to check the status of the external pods.

We would need to deploy the initialization jobs to finish setting up the SOLR and SQL pods. The default job configurtaion files provided by sitecore are missing the node selectors, so there is a chance that these jobs end up on linux nodes and fail or get stuck on ContainerCreating status. Add the below snippet just above imagePullSecrets under spec into both solr and mssql init job YAML files (in ./init folder)

      nodeSelector:
        kubernetes.io/os: windows

Run the following command to deploy the init jobs into the cluster.

kubectl apply -f ./init/

Wait for the jobs to return a Completed status, Use the get pods status command used previously.

Deploy Sitecore and Ingress configuration

To deploy sitecore and the nginx ingress configuration run the following command

kubectl apply -f ./ -f ./ingress-nginx/ingress.yaml

Wait for the deployments to be completed and all pods to return either a Running or a Completed status and Sitecore should now be ready.

Check out the other related posts:

Sitecore on AWS Kubernetes (EKS)

Chapter 1: Configure AWS and Kubernetes CLI

Chapter 2: AWS Kubernetes Cluster for windows workloads

Chapter 3: Deploy nginx ingress controller into AWS EKS Cluster

Chapter 3: Deploy nginx ingress controller into AWS EKS Cluster

Posted by on in Sitecore 10Leave a comment

Ingress controller is used in kubernetes to direct external traffic to the relevant containers/pods running in the cluster. nginx is a very common and popular ingress controller used with kubernetes. This article guides through the steps involved in deploying nginx ingress controller.

Install helm

helm is one of the popular ways of managing deployments into kubernetes environments. Use the below chocolatey command to install helm.

choco install kubernetes-helm -y

Register Repositories to helm

Add the default repository to helm using below command.

helm repo add stable https://kubernetes-charts.storage.googleapis.com/

Add the bitnami repository to helm using the below command

helm repo add bitnami https://charts.bitnami.com/bitnami

Once the above repos are added to helm. Search for nginx using the below command to ensure that we have pulled the latest nginx charts into the repository. Use the below command to search

helm search repo nginx

Deploy nginx ingress controller

Run the following command to install bitnami nginx controller on to the default linux nodes in the cluster.

helm install <deployment-name> bitnami/nginx-ingress-controller `
--set replicaCount=1 `
--set nodeSelector."beta\.kubernetes\.io/os"=linux `
--set defaultBackend.nodeSelector."beta\.kubernetes\.io/os"=linux `
--set-string controller.config.proxy-body-size=10m `
--set service.externalTrafficPolicy=Local `

Retrieve external ip for DNS

Run the following command to check the status of the ingress controller apps deployed into the cluster. Wait until the status changes to Running.

kubectl get pods -o wide -A

Run the below command to get the external ip of the ingress controller in the cluster. This returns a cname which can be used for managing the DNS entries going into the applications running in the cluster.

kubectl --namespace default get services -o wide -w bitnami-ingress-nginx-ingress-controller

Note: If you are working with a dummy DNS names you can perform a nslookup on the CNAME and extract the IP Address to add them to your local hosts file with the relevant host names.

Check out the other related posts:

Sitecore on AWS Kubernetes (EKS)

Chapter 1: Configure AWS and Kubernetes CLI

Chapter 2: AWS Kubernetes Cluster for windows workloads

Chapter 4: Deploy Sitecore into Kubernetes

Chapter 2: AWS Kubernetes Cluster for windows workloads

Posted by on in Sitecore 101 Comment

AWS has been supporting windows workloads in kubernetes since march 2019. The default cluster created only supports linux workloads, this article is a detailed account of how to create a kubernetes cluster in AWS for windows workloads.

Create Cluster

Create a new EKS cluster using the below command. This command creates the default nodes that have to be linux. These nodes host the default applications (pods) that manage the orchestration of kubernetes. Please ensure to update <Cluster-Name> and <Node-Group-Name> and adust the number of nodes accordingly. Its a good practice to have at least 2 nodes to ensure the high availability.

eksctl create cluster `
--name <Cluster-Name> `
--version 1.17 `
--nodegroup-name <Node-Group-Name> `
--node-type t3.medium `
--nodes 2 `
--nodes-min 1 `
--nodes-max 3 `
--node-ami auto

Export Kube config

Run the following command to export the kubernetes cluster configuration into the user profile so the context is set for kubectl

aws eks --region ap-southeast-2 update-kubeconfig --name <cluster name>

Ensure that all the default pods are in running state using the below command.

kubectl get pods -o wide -A

Install VPC controller

Install vpc controller to support windows nodes in the cluster using the below command.

eksctl utils install-vpc-controllers --cluster <Cluster-Name> --approve

Run the get pods command again to see the VPC controller pods running as per below and wait until all the pods are in Running status.

Create windows nodes

Create a node group with windows nodes to support windows workloads using the below command. Please update the <Cluster-Name> and <Node-Group-Name>. Adjust the number of nodes according to the need.

eksctl create nodegroup `
--region ap-southeast-2 `
--cluster <Cluster-Name> `
--version 1.17 `
--name <Node-Group-Name> `
--node-type t3.large `
--nodes 2 `
--nodes-min 1 `
--nodes-max 3 `
--node-ami-family WindowsServer2019FullContainer `
--node-ami auto `

Check the status of all the nodes running correctly using the below command

kubectl get nodes -L kubernetes.io/os `
--sort-by=".status.conditions[?(@.reason == 'KubeletReady' )].lastTransitionTime" `

Check out the other related posts:

Sitecore on AWS Kubernetes (EKS)

Chapter 1: Configure AWS and Kubernetes CLI

Chapter 3: Deploy nginx ingress controller into AWS EKS Cluster

Chapter 4: Deploy Sitecore into Kubernetes

Chapter 1: Configure AWS and Kubernetes CLI

Posted by on in Sitecore 102 Comments

AWS supports kubernetes workloads for windows through EKS and also supports use of command line interface for deploying and configuring resources. Using CLI makes it easy for automating this process through a CI/CD pipeline when required. This article guides through the configuration of CLI for AWS and Kubernetes.

Install and configure AWS CLI

Install AWS CLI using chocolatey

choco install awscli -y

Once successfully installed run aws --version to check if the cli is correctly installed.

Configure AWS CLI with the relevant access key for CLI. This can be generated using the My Security Credentials page through AWS Console. (detailed instructions)

Use the below command to start configuring the CLI

aws configure

Install CLI for EKS

eksctl is the command line utility used for managing the EKS cluster. Use below chocolatey command to install eksctl

choco install eksctl -y

Once successfully installed run eksctl version to verify the version (see below)

Note: eksctl seemed to only use default profile. If you are using named profile for aws cli. this will always use default profile. Hopefully in the newer versions of the cli this will be addressed by AWS.

Install CLI for kubernetes

Install kubectl using chocolatey using the below command

choco install kubernetes-cli -y

Check out the other related posts:

Sitecore on AWS Kubernetes (EKS)

Chapter 2: AWS Kubernetes Cluster for windows workloads

Chapter 3: Deploy nginx ingress controller into AWS EKS Cluster

Chapter 4: Deploy Sitecore into Kubernetes

Sitecore on AWS Kubernetes (EKS)

Posted by on in Sitecore 103 Comments

Sitecore with release of version 10 now officially supports deployments into container workloads using kubernetes. Sitecore has officially marked PaaS would be deprecated in the future releases (more details). This article is about how to deploy Sitecore 10 into AWS kubernetes (EKS). This article is broken down into four chapters as per below with a brief summary.

1. Configure AWS and Kubernetes CLI

AWS command line interface could be used to create or manage resources in AWS. This chapter guides through the installation and configuration of AWS CLI and Kubernetes CLI. Click here to start configuring your CLI.

2. Create AWS Kubernetes Cluster

A Kubernetes cluster needs to be provisioned to deploy Sitecore workloads. This chapter guides through the creation and configuration of AWS EKS Cluster. Click here to start provisioning the cluster.

3. Deploy ingress controller into EKS Cluster

An ingress controller is used to create external access to the applications deployed into the Kubernetes cluster. This chapter guides through the preparation and deployment of ingress controller. Click here to start deploying the ingress controller.

4. Deploy Sitecore into AWS EKS

This is the last chapter that guides through the preparation of the configuration files and deploying Sitecore into kubernetes cluster. Click here to start deploying Sitecore.

Credits

Credit to Gurpreet (Garry) Singh & Jason Umiker for sharing their knowledge and expertise on AWS EKS.