ADDITIONAL VALUES REQUIRED FOR THIS STEP

• aws_winpassword
• aws_winuser

The aws_winpassword and aws_winuser values set the admin credentials for any Windows Server containers created on the cluster and must meet Windows Server password requirements. If you don’t specify the windows-admin-password parameter, you will be prompted to provide a value.

Example: aws_winpassword=P@ssw0rd1234567!

Example: aws_winuser=azureuser

• cluster

  You can name your cluster as you wish, keeping in mind the naming conventions described in [registering the application] (#register-application). Failure to adhere to this convention will lead to an error such as this when the $CLUSTER parameter is used to name a DNS domain:

  *a DNS-1123 subdomain must consist of lower case alphanumeric characters, ‘-’ or ‘.’, and must start and end with an alphanumeric character (e.g. ‘example.com’, regex used for validation is '[a-z0-9]([-a-z0-9]*[a-z0-9])?(\.[a-z0-9]([-a-z0-9]*[a-z0-9])?)*')

  Assign values to aws_winpassword, aws_winuser, and cluster. Once you have those values set, issue the following command:

        
        eksctl create cluster \
            --name $CLUSTER \
            --region $REGION_NAME \
            --without-nodegroup \
            --with-oidc \
            --max-pods-per-node 200  

This command will takes several minutes. When it completes, you will see a message such as:

    2023-01-19 17:59:25 [ℹ]  eksctl version 0.124.0
    2023-01-19 17:59:25 [ℹ]  using region us-east-2
    2023-01-19 17:59:26 [ℹ]  setting availability zones to [us-east-2b us-east-2c us-east-2a]
    2023-01-19 17:59:26 [ℹ]  subnets for us-east-2b - public:192.168.0.0/19 private:192.168.96.0/19
    2023-01-19 17:59:26 [ℹ]  subnets for us-east-2c - public:192.168.32.0/19 private:192.168.128.0/19
    2023-01-19 17:59:26 [ℹ]  subnets for us-east-2a - public:192.168.64.0/19 private:192.168.160.0/19
    2023-01-19 17:59:26 [ℹ]  using Kubernetes version 1.24
    2023-01-19 17:59:26 [ℹ]  creating EKS cluster "mmscluster" in "us-east-2" region with
    2023-01-19 17:59:26 [ℹ]  if you encounter any issues, check CloudFormation console or try 'eksctl utils describe-stacks --region=us-east-2 --cluster=mmscluster'
    2023-01-19 17:59:26 [ℹ]  Kubernetes API endpoint access will use default of {publicAccess=true, privateAccess=false} for cluster "mmscluster" in "us-east-2"
    2023-01-19 17:59:26 [ℹ]  CloudWatch logging will not be enabled for cluster "mmscluster" in "us-east-2"
    2023-01-19 17:59:26 [ℹ]  you can enable it with 'eksctl utils update-cluster-logging --enable-types={SPECIFY-YOUR-LOG-TYPES-HERE (e.g. all)} --region=us-east-2 --cluster=mmscluster'
    2023-01-19 17:59:26 [ℹ]
    2 sequential tasks: { create cluster control plane "mmscluster",
        4 sequential sub-tasks: {
            wait for control plane to become ready,
            associate IAM OIDC provider,
            2 sequential sub-tasks: {
                create IAM role for serviceaccount "kube-system/aws-node",
                create serviceaccount "kube-system/aws-node",
            },
            restart daemonset "kube-system/aws-node",
        }
    }
    2023-01-19 17:59:26 [ℹ]  building cluster stack "eksctl-mmscluster-cluster"
    2023-01-19 17:59:29 [ℹ]  deploying stack "eksctl-mmscluster-cluster"
    2023-01-19 17:59:59 [ℹ]  waiting for CloudFormation stack "eksctl-mmscluster-cluster"
    2023-01-19 18:00:34 [ℹ]  waiting for CloudFormation stack "eksctl-mmscluster-cluster"
    2023-01-19 18:01:36 [ℹ]  waiting for CloudFormation stack "eksctl-mmscluster-cluster"
    2023-01-19 18:02:37 [ℹ]  waiting for CloudFormation stack "eksctl-mmscluster-cluster"
    2023-01-19 18:03:39 [ℹ]  waiting for CloudFormation stack "eksctl-mmscluster-cluster"
    2023-01-19 18:06:35 [ℹ]  waiting for CloudFormation stack "eksctl-mmscluster-cluster"
    2023-01-19 18:07:37 [ℹ]  waiting for CloudFormation stack "eksctl-mmscluster-cluster"
    2023-01-19 18:08:40 [ℹ]  waiting for CloudFormation stack "eksctl-mmscluster-cluster"
    2023-01-19 18:09:41 [ℹ]  waiting for CloudFormation stack "eksctl-mmscluster-cluster"
    2023-01-19 18:11:53 [ℹ]  building iamserviceaccount stack "eksctl-mmscluster-addon-iamserviceaccount-kube-system-aws-node"
    2023-01-19 18:11:54 [ℹ]  deploying stack "eksctl-mmscluster-addon-iamserviceaccount-kube-system-aws-node"
    2023-01-19 18:11:54 [ℹ]  waiting for CloudFormation stack "eksctl-mmscluster-addon-iamserviceaccount-kube-system-aws-node"
    2023-01-19 18:12:27 [ℹ]  waiting for CloudFormation stack "eksctl-mmscluster-addon-iamserviceaccount-kube-system-aws-node"
    2023-01-19 18:12:27 [ℹ]  serviceaccount "kube-system/aws-node" already exists
    2023-01-19 18:12:28 [ℹ]  updated serviceaccount "kube-system/aws-node"
    2023-01-19 18:12:29 [ℹ]  daemonset "kube-system/aws-node" restarted
    2023-01-19 18:12:29 [ℹ]  waiting for the control plane to become ready
    2023-01-19 18:12:31 [✔]  saved kubeconfig as "C:\\Users\\saushind\\.kube\\config"
    2023-01-19 18:12:31 [ℹ]  no tasks
    2023-01-19 18:12:31 [✔]  all EKS cluster resources for "mmscluster" have been created
    2023-01-19 18:12:43 [ℹ]  kubectl command should work with "C:\\Users\\saushind\\.kube\\config", try 'kubectl get nodes'
    2023-01-19 18:12:43 [✔]  EKS cluster "mmscluster" in "us-east-2" region is ready

VALUES TO BE EXTRACTED FROM THIS STEP

• rolename

ADDITIONAL VALUES REQUIRED FOR THIS STEP

Issue the following command to extract rolename:

    aws iam list-roles | jq -r '.Roles| .[] | .RoleName' | grep eksctl-$CLUSTER-nodegroup

You should see output such as this (Two rolenames will be created if windows node is added else only one rolename for linux):

    eksctl-mmscluster-nodegroup-devm-NodeInstanceRole-1GV0F2NT37D6U
    eksctl-mmscluster-nodegroup-devm-NodeInstanceRole-9OXZ2QBHWDQ

Assign below two IAM Policies to eksctl rolename from the output

Rolename 1:
        aws iam attach-role-policy \
            --policy-arn arn:aws:iam::aws:policy/AmazonEC2ContainerRegistryFullAccess \
            --role-name eksctl-mmscluster-nodegroup-devm-NodeInstanceRole-1GV0F2NT37D6U
        aws iam attach-role-policy \
            --policy-arn arn:aws:iam::aws:policy/AmazonElasticContainerRegistryPublicFullAccess \
            --role-name eksctl-mmscluster-nodegroup-devm-NodeInstanceRole-1GV0F2NT37D6U
Rolename 2:
        aws iam attach-role-policy --policy-arn arn:aws:iam::aws:policy/AmazonEC2ContainerRegistryFullAccess \
            --role-name eksctl-mmscluster-nodegroup-devm-NodeInstanceRole-1GV0F2NT37D6U
        aws iam attach-role-policy --policy-arn arn:aws:iam::aws:policy/AmazonElasticContainerRegistryPublicFullAccess \
            --role-name eksctl-mmscluster-nodegroup-devm-NodeInstanceRole-9OXZ2QBHWDQ

VALUES TO BE EXTRACTED FROM THIS STEP

• windowsnode

ADDITIONAL VALUES REQUIRED FOR THIS STEP

This step is only required when windows nodes are added. Issue the following command to extract windows node name:

    kubectl get nodes -o wide|grep Windows | awk '{print $1}'

You should see output such as this:

    ip-192-168-1-209.us-west-1.compute.internal
    ip-192-168-86-29.us-west-1.compute.internal

Assign Tain to below two windows node:

    kubectl taint nodes ip-192-168-1-209.us-west-1.compute.internal  os=windows:NoSchedule
    kubectl taint nodes ip-192-168-86-29.us-west-1.compute.internal  os=windows:NoSchedule

ADDITIONAL VALUES REQUIRED FOR THIS STEP

• ELASTIC_PW
• GIT_SERVER_PW
• NEXUS_SERVER_PW
• PROMETHEUS_PW
• SCORING_ADMIN_PW
• ARTIFACT_MANAGEMENT_PW
• Oauth2 server details

In order to avoid clear text passwords, Kubernetes provides a Secrets facility. So prior to installation, Kubernetes Secrets have to be created to contain the passwords required by MMS.

Assign each of the names above to some value, then issue the following commands to set up the secrets.

NOTE: without secrets installed, the [helm installation] (#install-helm-chart) step will be in a wait mode and eventually time out.

Clear out any old secrets that may exist with this series of delete secret commands:

    kubectl delete secret git-server --namespace mms
    kubectl delete secret nexus-server --namespace mms
    kubectl delete secret prometheus-server --namespace mms
    kubectl delete secret scoring-admin --namespace mms
    kubectl delete secret oauth2 --namespace mms
    kubectl delete secret artifact-management --namespace mms
    kubectl delete secret artifact-management-env --namespace mms

Create new secrets:

    kubectl create secret generic elasticsearch-es-elastic-user \
        --from-literal=elastic=$ELASTIC_PW \
        --namespace mms --dry-run=client --output=yaml 2>/dev/null > secret.yaml
    kubectl apply --filename secret.yaml
    kubectl create secret generic git-server \
        --from-literal=streaming-web=$GIT_SERVER_PW \
        --namespace mms
    kubectl create secret generic nexus-server \
        --from-literal=admin=$NEXUS_SERVER_PW \
        --namespace mms
    kubectl create secret generic prometheus-server \
        --from-literal=admin=$PROMETHEUS_PW \
        --namespace mms
    kubectl create secret generic scoring-admin \
        --from-literal=admin=$SCORING_ADMIN_PW \
        --namespace mms
    kubectl create secret generic artifact-management \
        --from-literal=admin=$ARTIFACT_MANAGEMENT_PW \
        --namespace mms
    kubectl create secret generic artifact-management-env --namespace mms

NOTE: The Elasticsearch password is limited to alphanumeric, “.”, “_”, “~”, and “-” characters, i.e. it must conform to this regular expression (‘^[a-zA-Z0-9._~-]+$’)).

NOTE: The prometheus-server secret is only used if you are not using OAuth2 authentication; if using OAuth2, this secret need not be created. It should consist of name value pairs where each name is a user name, and each value is the corresponding password. These are used to secure the Prometheus ingress with basic authentication.

The oauth2 secret depends on the type of authentication server used.

For Azure, the authentication server administrator should supply the Azure tenant id ($AZURE_TENANT_ID), app id ($AZURE_APP_ID) and client secret ($AZURE_CLIENT_SECRET). The secret is created with:

    kubectl create secret generic oauth2 \
        --from-literal=TENANT_ID=$AZURE_TENANT_ID \
        --from-literal=CLIENT_ID=$AZURE_APP_ID \
        --from-literal=CLIENT_SECRET=$AZURE_CLIENT_SECRET \
        --namespace mms

For Cognito, the authentication server administrator should supply the Cognito region ($COGNITO_REGION), pool id ($COGNITO_POOL_ID), client id ($COGNITO_CLIENT_ID), client secret ($COGNITO_CLIENT_SECRET) and the domain ($COGNITO_DOMAIN). The secret is created with:

    kubectl create secret generic oauth2 \
        --from-literal=REGION=$COGNITO_REGION \
        --from-literal=POOL_ID=$COGNITO_POOL_ID \
        --from-literal=CLIENT_ID=$COGNITO_CLIENT_ID \
        --from-literal=CLIENT_SECRET=$COGNITO_CLIENT_SECRET \
        --from-literal=DOMAIN=$COGNITO_DOMAIN \
        --namespace mms

For Okta, the authentication server administrator should supply the Okta client id ($OKTA_CLIENT_ID), client secret ($OKTA_CLIENT_SECRET), the domain ($OKTA_DOMAIN), and the authorization server id ($OKTA_AUTH_SERVER). The secret is created with:

    kubectl create secret generic oauth2 \
        --from-literal=CLIENT_ID=$OKTA_CLIENT_ID \
        --from-literal=CLIENT_SECRET=$OKTA_CLIENT_SECRET \
        --from-literal=DOMAIN=$OKTA_DOMAIN \
        --from-literal=AUTH_SERVER_ID=$OKTA_AUTH_SERVER \
        --namespace mms

ADDITIONAL VALUES REQUIRED FOR THIS STEP

• hostedzone

  A real-world value would be a domain that you bought from a domain name registrar. Eg: xyzcloud.com

• mms_home

  The directory where MMS is installed on your machine. For instance, on windows, c:\TIBCO\str*n.m*

• name

  This is NOT the display name of the application registered at the beginning of this process. Rather, this is usually set to be the same as $CLUSTER

• domain

Assign to this the combination of existing parameters: $CLUSTER.$DOMAIN

• subdomain

  This is an optional variable where you can specify the desired subdomain name. If it's not defined, the default value will be ‘mms’.

• network_exposure

  Assign to this the string “ingress” (without the quotes)

• oauth2_server_type

  One of azure, cognito, or okta to use an external Oauth2 authentication server.
  Leave blank if no authentication server is required.

• EKS_ROLE_ARN

  ExternalDNS makes Kubernetes resources discoverable via public DNS servers. We need some access added to the cluster.

  IAMpolicy The following IAM Policy document allows ExternalDNS to update Route53 Resource Record Sets and Hosted Zones. You'll want to create this Policy in IAM first. In our example, we'll call the policy AllowExternalDNSUpdates (but you can call it whatever you prefer). If you prefer, you may fine-tune the policy to permit updates only to explicit Hosted Zone ID

  
        {
            "Version": "2012-10-17",
            "Statement": [
                {
                "Effect": "Allow",
                "Action": [
                    "route53:ChangeResourceRecordSets"
                ],
                "Resource": [
                    "arn:aws:route53:::hostedzone/*"
                ]
                },
                {
                "Effect": "Allow",
                "Action": [
                    "route53:ListHostedZones",
                    "route53:ListResourceRecordSets"
                ],
                "Resource": [
                    "*"
                ]
                }
            ]
        }
    

  If you are using the AWS CLI, you can run the following to install the above policy (saved as policy.json). This can be use in subsequent steps to allow ExternalDNS to access Route53 zones.

  
        aws iam create-policy --policy-name "AllowExternalDNSUpdates" --policy-document file://policy.json
        # example: arn:aws:iam::XXXXXXXXXXXX:policy/AllowExternalDNSUpdates
        export POLICY_ARN=$(aws iam list-policies \
            --query 'Policies[?PolicyName==`AllowExternalDNSUpdates`].Arn' --output text)
    

  Create a role with above policy attached to it

  
        $ACCOUNT_ID=$(aws sts get-caller-identity \
                            --query "Account" --output text)
        $OIDC_PROVIDER=$(aws eks describe-cluster --name $EKS_CLUSTER_NAME \
                            --query "cluster.identity.oidc.issuer" --output text | sed -e 's|^https://||')
  
        $cat <<-EOF > trust.json
            {
                "Version": "2012-10-17",
                "Statement": [
                {
                    "Effect": "Allow",
                    "Principal": {
                        "Federated": "arn:aws:iam::$ACCOUNT_ID:oidc-provider/$OIDC_PROVIDER"
                    },
                    "Action": "sts:AssumeRoleWithWebIdentity",
                    "Condition": {
                        "StringEquals": {
                            "$OIDC_PROVIDER:sub": "system:serviceaccount:mms:external-dns",
                            "$OIDC_PROVIDER:aud": "sts.amazonaws.com"
                        }
                    }
                }
                ]
            }
            EOF
  
            IRSA_ROLE="external-dns-irsa-role"
            aws iam create-role --role-name $IRSA_ROLE --assume-role-policy-document file://trust.json
            aws iam attach-role-policy --role-name $IRSA_ROLE --policy-arn $POLICY_ARN
  
    

Enable Oauth2

This file provides instructions for enabling OAuth2 during the installation process. For enabling OAuth2, refer to the Cognito documentation at the following link: Cognito

This section of the documentation provides the callback URL for Microsoft Entra ID. The callback URL is used for OAuth2 authentication.

Example: “fqdn”: “mms-server.lkvaks.streamingaz.tibcocloud.com/oauth2/callback”

Assign each of the names above to an appropriate value, then issue the following command:

    helm upgrade \
        --install mms $MMS_HOME/mms/kubernetes-installer-1.4.0.tgz \
        --atomic \
        --set cloud=eks \
	    --set eks.externalDNS=aws \
	    --set externalDNS.aws.eksRoleArn=$EKS_ROLE_ARN \
        --set eks.containerRegistry=$SHARED_ACCOUNT_ID.dkr.ecr.$REGION_NAME.amazonaws.com \
        --set eks.containerRegistryPrefix=$CONTAINER_PREFIX \
        --set eks.region=$REGION_NAME \
        --namespace mms \
        --set eks.networkExposure=$NETWORK_EXPOSURE \
        --set eks.ingressDomain=$DOMAIN \
        --set eks.ingressSubdomain=$subdomain \
        --set eks.oauth2=$OUTH2_SERVER_TYPE \
        --timeout 10m0s \
        --set eks.awsTokenId=IQoJb3JpZ2luX2VjEKT//////////wEaCXVzLWVhc3QtMiJHasdasdaMEUCIEEvv0raHD7CahCXa95brWPyKBR8gAu7izrMAiEAsrY9sZOizSn81OZTiU0YqCDhsV79h1MdzvBIqBudLhAqngII/f//////////ARADGgwzMDk0OTI2MjM0NjkiDOEHEsy0mtHDwfAkryryAWPZbcONL+ohB7SfdQrQKcAXukkGNOb0OSLESMLL1pIP5GyPkFGKPyCs/A5dFQnJPp96u2ZuhjDerkkqKrWp0CzJHs3+GyEmfjydnbyDsOvpLm10yT1SnvluNZUf9ZgNwkb2++YxUxBIfUeW3hKHM/aDbQ85X8wswpaQ98X0BgdgV1l68PK+qw2u9b/ndzb3T5Mvw0ic063YJt3ZASZCH593+UK/dFfXOiQc4gUmd8QYYbqbpYSjncJSWoWmO/kwzy7GiEs8DVv2f3Bk9TW4BVL6xg6eACYBCrh+eD7AGq1Fxg8KdkIzgu/I67tytr0Jy5s7MIHdqooGOp0BPwISyZc6Zlq7JO5tZQ0tJNQ1eeaQPRgfppB+/+VfYu+qHiS/BZyWsHYZZ7OS50WBNxcWsLP8FhRpmoIsyCXnfWRkOhdizb5noT7F/p+nVvQp/X7F1o7/2ys9J+kZphLfp4A535fKTqkRi9dtQawJryyHgZ4zR891tO2cVAjQo7jRCFhOC3NxgpFxJmRyFvbiEtx2HkhJZr1fSSDIIQ== \
        --set eks.awsSecretAccessKey=GrowYTjtvgrMjpdWrW0wDa5YcpOzQRLaUq2e3/Ry+6csZs4 \
        --set eks.awsAccessKeyID=ASIAUQDZSVBWS5ETW7ET 

The above command will produce a series of warnings, user can ignore those warnings. Then a series of lines of output, including a thank you, and ending with a note for how to track the progress of the installation pipeline. See [monitoring the installation] (#monitor-installation) for more details.

NOTE: If users do not wish to use oauth authentication, remove the –set eks.oauth2=$OUTH2_SERVER_TYPE command while execution.

Delete all completed TaskRuns in the namespace

tkn tr list --namespace mms -o name | sed 's#taskrun.tekton.dev/##' | xargs -I {} tkn tr delete {} --namespace mms -f

Delete all completed jobs in the namespace

kubectl delete jobs --all --namespace mms

If you want to keep some tasks or jobs for debugging purposes, you can use the following command to keep specific TaskRuns & jobs:

List all TaskRuns in the specified namespace, filter out the one to keep, and delete the rest

tkn tr list --namespace mms -o name | sed 's#taskrun.tekton.dev/##' | grep -v -E "$taskrun1_to_keep|taskrun2_to_keep" | xargs -I {} tkn tr delete {} --namespace mms -f

Replace ‘job1-to-keep’ and ‘job2-to-keep’ with the names of the jobs you want to keep

kubectl get jobs --namespace mms -o jsonpath='{.items[*].metadata.name}' | tr ' ' '\n' | grep -v -E '^(job1-to-keep|job2-to-keep)$' | xargs -I {} kubectl delete job --namespace mms {}

VALUES TO BE EXTRACTED FROM THIS STEP

• ingress_lb_ip
• hosted_zone_id

ADDITIONAL VALUES REQUIRED FOR THIS STEP

• Issue the following command to extract ingress_lb_ip:

        kubectl get service/nginx-ingress-ingress-nginx-controller -o jsonpath='{.status.loadBalancer.ingress[0].hostname}' --namespace mms

You should see output such as this:

        a754a322be44b4d68b27eeewwwe103ce583-731052421.us-west-1.elb.amazonaws.com%

Assign the output of the above command to ingress_lb_ip (without % sign) Example: set ingress_lb_ip=a754a322be44b4d68b27eeewwwe103ce583-731052421.us-west-1.elb.amazonaws.com

• Issue the following command to extract hosted_zone_id:

        aws route53 list-hosted-zones-by-name | jq --arg name "${Domain}." -r '.HostedZones | .[] | select(.Name=="\($name)") | .Id'
>

You should see output such as this:

        /hostedzone/Z0415WEWR1C17NACM6JCG

Assign the output of the above command to hosted_zone_id Example: set hosted_zone_id=/hostedzone/Z0415WEWR1C17NACM6JCG

Once ingress_lb_ip and hosted_zone_id parameter is set, modify the record-sets by issuing the following command:

    aws route53 change-resource-record-sets \
            --hosted-zone-id ${hosted_zone_id}  \
            --change-batch '{ "Comment": "Updating a record",
                              "Changes": [ {
                                    "Action": "UPSERT",
                                    "ResourceRecordSet": {
                                        "Name": "mms.'"$domain"'",
                                        "Type": "CNAME",
                                        "TTL": 300,
                                        "ResourceRecords": [ {
                                            "Value": "'"$ingress_lb_ip"'" } ] } } ] }'

You should see output such as this:

        {
           "ChangeInfo": {
            "Id": "/change/C08087523NGIM5VVMOYKU",
            "Status": "PENDING",
            "SubmittedAt": "2021-10-13T13:50:20.565000+00:00",
            "Comment": "Updating a record"
            }
        }

• If Hosted zone is not present then first you have to create it.

        aws route53 create-hosted-zone \
            --name ${domain} \
            --caller-reference $RANDOM \
            --hosted-zone-config \
            Comment="Creating HostedZone"

Issue the following command to extract hosted_zone_id:

        aws route53 list-hosted-zones-by-name | jq --arg name "${Domain}." -r '.HostedZones | .[] | select(.Name=="\($name)") | .Id'

You should see output such as this:

        /hostedzone/Z0415WEWR1C17NACM6JCG

Assign the output of the above command to hosted_zone_id Example: set hosted_zone_id=/hostedzone/Z0415WEWR1C17NACM6JCG

Once your ingress_lb_ip and hosted_zone_id parameter is set, modeify the record-sets by issuing the following command:

         
        aws route53 change-resource-record-sets \
            --hosted-zone-id ${hosted_zone_id}  \
             --change-batch '{ "Comment": "Creating a record",
                              "Changes": [ {
                                    "Action": "CREATE",
                                    "ResourceRecordSet": {
                                        "Name": "mms.'"$domain"'",
                                        "Type": "CNAME",
                                        "TTL": 300,
                                        "ResourceRecords": [ {
                                            "Value": "'"$ingress_lb_ip"'" } ] } } ] }'  

You should see output such as this:

        {
           "ChangeInfo": {
            "Id": "/change/C04087802ADO55OR1VNCN",
            "Status": "PENDING",
            "SubmittedAt": "2021-10-12T07:53:21.930000+00:00",
            "Comment": "Creating a record"
            }
        }

If API v1 integration is required to Team Studio, the mms-1 host should also be added to DNS in a similar way:

        aws route53 change-resource-record-sets \
            --hosted-zone-id ${hosted_zone_id}  \
             --change-batch '{ "Comment": "Creating a record",
                              "Changes": [ {
                                    "Action": "CREATE",
                                    "ResourceRecordSet": {
                                        "Name": "mms-1.'"$domain"'",
                                        "Type": "CNAME",
                                        "TTL": 300,
                                        "ResourceRecords": [ {
                                            "Value": "'"$ingress_lb_ip"'" } ] } } ] }'  

VALUES TO BE EXTRACTED FROM THIS STEP

• rolename

Issue the following command to extract rolename:

    aws iam list-roles | jq -r '.Roles| .[] | .RoleName' | grep eksctl-$CLUSTER-nodegroup

You should see output such as this (Two rolenames will be displayed if windows node is added else only one rolename for linux):

    eksctl-devmms-nodegroup-devm-NodeInstanceRole-1GV0F2NT37D6U
    eksctl-devmms-nodegroup-devm-NodeInstanceRole-9OXZ2QBHWDQ

Detach below two IAM Policies from eksctl rolename

    Rolename 1:
        aws iam detach-role-policy \
            --policy-arn arn:aws:iam::aws:policy/AmazonEC2ContainerRegistryFullAccess \
            --role-name eksctl-devmms-nodegroup-devm-NodeInstanceRole-1GV0F2NT37D6U
aws iam detach-role-policy \
            --policy-arn arn:aws:iam::aws:policy/AmazonElasticContainerRegistryPublicFullAccess \
            --role-name eksctl-devmms-nodegroup-devm-NodeInstanceRole-1GV0F2NT37D6U
Rolename 2:
        aws iam detach-role-policy --policy-arn arn:aws:iam::aws:policy/AmazonEC2ContainerRegistryFullAccess \
            --role-name eksctl-devmms-nodegroup-devm-NodeInstanceRole-1GV0F2NT37D6U
aws iam detach-role-policy --policy-arn arn:aws:iam::aws:policy/AmazonElasticContainerRegistryPublicFullAccess \
            --role-name eksctl-devmms-nodegroup-devm-NodeInstanceRole-9OXZ2QBHWDQ

To delete the Cluster resources issue the following commands:

    eksctl delete cluster \
        --name $CLUSTER  \
        --region $REGION_NAME \
        --wait \
        --force