Skip to content

Node CI/CD to EKS with GitHub Actions

Costhigh
Deployability ci cd ready
Status local validated
Validation make test
Node.js Docker Kubernetes Kustomize Terraform aws terraform github-actions
Use the guide first.

The full learning guide is on this page. Open the repository files only when a step asks you to inspect code, fork the project, or download raw assets.

github-actions

πŸ›‘οΈ 2026 DevSecOps Enhancements (What You Will Learn)

Section titled β€œπŸ›‘οΈ 2026 DevSecOps Enhancements (What You Will Learn)”

This repository demonstrates advanced DevSecOps CI/CD patterns using GitHub Actions and Kustomize:

  1. OIDC AWS Authentication: The workflow utilizes OpenID Connect (OIDC) to authenticate with AWS. This eliminates the necessity of storing long-lived, static IAM access keys in GitHub Secrets, significantly reducing the risk of credential compromise.
  2. Environment Isolation via Kustomize: By leveraging Kustomize overlays (dev, staging, prod), the infrastructure configuration is strictly isolated. This guarantees separation of duties, allowing precise RBAC controls over who can deploy to each specific environment slice.

The repository is organized into several key directories:

β”œβ”€β”€ app
β”‚ β”œβ”€β”€ app.py
β”‚ β”œβ”€β”€ calculator.js
β”‚ β”œβ”€β”€ calculator.test.js
β”‚ β”œβ”€β”€ Dockerfile
β”‚ β”œβ”€β”€ Dockerfile-python
β”‚ β”œβ”€β”€ index.js
β”‚ └── package.json
β”œβ”€β”€ kustomize
β”‚ β”œβ”€β”€ base
β”‚ β”‚ β”œβ”€β”€ deploy.yaml
β”‚ β”‚ β”œβ”€β”€ ingress.yaml
β”‚ β”‚ β”œβ”€β”€ kustomization.yaml
β”‚ β”‚ └── svc.yaml
β”‚ └── overlays
β”‚ β”œβ”€β”€ dev
β”‚ β”‚ β”œβ”€β”€ deploy-dev.yaml
β”‚ β”‚ β”œβ”€β”€ ingress-dev.yaml
β”‚ β”‚ β”œβ”€β”€ kustomization.yaml
β”‚ β”‚ └── svc-dev.yaml
β”‚ β”œβ”€β”€ prod
β”‚ β”‚ β”œβ”€β”€ deploy-prod.yaml
β”‚ β”‚ β”œβ”€β”€ ingress-prod.yaml
β”‚ β”‚ β”œβ”€β”€ kustomization.yaml
β”‚ β”‚ └── svc-prod.yaml
β”‚ └── staging
β”‚ β”œβ”€β”€ deploy-staging.yaml
β”‚ β”œβ”€β”€ ingress-staging.yaml
β”‚ β”œβ”€β”€ kustomization.yaml
β”‚ └── svc-staging.yaml
β”œβ”€β”€ README.md
β”œβ”€β”€ terraform
β”‚ β”œβ”€β”€ ingress-nginx.tf
β”‚ β”œβ”€β”€ main.tf
β”‚ β”œβ”€β”€ outputs.tf
β”‚ β”œβ”€β”€ terraform.tf
β”‚ └── variables.tf
└── VERSION

The build job performs several key tasks:

  1. Environment Setup: Node.js environment is set up and dependencies are installed.
  2. Run Tests: Executes unit tests for the application.
  3. Determine Version Increment: Checks the commit message to determine if the version needs to be incremented using Semantic Versioning scheme.
  4. Docker Build and Push: Builds a Docker image and pushes it to a registry.

The deployment job handles the following:

  1. Terraform Setup: Initializes Terraform and sets up the backend with different state files.
  2. Terraform Plan and Apply: Executes terraform plan and terraform apply to provision environment specific infrastructure.
  3. Kubernetes Configuration: Configures kubectl to interact with the Kubernetes cluster.
  4. Ingress Controller Setup: Uses Helm to install the ingress controller.
  5. Application Deployment: Uses kubectl to deploy the Kustomized application manifests.
  • Dev Environment: Uses t3.small EC2 instances and deploys a single replica.
  • Staging Environment: Uses t3.medium EC2 instances and deploys three replicas.
  • Prod Environment: Uses t3.large EC2 instances and deploys three replicas.

DNS for all environments is automatically managed via Cloudflare and environment-specific subdomains are assigned and pointed to their respective LB hostname (using CNAME) ie., dev.afraz.dev, staging.afraz.dev and prod.afraz.dev.

Slack notifications are configured to send updates at the end of each job. This provides immediate feedback on the success or failure of the pipeline and also updates on the DNS changes if applicable.

The pipeline adheres to GitOps principles, where Git serves as the single source of truth. Any change to the application or infrastructure is expected to be made through a Git commit.

If you are planning to use this repo for learning, please hit the star. Thanks!