{"id":15130048,"url":"https://github.com/chukwuemekaaham/argocd_eks_reskill","last_synced_at":"2025-04-05T19:20:28.359Z","repository":{"id":247628984,"uuid":"826116121","full_name":"ChukwuemekaAham/ArgoCD_EKS_Reskill","owner":"ChukwuemekaAham","description":"AWS EKS reskill","archived":false,"fork":false,"pushed_at":"2024-07-09T16:24:15.000Z","size":9468,"stargazers_count":1,"open_issues_count":0,"forks_count":0,"subscribers_count":1,"default_branch":"main","last_synced_at":"2025-02-11T17:14:47.331Z","etag":null,"topics":["add-ons","alb","argocd","aws","aws-load-balancer-controller","cicd","eks","eksctl","grafana-dashboard","helm","ingress","irsa","k8s","kubectl","kustomize","nlb","prometheus","terraform"],"latest_commit_sha":null,"homepage":"","language":"HCL","has_issues":true,"has_wiki":null,"has_pages":null,"mirror_url":null,"source_name":null,"license":null,"status":null,"scm":"git","pull_requests_enabled":true,"icon_url":"https://github.com/ChukwuemekaAham.png","metadata":{"files":{"readme":"README.md","changelog":null,"contributing":null,"funding":null,"license":null,"code_of_conduct":null,"threat_model":null,"audit":null,"citation":null,"codeowners":null,"security":null,"support":null,"governance":null,"roadmap":null,"authors":null,"dei":null,"publiccode":null,"codemeta":null}},"created_at":"2024-07-09T06:05:30.000Z","updated_at":"2024-07-09T17:02:38.000Z","dependencies_parsed_at":"2024-07-09T21:08:24.656Z","dependency_job_id":null,"html_url":"https://github.com/ChukwuemekaAham/ArgoCD_EKS_Reskill","commit_stats":null,"previous_names":["chukwuemekaaham/argocd_eks_reskill"],"tags_count":0,"template":false,"template_full_name":null,"repository_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/ChukwuemekaAham%2FArgoCD_EKS_Reskill","tags_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/ChukwuemekaAham%2FArgoCD_EKS_Reskill/tags","releases_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/ChukwuemekaAham%2FArgoCD_EKS_Reskill/releases","manifests_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/ChukwuemekaAham%2FArgoCD_EKS_Reskill/manifests","owner_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners/ChukwuemekaAham","download_url":"https://codeload.github.com/ChukwuemekaAham/ArgoCD_EKS_Reskill/tar.gz/refs/heads/main","host":{"name":"GitHub","url":"https://github.com","kind":"github","repositories_count":247387100,"owners_count":20930775,"icon_url":"https://github.com/github.png","version":null,"created_at":"2022-05-30T11:31:42.601Z","updated_at":"2022-07-04T15:15:14.044Z","host_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub","repositories_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories","repository_names_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repository_names","owners_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners"}},"keywords":["add-ons","alb","argocd","aws","aws-load-balancer-controller","cicd","eks","eksctl","grafana-dashboard","helm","ingress","irsa","k8s","kubectl","kustomize","nlb","prometheus","terraform"],"created_at":"2024-09-26T02:27:56.649Z","updated_at":"2025-04-05T19:20:28.332Z","avatar_url":"https://github.com/ChukwuemekaAham.png","language":"HCL","funding_links":[],"categories":[],"sub_categories":[],"readme":"# Sample application\n\nThe sample application models a simple web store application, where customers can browse a catalog, add items to their cart and complete an order through the checkout process.\n\nThe application has several components and dependencies:\n\n![architecture](https://github.com/ChukwuemekaAham/ArgoCD_EKS_Reskill/blob/main/architecture-66f1f6af92d51d0b23a10dc4bfa77bdf.png)\n\n## Component description\n\nUI\t- Provides the front end user interface and aggregates API calls to the various other services.\nCatalog\t- API for product listings and details\nCart - API for customer shopping carts\nCheckout - API to orchestrate the checkout process\nOrders - API to receive and process customer orders\nStatic assets - Serves static assets like images related to the product catalog\n\n\u003ctable\u003e\u003cthead\u003e\u003ctr\u003e\u003cth\u003eComponent\u003c/th\u003e\u003cth\u003eDescription\u003c/th\u003e\u003c/tr\u003e\u003c/thead\u003e\u003ctbody\u003e\u003ctr\u003e\u003ctd\u003eUI\u003c/td\u003e\u003ctd\u003eProvides the front end user interface and aggregates API calls to the various other services.\u003c/td\u003e\u003c/tr\u003e\u003ctr\u003e\u003ctd\u003eCatalog\u003c/td\u003e\u003ctd\u003eAPI for product listings and details\u003c/td\u003e\u003c/tr\u003e\u003ctr\u003e\u003ctd\u003eCart\u003c/td\u003e\u003ctd\u003eAPI for customer shopping carts\u003c/td\u003e\u003c/tr\u003e\u003ctr\u003e\u003ctd\u003eCheckout\u003c/td\u003e\u003ctd\u003eAPI to orchestrate the checkout process\u003c/td\u003e\u003c/tr\u003e\u003ctr\u003e\u003ctd\u003eOrders\u003c/td\u003e\u003ctd\u003eAPI to receive and process customer orders\u003c/td\u003e\u003c/tr\u003e\u003ctr\u003e\u003ctd\u003eStatic assets\u003c/td\u003e\u003ctd\u003eServes static assets like images related to the product catalog\u003c/td\u003e\u003c/tr\u003e\u003c/tbody\u003e\u003c/table\u003e\n\nInitially we'll deploy the application in a manner that is self-contained in the Amazon EKS cluster, without using any AWS services like load balancers or a managed database. \n\nOver the course of the labs we'll leverage different features of EKS to take advantage of broader AWS services and features for our retail store.\n\nYou can find the full source code for the sample application on ![GitHub](https://github.com/aws-containers/retail-store-sample-app).\n\n\u003chr /\u003e\n\n# Setting Up EKS Cluster\n\nsee ~/setup folder\n\n```bash\n$ kubectl get nodes\nNAME                                           STATUS   ROLES    AGE   VERSION\nip-192-168-32-131.us-east-2.compute.internal   Ready    \u003cnone\u003e   9h    v1.23.17-eks-ae9a62a       \nip-192-168-79-172.us-east-2.compute.internal   Ready    \u003cnone\u003e   9h    v1.23.17-eks-ae9a62a       \nip-192-168-8-139.us-east-2.compute.internal    Ready    \u003cnone\u003e   9h    v1.23.17-eks-ae9a62a \n```\n\n# Packaging the components\n\nBefore a workload can be deployed to a Kubernetes distribution like EKS it first must be packaged as a container image and published to a container registry. Basic container topics like this are not covered as part of this workshop, and the sample application has container images already available in Amazon Elastic Container Registry for the labs we'll complete today.\n\nThe table below provides links to the ECR Public repository for each component, as well as the Dockerfile that was used to build each component.\n\n\n\u003ctable\u003e\u003cthead\u003e\u003ctr\u003e\u003cth\u003eComponent\u003c/th\u003e\u003cth\u003eECR Public repository\u003c/th\u003e\u003cth\u003eDockerfile\u003c/th\u003e\u003c/tr\u003e\u003c/thead\u003e\u003ctbody\u003e\u003ctr\u003e\u003ctd\u003eUI\u003c/td\u003e\u003ctd\u003e\u003ca href=\"https://gallery.ecr.aws/aws-containers/retail-store-sample-ui\" target=\"_blank\" rel=\"noopener noreferrer\"\u003eRepository\u003c/a\u003e\u003c/td\u003e\u003ctd\u003e\u003ca href=\"https://github.com/aws-containers/retail-store-sample-app/blob/main/images/java17/Dockerfile\" target=\"_blank\" rel=\"noopener noreferrer\"\u003eDockerfile\u003c/a\u003e\u003c/td\u003e\u003c/tr\u003e\u003ctr\u003e\u003ctd\u003eCatalog\u003c/td\u003e\u003ctd\u003e\u003ca href=\"https://gallery.ecr.aws/aws-containers/retail-store-sample-catalog\" target=\"_blank\" rel=\"noopener noreferrer\"\u003eRepository\u003c/a\u003e\u003c/td\u003e\u003ctd\u003e\u003ca href=\"https://github.com/aws-containers/retail-store-sample-app/blob/main/images/go/Dockerfile\" target=\"_blank\" rel=\"noopener noreferrer\"\u003eDockerfile\u003c/a\u003e\u003c/td\u003e\u003c/tr\u003e\u003ctr\u003e\u003ctd\u003eShopping cart\u003c/td\u003e\u003ctd\u003e\u003ca href=\"https://gallery.ecr.aws/aws-containers/retail-store-sample-cart\" target=\"_blank\" rel=\"noopener noreferrer\"\u003eRepository\u003c/a\u003e\u003c/td\u003e\u003ctd\u003e\u003ca href=\"https://github.com/aws-containers/retail-store-sample-app/blob/main/images/java17/Dockerfile\" target=\"_blank\" rel=\"noopener noreferrer\"\u003eDockerfile\u003c/a\u003e\u003c/td\u003e\u003c/tr\u003e\u003ctr\u003e\u003ctd\u003eCheckout\u003c/td\u003e\u003ctd\u003e\u003ca href=\"https://gallery.ecr.aws/aws-containers/retail-store-sample-checkout\" target=\"_blank\" rel=\"noopener noreferrer\"\u003eRepository\u003c/a\u003e\u003c/td\u003e\u003ctd\u003e\u003ca href=\"https://github.com/aws-containers/retail-store-sample-app/blob/main/images/nodejs/Dockerfile\" target=\"_blank\" rel=\"noopener noreferrer\"\u003eDockerfile\u003c/a\u003e\u003c/td\u003e\u003c/tr\u003e\u003ctr\u003e\u003ctd\u003eOrders\u003c/td\u003e\u003ctd\u003e\u003ca href=\"https://gallery.ecr.aws/aws-containers/retail-store-sample-orders\" target=\"_blank\" rel=\"noopener noreferrer\"\u003eRepository\u003c/a\u003e\u003c/td\u003e\u003ctd\u003e\u003ca href=\"https://github.com/aws-containers/retail-store-sample-app/blob/main/images/java17/Dockerfile\" target=\"_blank\" rel=\"noopener noreferrer\"\u003eDockerfile\u003c/a\u003e\u003c/td\u003e\u003c/tr\u003e\u003ctr\u003e\u003ctd\u003eAssets\u003c/td\u003e\u003ctd\u003e\u003ca href=\"https://gallery.ecr.aws/aws-containers/retail-store-sample-assets\" target=\"_blank\" rel=\"noopener noreferrer\"\u003eRepository\u003c/a\u003e\u003c/td\u003e\u003ctd\u003e\u003ca href=\"https://github.com/aws-containers/retail-store-sample-app/blob/main/src/assets/Dockerfile\" target=\"_blank\" rel=\"noopener noreferrer\"\u003eDockerfile\u003c/a\u003e\u003c/td\u003e\u003c/tr\u003e\u003c/tbody\u003e\u003c/table\u003e\n\n\n# Microservices on Kubernetes\n\nLet's explore some of the Kubernetes building blocks by looking at the catalog component:\n\n![catalog-microservice-450d6b2c9455ae06ae050a332de816be](https://github.com/ChukwuemekaAham/ArgoCD_EKS_Reskill/blob/main/catalog-microservice-450d6b2c9455ae06ae050a332de816be.png)\n\nLet's explore some of the Kubernetes building blocks by looking at the catalog component:\n\nCatalog microservice in Kubernetes\n\nThere are a number of things to consider in this diagram:\n\n- The application that provides the catalog API runs as a Pod, which is the smallest deployable unit in Kubernetes. Application Pods will run the container images we outlined in the previous section.\n\n- The Pods that run for the catalog component are created by a Deployment which may manage one or more \"replicas\" of the catalog Pod, allowing it to scale horizontally.\n\n- A Service is an abstract way to expose an application running as a set of Pods, and this allows our catalog API to be called by other components inside the Kubernetes cluster. Each Service is given its own DNS entry.\n\n- MySQL database that runs inside our Kubernetes cluster as a StatefulSet, which is designed to manage stateful workloads.\n\n- All of these Kubernetes constructs are grouped in their own dedicated catalog Namespace. Each of the application components has its own Namespace.\n\nEach of the components in the microservices architecture is conceptually similar to the catalog, using Deployments to manage application workload Pods and Services to route traffic to those Pods. If we expand out our view of the architecture we can consider how traffic is routed throughout the broader system:\n\n![microservices-da8ae7db8227d536d2481f4bfe5248e2](https://github.com/ChukwuemekaAham/ArgoCD_EKS_Reskill/blob/main/microservices-da8ae7db8227d536d2481f4bfe5248e2.png)\n\nThe ui component receives HTTP requests from, for example, a users browser. It then makes HTTP requests to other API components in the architecture to fulfill that request and returns a response to the user. Each of the downstream components may have their own data stores or other infrastructure. The Namespaces are a logical grouping of the resources for each microservice and also act as a soft isolation boundary, which can be used to effectively implement controls using Kubernetes RBAC and Network Policies.\n\n\n# Deploying our component\n\nThe sample application is composed of a set of Kubernetes manifests organized in a way that can be easily applied with Kustomize. Kustomize is an open-source tool also provided as a native feature of the kubectl CLI. This workshop uses Kustomize to apply changes to Kubernetes manifests, making it easier to understand changes to manifest files without needing to manually edit YAML. Kustomize was used to incrementally apply overlays and patches.\n\n**lets inspect the current Namespaces in our EKS cluster:**\n```bash\n$ kubectl apply -k ./base-application\n\n$ kubectl get namespaces\nNAME              STATUS   AGE\nargocd            Active   7h38m     \nassets            Active   64m       \ncarts             Active   64m\ncatalog           Active   64m       \ncheckout          Active   64m       \ndefault           Active   9h        \nkube-node-lease   Active   9h        \nkube-public       Active   9h        \nkube-system       Active   9h        \norders            Active   64m       \nother             Active   64m\nrabbitmq          Active   64m       \nui                Active   64m\n\n$ kubectl get deployment -l app.kubernetes.io/created-by=eks-workshop -A\nNAMESPACE   NAME             READY   UP-TO-DATE   AVAILABLE   AGE\nassets      assets           1/1     1            1           65m\ncarts       carts            1/1     1            1           65m\ncarts       carts-dynamodb   1/1     1            1           65m\ncatalog     catalog          1/1     1            1           64m\ncheckout    checkout         1/1     1            1           64m\ncheckout    checkout-redis   1/1     1            1           64m\norders      orders           1/1     1            1           64m\norders      orders-mysql     1/1     1            1           64m\nui          ui               3/3     3            3           65m\n\n```\n\n# Helm\n\n\nAlthough we primarily interact with kustomize, there will be situations where Helm will be used to install certain packages in the EKS cluster. \n\nHelm is a package manager for Kubernetes that helps you define, install, and upgrade Kubernetes applications. It uses a packaging format called charts, which contain all the necessary Kubernetes resource definitions to run an application. Helm simplifies the deployment and management of applications on Kubernetes clusters.\n\n## Helm CLI\nThe helm CLI tool is typically used in conjunction with a Kubernetes cluster to manage the deployment and lifecycle of applications. It provides a consistent and repeatable way to package, install, and manage applications on Kubernetes, making it easier to automate and sta\n\n\n`$ helm version`\n\n## Helm repositories\nA Helm repository is a centralized location where Helm charts are stored and managed, and allow users to easily discover, share, and install charts. They facilitate easy access to a wide range of pre-packaged applications and services for deployment on Kubernetes clusters.\n\nThe Bitnami Helm repository is a collection of Helm charts for deploying popular applications and tools on Kubernetes. Let's add the bitnami repository to our Helm CLI:\n\n```bash\n$ helm repo add bitnami https://charts.bitnami.com/bitnami\n\n$ helm repo update\nNow we can search the repository for charts, for example the postgresql \n\n$ helm search repo postgresql\nNAME                    CHART VERSION   APP VERSION     DESCRIPTION\nbitnami/postgresql      X.X.X           X.X.X           PostgreSQL (Postgres) is an open source object-...\n[...]\n```\n\n## nstalling a Helm chart\nLet's install an NGINX server in our EKS cluster using the Helm chart we found above. When you install a chart using the Helm package manager, it creates a new release for that chart. Each release is tracked by Helm and can be upgraded, rolled back, or uninstalled independently from other releases.\n\n```bash\n$ echo $NGINX_CHART_VERSION\n\n$ helm install nginx bitnami/nginx \\\n  --version $NGINX_CHART_VERSION \\\n  --namespace nginx --create-namespace --wait\n```\n\nWe can break this command down as follows:\n\n- Use the install sub-command to instruct Helm to install a chart\nName the release nginx\n\n- Use the chart bitnami/nginx with the version $NGINX_CHART_VERSION\nInstall the chart in the nginx namespace and create that namespace first\n\n- Wait for pods in the release to get to a ready state\n\n- Once the chart has installed we can list the releases in our EKS cluster:\n\n```bash\n$ helm list -A\nNAME \t NAMESPACE  REVISION  UPDATED                                  STATUS    CHART         APP VERSION\nnginx\t nginx      1         2024-06-11 03:58:39.862100855 +0000 UTC  deployed  nginx-X.X.X   X.X.X\nWe can also see NGINX running in the namespace we specified:\n\n\n$ kubectl get pod -n nginx\nNAME                     READY   STATUS    RESTARTS   AGE\nnginx-55fbd7f494-zplwx   1/1     Running   0          119s\n```\n\n## Configuring chart options\nIn the example above we installed the NGINX chart in its default configuration. Sometimes you'll need to provide configuration values to charts during installation to modify the way the component behaves.\n\nThere are two common ways to provide values to charts during installation:\n\nCreate YAML files and pass them to Helm using the -f or --values flag\nPass values using the --set flag followed by key=value pairs\nLet's combine these methods to update our NGINX release. We'll use this values.yaml file:\n\n./introduction/helm/values.yaml\n\npodLabels:\n  team: team1\n  costCenter: org1\n\nresources:\n  requests:\n    cpu: 250m\n    memory: 256Mi\n\nThis adds several custom Kubernetes labels to the NGINX pods, as well as setting some resource requests.\n\nWe'll also add additional replicas using the --set flag:\n\n```bash\n$ helm upgrade --install nginx bitnami/nginx \\\n  --version $NGINX_CHART_VERSION \\\n  --namespace nginx --create-namespace --wait \\\n  --set replicaCount=3 \\\n  --values ./introduction/helm/values.yaml\n\n\n# List the releases:\n\n$\nhelm list -A\nNAME \t NAMESPACE  REVISION  UPDATED                                  STATUS    CHART         APP VERSION\nnginx\t nginx      2         2024-06-11 04:13:53.862100855 +0000 UTC  deployed  nginx-X.X.X   X.X.X\n\n# You'll notice that the revision column has updated to 2 as Helm has applied our updated configuration as a distinct revision. This would allow us to rollback to our previous configuration if necessary.\n\n# You can view the revision history of a given release like this:\n\n$ helm history nginx -n nginx\nREVISION  UPDATED                   STATUS      CHART        APP VERSION  DESCRIPTION\n1         Tue Jun 11 03:58:39 2024  superseded  nginx-X.X.X  X.X.X       Install complete\n2         Tue Jun 11 04:13:53 2024  deployed    nginx-X.X.X  X.X.X       Upgrade complete\n\n# To check that our changes have taken effect list the pods in the nginx namespace:\n\n\n$ kubectl get pods -n nginx\nNAME                     READY   STATUS    RESTARTS   AGE\nnginx-55fbd7f494-4hz9b   1/1     Running   0          30s\nnginx-55fbd7f494-gkr2j   1/1     Running   0          30s\nnginx-55fbd7f494-zplwx   1/1     Running   0          5m\n\n# You can see we now have 3 replicas of the NGINX pod running.\n\n# Removing releases\n# We can similarly uninstall a release using the CLI:\n\n\n$ helm uninstall nginx --namespace nginx --wait\n\n# This will delete all the resources created by the chart for that release from our EKS cluster.\n","project_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fchukwuemekaaham%2Fargocd_eks_reskill","html_url":"https://awesome.ecosyste.ms/projects/github.com%2Fchukwuemekaaham%2Fargocd_eks_reskill","lists_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fchukwuemekaaham%2Fargocd_eks_reskill/lists"}