Bala's Blog
Building a Three-Tier E-commerce Project (ROBOT-SHOP)

Building a Three-Tier E-commerce Project (ROBOT-SHOP)

Bala's photo
Bala
·

9 min read

This project, aptly named "Robot Shop," offers a hands-on experience of an e-commerce platform specializing in robots and artificial intelligence products.

Developed using a variety of programming languages, each microservice contributes to the project's seamless functionality. Behind the scenes, the project employs several databases, including RabbitMQ and Redis for in-memory data storage. The result is a well-orchestrated symphony of services, providing insights into building scalable and maintainable architectures.

As you explore the functionalities of this demo project, you'll find parallels with real-world e-commerce applications. Navigate through the catalog, examine product details, check ratings, and make purchases with an intuitive user interface reminiscent of popular online marketplaces. The absence of a registration page simplifies the login process, allowing users to seamlessly access the platform.

Journey through the purchasing process, from adding items to the cart to calculating shipping costs based on your region. Experience a simulated checkout, complete with order confirmation and the option to integrate with a payment gateway. While the demo project does not currently feature a payment integration, it provides a glimpse into the possibilities.

Prerequisites:

Here are the prerequisites to set up your environment and kickstart your journey:

  1. kubectl – Kubernetes Command Line Tool:

    • Install or update kubectl to interact seamlessly with Kubernetes clusters. Detailed instructions can be found here.

  2. eksctl – EKS Command Line Tool:

    • Streamline your tasks with eksctl, the command line tool for working effortlessly with EKS clusters. Automate your workflow and simplify cluster management by referring to the installation guide here.

  3. AWS CLI – Command Line Interface for AWS:

    • Set up the AWS Command Line Interface (AWS CLI) to work seamlessly with AWS services, including Amazon EKS. Installation instructions are available here in the AWS Command Line Interface User Guide.

  4. Configure AWS CLI:

    • After installing AWS CLI, enhance your experience by configuring it. Follow the steps outlined in the Quick configuration with aws configure section of the AWS Command Line Interface User Guide.

EKS Cluster Setup:

Before we dive into the installation process, ensure you've covered the prerequisites mentioned in the documentation. Once you've confirmed that, follow these steps to install and create your EKS cluster using ekctl:

  1. Install EKS:

    • Make sure you've completed the prerequisites documentation before proceeding.

  2. Installation Using eksctl:

    • Open your terminal and run the following command to create your EKS cluster:

        eksctl create cluster --name demo-cluster-three-tier-1 --region ap-south-1

    • This command utilizes eksctl, the EKS command line tool, to automate the creation of your cluster named demo-cluster-three-tier-1 in the AP South 1 (Mumbai) region.

  3. Cluster Creation Complete:

    • Once the process completes, you'll have a fully functional EKS cluster ready to power your containerized applications.

    • Your EKS cluster is now installed and configured. Whether you're a Kubernetes enthusiast or exploring container orchestration for the first time, you're ready to leverage the power of EKS for your containerized applications.

OIDC IAM Setup:

Configuring the IAM OIDC provider is a crucial step when working with Amazon EKS. It establishes a link between your EKS cluster and AWS Identity and Access Management (IAM), enabling seamless integration and secure authentication for your cluster.

  1. Export Cluster Name:

    • Begin by exporting your EKS cluster name as an environment variable.

        export cluster_name=<CLUSTER-NAME>

  2. Retrieve OIDC Issuer URL:

    • Obtain the OIDC issuer URL for your EKS cluster.

        oidc_id=$(aws eks describe-cluster --name $cluster_name --query "cluster.identity.oidc.issuer" --output text | cut -d '/' -f 5)

  3. Check Existing OIDC Providers:

    • Verify if there's already an IAM OIDC provider configured for your cluster.

        aws iam list-open-id-connect-providers | grep $oidc_id | cut -d "/" -f4

  4. Configure IAM OIDC Provider (if not configured):

    • If no OIDC provider is found, run the following command to associate IAM with your EKS cluster.

        eksctl utils associate-iam-oidc-provider --cluster $cluster_name --approve

    • This command establishes the IAM OIDC provider, enabling AWS services like IAM roles for service accounts (IRSA) to work seamlessly with your EKS cluster.

ALB Configuration:

The AWS Load Balancer Controller (ALB Controller) is a critical component when it comes to managing and configuring Application Load Balancers (ALBs) on Amazon EKS. It simplifies the process of deploying and managing load balancers for your Kubernetes services, providing dynamic and automatic scaling capabilities.

Step-by-Step Setup Guide:

  1. Download IAM Policy:

    • Begin by downloading the IAM policy required for the ALB Controller.

        curl -O https://raw.githubusercontent.com/kubernetes-sigs/aws-load-balancer-controller/v2.5.4/docs/install/iam_policy.json

  2. Create IAM Policy:

    • Create the IAM policy using the downloaded JSON file.

        aws iam create-policy \
      --policy-name AWSLoadBalancerControllerIAMPolicy \
      --policy-document file://iam_policy.json

  3. Create IAM Role:

    • Set up the IAM role for the ALB Controller, attaching the policy created in the previous step.

        eksctl create iamserviceaccount \
    --cluster=<your-cluster-name> \
    --namespace=kube-system \
    --name=aws-load-balancer-controller \
    --role-name AmazonEKSLoadBalancerControllerRole \
    --attach-policy-arn=arn:aws:iam::<your-aws-account-id>:policy/AWSLoadBalancerControllerIAMPolicy \
    --approve

  4. Deploy ALB Controller:

    • Use Helm to deploy the AWS Load Balancer Controller. Start by adding the EKS Helm repo.

        helm repo add eks https://aws.github.io/eks-charts

    • Update the Helm repo to ensure you have the latest charts.

        helm repo update eks

    • Finally, install the AWS Load Balancer Controller, ensuring you provide necessary configuration details such as your cluster name, AWS region, and VPC ID.

        helm install aws-load-balancer-controller eks/aws-load-balancer-controller \            
    -n kube-system \
    --set clusterName=<your-cluster-name> \
    --set serviceAccount.create=false \
    --set serviceAccount.name=aws-load-balancer-controller \
    --set region=<region> \
    --set vpcId=<your-vpc-id>

  5. Verification:

    • Confirm that the deployments are running successfully by checking the AWS Load Balancer Controller deployment in the kube-system namespace.

        bashCopy codekubectl get deployment -n kube-system aws-load-balancer-controller

Why EC2 instead of FARGATE?

Fargate lacks support for Redis and EBS volumes, critical components in our infrastructure. Embracing EKS with EC2 ensures compatibility, enabling seamless integration of Redis and harnessing the benefits of EBS volumes for persistent storage. This strategic shift aligns our container orchestration with the specific needs of our applications, balancing simplicity and robust capabilities. 🚀🔗

Hence we are using EKS with EC2 instead of Fargate.

Redis, being a go-to in-memory data store, often requires persistence, driving its deployment as a StatefulSet.

Here's the breakdown:

  1. Persistent Volume and Storage Class:

    • Redis deployment involves the orchestration of two key components: the persistent volume and the storage class. These elements form the backbone of Redis StatefulSets, ensuring data persistence and reliability.

  2. EBS as a Persistent Volume:

    • Traditionally, EBS (Elastic Block Store) serves as a popular choice for persistent volumes in Redis deployments. Its robust capabilities make it an ideal companion for storing and persisting the stateful data managed by Redis.

  3. Automated Volume Management with EBS CSI:

    • Achieving seamless automation in volume management requires the incorporation of the EBS CSI (Container Storage Interface) plugin. By integrating this plugin into your EKS (Elastic Kubernetes Service) cluster, a symbiotic relationship between the storage class and persistent volume claim (PVC) is established.

  4. EBS CSI Plugin: The Catalyst for Automation:

    • The EBS CSI plugin acts as the catalyst for automation in Redis deployments. It ensures that when a PVC is created, an EBS volume is automatically provisioned and seamlessly attached to the Redis StatefulSet. This automation simplifies the management of persistent volumes, streamlining the entire process.

  5. Deployment Considerations:

    • To fully leverage the benefits of automated volume management, it is imperative to deploy the EBS CSI plugin within your EKS cluster. This deployment sets the stage for a dynamic and efficient interaction between Redis, persistent volumes, and EBS storage.

EBS-CSI DRIVER:

To enable the Amazon EBS CSI plugin and empower it with the necessary IAM permissions, follow these steps for a smooth configuration within your EKS cluster.

  1. Create IAM Role and Attach Policy:

    • Begin by creating an IAM role specifically for the EBS CSI plugin, and attach the required policy. This policy grants the essential permissions for the plugin to interact with AWS APIs on your behalf.

        eksctl create iamserviceaccount \
    --name ebs-csi-controller-sa \
    --namespace kube-system \
    --cluster <YOUR-CLUSTER-NAME> \
    --role-name AmazonEKS_EBS_CSI_DriverRole \
    --role-only \
    --attach-policy-arn arn:aws:iam::aws:policy/service-role/AmazonEBSCSIDriverPolicy \
    --approve

    • Replace <YOUR-CLUSTER-NAME> with the name of your EKS cluster.

  2. Deploy EBS CSI Plugin via CloudFormation:

    • Deploy the AWS CloudFormation stack that creates the IAM role and attaches the specified IAM policy. Execute the following command:

        eksctl create addon --name aws-ebs-csi-driver --cluster <YOUR-CLUSTER-NAME> --service-account-role-arn arn:aws:iam::<AWS-ACCOUNT-ID>:role/AmazonEKS_EBS_CSI_DriverRole --force

    • Replace <YOUR-CLUSTER-NAME> with your EKS cluster name and <AWS-ACCOUNT-ID> with your AWS account ID.

  3. Verification:

    • Ensure that the EBS CSI plugin is successfully deployed by checking the status of the addon:

        kubectl get daemonset ebs-csi-controller -n kube-system

    • This command confirms that the EBS CSI controller is up and running, ready to facilitate automated volume management for your EKS cluster.

Deploying Robot Shop Project with Helm Chart

To streamline the deployment of the Robot Shop project, we leverage Helm, Kubernetes' package manager. This allows us to encapsulate and manage all the Kubernetes resources efficiently.

1. Create Namespace for Robot Shop:

kubectl create ns robot-shop

2. Install Helm Chart:

helm install robot-shop --namespace robot-shop .

Executing this command deploys the entire Robot Shop project, utilizing the Helm chart to manage each component seamlessly.

3. Helm Chart Configuration: All Kubernetes resources for the project are organized in the templates folder, with values managed through the values.yaml file. This structured approach facilitates easy management and customization.

4. Choose Exposition Method: Two options exist for exposing the application externally: through a Load Balancer or via an Ingress Controller. Since an Ingress Controller is already set up, we opt for this method.

5. Apply Ingress Configuration:

kubectl apply -f ingress.yaml

This command applies the Ingress resource configuration, allowing external access to the Robot Shop application.

6. Check Ingress Status:

kubectl get ingress -n robot-shop

After applying the Ingress resource, it is assigned an address. However, please note that the Load Balancer may still be in the provisioning state. Access to the application will be available once the Load Balancer status is active.

6. Check Pods status:

kubectl get pods -n robot-shop

6. Check Load Balancer status:

Now the load balancer status has turned from provisioning to active, which means our application is ready to be accessed.

By following these steps, the Robot Shop project is efficiently deployed using Helm, with flexible options for external access via an Ingress Controller.

Monitoring the Ingress status provides visibility into the readiness of the application for external access.

Conclusion:

As we conclude our exploration of the Robot Shop project deployment, we've witnessed the power of Helm charts and Kubernetes in orchestrating a complex, microservices-based application. The Robot Shop project serves as a dynamic playground for honing your skills in Kubernetes, Helm, and beyond.

If you found this journey insightful and empowering, don't forget to hit the "like" button and share it with your fellow enthusiasts. Let the knowledge flow, and may your Kubernetes endeavors be as smooth as orchestrating robots in a digital marketplace.

Happy coding, and may your containers always run smoothly! 🚀🤖

EKSAWSHelmRedisMongoDBKubernetesec2