Forem: Amarachi Iheanacho

Securing your AWS EKS cluster

Amarachi Iheanacho — Sat, 09 Aug 2025 12:32:58 +0000

When a small analytics firm's misconfigured Kubernetes cluster exposed the sensitive data of a Fortune 500 client worth billions in revenue, it wasn't just a technical oversight, it was a business catastrophe waiting to happen. This isn't an isolated incident. In 2024 alone, researchers discovered over 350 organizations with publicly accessible, largely unprotected Kubernetes clusters, with 60% of them already breached and running active malware campaigns.

The financial stakes couldn't be higher. The average data breach now costs $4.88 million, while software supply chain attacks cost businesses $45.8 billion globally in 2023. For organizations running AWS Elastic Kubernetes Service (EKS), these aren't abstract statistics, they're urgent realities that demand immediate attention.

AWS EKS is indeed a powerful solution for running containerized applications at scale. It simplifies many operational challenges by providing a fully managed Kubernetes control plane, helping organizations reduce overhead and accelerate deployment. However, the AWS shared responsibility model makes one thing crystal clear: while AWS secures the underlying infrastructure, protecting your workloads, configurations, and data remains entirely your responsibility. Even the smallest oversight can cascade into breaches or compliance violations that cost millions.

This is where this guide comes in. We'll show you how to build a robust security posture for your EKS environment, covering:

Control plane security
Network and pod security layers
Secrets management
Monitoring and incident response planning.

Understanding the EKS security landscape

With EKS clusters holding our entire application, saying that you need to care about securing these clusters is by no means a throwaway statement. Security is absolutely critical, and, unfortunately, also very challenging.

The challenge with EKS security isn’t just about implementing individual protective measures. It’s about understanding how all these components interact within a complex, distributed system.

Unlike traditional monolithic applications, where security boundaries are clearly defined, containerized environments create dynamic attack surfaces that shift as pods scale, migrate, and communicate across your infrastructure.

This complexity is compounded by the fact that many security decisions must happen simultaneously at multiple levels: at the cluster level through RBAC policies, at the network level through CNI configurations, and at the application level through service mesh implementations. A compromise at any of these layers can put your entire cluster, and therefore your entire application, at risk.

In this article, we’re going to discuss security at different levels, covering how to secure the following components of your cluster:

Control plane
Network
Pods
Secrets
Images

And more importantly, we’ll look at why even after doing all this, you should never abandon your cluster and must continue monitoring it for anomalies and vulnerabilities.

Control plane security

The control plane is the heart, or more accurately, the brain, of any cluster, and this holds true for an EKS cluster as well. That makes it the most critical component to secure properly.

The control plane decides and enforces everything: where and when pods should run, who has access to what, how API requests are handled, and the overall state of the cluster. If an attacker gains access to the control plane, they can see everything happening in your environment, change configurations, and much more.

To put it simply, so you understand the severity: if you lose control of the control plane, you lose control of your entire cluster.

Thankfully, there are ways to protect your control plane from malicious actors. Here’s how:

API server access control

Your API server is the gateway to your entire Kubernetes cluster. Every kubectl command, every deployment, every request to access secrets, it all flows through this single point. This centralization makes the API server incredibly powerful but also a potential security risk if you don’t secure it properly.

To protect your API server, start by enabling private endpoint access. You can refer to the Cluster API server endpoint documentation for detailed steps on how to set this up.

Private endpoints ensure that communication between your worker nodes and the control plane stays entirely within your VPC, eliminating exposure to internet-based attack vectors.

While this approach is excellent for securing the control plane, using only private endpoints can make cluster management more challenging.

That’s why I usually recommend a hybrid approach: enable both private and public endpoints but restrict public access to specific IP ranges using CIDR blocks. This setup allows you to manage your cluster securely from authorized locations without sacrificing flexibility.

Authentication and authorization

Another way to secure your control plane is by carefully managing who has access to your clusters and, once they do, what they’re allowed to do inside them.

A powerful way to achieve this is by leveraging AWS IAM. Amazon EKS integrates seamlessly with IAM, allowing you to use your existing AWS identities and permissions to control access to your Kubernetes clusters.

While this integration is convenient, you must be cautious when configuring IAM to avoid privilege escalation, in other words, accidentally granting people permissions they don’t actually need.

When you create an EKS cluster, only the IAM entity (user or role) that created it has access by default. This design helps prevent unauthorized access right from the start. However, you’ll typically need to grant access to additional team members and service accounts in a controlled, systematic way, based on their roles and responsibilities.

To efficiently and accurately grant access to individuals and teams, you use the aws-auth ConfigMap, which maps IAM roles and users to Kubernetes groups. Be aware that this mapping is where many security misconfigurations originate.

Always review and test these mappings carefully. Refer to Grant IAM users access to Kubernetes with a ConfigMap for more information on how to grant access using the ConfigMap.

Finally, never grant cluster-admin privileges unless absolutely necessary. Instead, create fine-grained RBAC policies that follow the principle of least privilege. For example, a developer working on frontend applications doesn’t need access to database secrets or infrastructure namespaces.

Network security

Now that we’ve covered control plane security, let’s turn to another critical, and frankly quite complex, attack surface: the network.

Everything in your cluster, pods, nodes, and services, communicates over the network. If you don’t secure this layer, anyone who gains access to your network could potentially read or tamper with sensitive data.

In Amazon EKS, network security operates across multiple layers, each offering a different type of protection. Let’s take a closer look at how to secure each of these layers.

VPC configuration and subnet strategy

Your cluster's network foundation starts with proper VPC design. Place your worker nodes in private subnets whenever you can, this ensures that they can't be directly accessed from the internet.

This single decision can eliminate entire categories of threats, such as SSH brute-force attacks, external scanning, and remote exploitation, while still allowing your applications to function as needed.

Use separate subnets for different node groups based on their security requirements. Your production workloads shouldn't share network space with development environments, and your database nodes need different access patterns than your web servers.

The subnet strategy becomes particularly important when implementing network policies. Kubernetes network policies work at the pod level, but they're most effective when combined with VPC-level controls.

Network policies

Next are network policies, which have become very popular at this point.

Network policies allow you to control traffic flow between pods with remarkable precision, creating microsegmentation that would be impossible with traditional network security tools.

A well-designed network policy starts with a default-deny stance. This means that unless explicitly allowed, no traffic flows between pods. While this might seem restrictive, it's the foundation of a zero-trust network architecture.

Once you've established your default-deny policy, you can selectively allow traffic based on your application's requirements. For example, a frontend application might need to communicate with a backend API but should never have direct access to the database.

Service mesh

For secure service-to-service encryption, then service mesh is your guy.

Service meshes like Istio or AWS App Mesh provide traffic encryption, authentication, and authorization at the service level, adding another layer of security beyond network policies.

Service meshes excel in environments where you need to implement security policies based on service identity rather than network location. They're particularly valuable when dealing with compliance requirements that mandate encryption in transit for all inter-service communication.

Pod security

Now that you have defined and restricted access to your pods and the spaces they run in, it’s time to control what pods are allowed to do and how they run. This is exactly what pod security aims to achieve.

Pod security lets you establish rules that prevent pods from performing potentially risky actions inside your cluster and this section will explore the components of pod security in detail.

Pod Security Standards implementation

Pod Security Standards are rules that define how strict Kubernetes should be about what pods are allowed to do. There are three main policy levels:

Privileged: Almost no restrictions, pods can do virtually anything. This is generally a bad idea for production environments.
Baseline: Applies some restrictions to block the most dangerous behaviors such as running as root without restrictions, while still supporting common use cases.
Restricted: The most stringent level. Pods can’t run as root, can’t perform privileged actions, and must declare clear security settings.

The Restricted policy is particularly effective at reducing your cluster’s exposure to container escape attacks. While you may need to adjust some applications to comply, these controls provide strong protection for your workloads.

Refer to the Pod Security Standards for more information.

Security contexts

Unlike Pod Security Standards, which act as cluster-wide gatekeepers deciding what pods can even be scheduled, security contexts are the granular controls you apply to individual pods and containers.

Security contexts give you precise control over how your containers operate at runtime. You can specify exactly which user ID a container runs as, whether it can escalate privileges, what Linux capabilities it has access to, and how it interacts with the file system. This granular approach means you can tailor security settings to each workload's specific needs rather than applying broad restrictions across your entire cluster.

The real power of security contexts becomes apparent when you consider that they work in tandem with Pod Security Standards. Your Pod Security Standards might enforce that containers can't run as root, but security contexts let you specify that a particular container should run as user ID 1000 with group ID 3000. The standards provide the guardrails; the contexts provide the precise configuration.

Runtime security

While Pod Security Standards and security contexts define who can run and how they are configured, runtime security focuses on what containers actually do once they are running.

Runtime security is all about continuously monitoring your workloads for suspicious or unauthorized activity. Even if a container starts in a secure state, it could be exploited through vulnerabilities, misconfigurations, or malicious code. Runtime security tools help detect and stop these threats before they can escalate.

Secrets management

In addition to securing your pods and network, you also need to protect your secrets. Kubernetes offers almost no secure mechanism for secret storage, and the default base64 encoding is not encryption, it's merely obfuscation that provides no real security benefit.

To actually secure your secrets, you need to use the following:

AWS Secrets Manager integration

AWS provides a solution for managing secrets, AWS Secrets Manager.

You can use AWS Secrets Manager to securely store and retrieve sensitive data such as API keys, passwords, and certificates. You can store and retrieve secrets without exposing them in your manifests or ConfigMaps.

To make the process even more seamless, tools like External Secrets Operator can automatically synchronize secrets from AWS Secrets Manager into Kubernetes in a controlled way.

Encryption at Rest and in Transit

Next, you need to enable encryption at rest for the etcd database in your EKS cluster. This ensures that even if someone gains physical access to the underlying storage, your secrets remain protected.

In addition, configure TLS for all inter-service communication. Many applications default to unencrypted connections within the cluster, assuming that private networks are secure by default. This assumption is risky in cloud environments, where network boundaries are often more fluid and less predictable. Refer to the Encrypting Data-at-Rest and Data-in-Transit for more information.

Image security

Another surface to secure that is often overlooked are container images. A single vulnerable base image or malicious dependency can compromise your entire application, and this is why the importance of image security cannot be overstated.

To secure your images, do the following:

Image scanning and vulnerability management

Implement automated image scanning in your CI/CD pipeline using tools like Amazon ECR image scanning or third-party solutions like Twistlock or Aqua Security. These tools identify known vulnerabilities in your images before they reach production.

With these solutions, you can establish rules and policies that prevent deployment of images with high-severity vulnerabilities.

While in an ideal world you would want to have zero vulnerabilities, it's sometimes an impractical goal.

Instead, focus on removing critical and high-severity vulnerabilities while managing medium and low-severity issues through regular patching cycles.

Admission controllers

Admission controllers are pieces of code that intercept requests to the Kubernetes APIserver after authentication and authorization, but before the object is persisted to etcd.

They validate or mutate resource requests.

So any time you create, update, or delete a Kubernetes resource, like a Pod, Deployment, or Secret, the Admission controllers get a chance to inspect or change the request.

They can enforce policies, apply defaults, or reject things that don’t meet certain criteria.

Monitoring and logging

Even after you’ve taken the necessary steps to secure your EKS cluster, that alone isn’t enough to guarantee complete peace of mind. You also need to continuously monitor your cluster and log events to ensure your systems remain healthy and secure over time.

Effective monitoring and logging creates the foundation for visibility, accountability, and rapid response, so that you can be ready even when things eventually goes wrong.

Here are the components of an effective monitoring and response strategy:

Control plane logging

AWS EKS provides comprehensive control plane logging capabilities that capture critical events and activities within your cluster's management layer. By enabling control plane logs, you gain visibility into API server requests, authenticator decisions, audit trails, and scheduler operations. These logs are automatically delivered to Amazon CloudWatch Logs, where you can analyze patterns, set up alerts, and maintain compliance requirements.

The five types of control plane logs available include API server logs for tracking all API requests, audit logs for security compliance, authenticator logs for authentication debugging, controller manager logs for resource management oversight, and scheduler logs for pod placement decisions.

Application and node monitoring

Beyond the control plane, your monitoring strategy must extend to the applications running within your cluster and the underlying worker nodes. Container-level metrics such as CPU usage, memory consumption, and network traffic patterns help you understand application performance and resource utilization. Node-level monitoring tracks system health, disk usage, and overall infrastructure stability.

Tools like Prometheus paired with Grafana provide powerful open-source monitoring capabilities, while AWS CloudWatch Container Insights offers native integration with EKS clusters. Implement custom metrics for your specific applications and establish baseline performance indicators so you can quickly identify when systems deviate from normal behavior.

Incident response planning

Having great monitoring is only valuable if you have a well-defined plan for what to do when an issue arises.

A great example of an amazing incident response was in 2018, when Tesla addressed vulnerabilities within hours of Redlock discovering them, before any customer data had been stolen.

Incident response planning involves developing clear, repeatable procedures for identifying, containing, and resolving security or operational incidents.

Your response strategy should include playbooks that outline step-by-step actions for different scenarios, such as compromised workloads, suspicious API activity, or unexpected resource exhaustion. These playbooks should specify how to isolate affected resources, collect forensic evidence, escalate to the appropriate teams, and communicate with stakeholders.

Wrapping up your EKS security journey

Securing your AWS EKS cluster isn’t a one-time task you can check off a list. It’s an ongoing process that requires careful planning, continuous improvement, and vigilance. From protecting your control plane and locking down your network to hardening pods, securing secrets, scanning images, and building robust monitoring and response practices, every layer contributes to your overall security posture.

While this guide has covered many of the most critical strategies and tools, remember that the most effective security programs are adaptive. New threats, vulnerabilities, and attack techniques will continue to emerge, and your defenses must evolve accordingly.

The key is to approach EKS security as a shared responsibility that extends beyond infrastructure. It’s about cultivating a culture where security is considered at every stage, design, development, deployment, and operation. With the right processes, tooling, and mindset in place, you’ll be well-equipped to protect your workloads and maintain the trust of your users, no matter how your Kubernetes environment grows.

Provision an AWS EC2 jumphost using Terraform and GitHub Actions

Amarachi Iheanacho — Mon, 30 Jun 2025 08:00:00 +0000

Modern application development demands a level of agility that traditional architectures simply can't support. Today's systems must enable teams to deploy changes quickly, safely, and efficiently. They must scale up or down in response to demand. And much of the work of DevOps involves figuring out how to achieve all of this in a repeatable and reliable way.

This article kicks off a four-part series on building a secure and scalable DevSecOps pipeline for deploying a quiz application to an Amazon Elastic Kubernetes Service(EKS) cluster. Throughout the series, you’ll leverage Infrastructure as Code (IaC) with Terraform, implement CI/CD using GitHub Actions, adopt GitOps practices through ArgoCD, and harness the scalability of Amazon EKS.

In this first part, we'll focus on setting up a secure EC2 jumphost. This jumphost will act as a controlled, auditable access point to the EKS cluster you’ll deploy later in the series. Rather than exposing your entire cluster to the internet, the jumphost provides a secure gateway for administrative access.

You’ll use Terraform to define the jumphost infrastructure, including compute resources, networking, and security rules. To make the setup fully automated, you’ll integrate GitHub Actions so that any change to the Terraform configuration triggers a workflow. This ensures that your infrastructure remains consistent, version-controlled, and easily reproducible.

By the end of this guide, you’ll have hands-on experience provisioning a hardened EC2 jumphost on AWS, entirely automated through Terraform and GitHub Actions, laying the foundation for a secure and scalable DevSecOps pipeline.

What this series will contain

This four-part series will walk you through building a modern DevSecOps pipeline for a containerized quiz application. Here's what each part will cover:

Provision a secure EC2 jumphost using Terraform and GitHub Actions (this article).
Build a CI/CD pipeline that tests your application and pushes Docker images to Amazon ECR.
Set up an Amazon EKS cluster and deploy the application with ArgoCD.
Add monitoring and observability using Prometheus and Grafana.

Clone the quiz application

This series builds on the quiz application. You can clone the repository here: Quiz application GitHub

Check out this GitHub repository, to view the complete code for the entire series: Three-tier DevSecOps Project GitHub

Prerequisites

To get the most out of this article, you must have the following:

A basic understanding of Git.
A GitHub account. If you don’t have one, you can create one here.
An AWS account. If you don’t have one, you can sign up for a free account here.
A basic understanding of GitHub Actions and Terraform.

Project structure

In this article, you will create a jumphost, which you'll later use to access an EKS cluster in the later parts of the series.

After cloning and pulling the quiz project from GitHub, add the following folders and files to the project structure:

terraform folder: Inside this folder, create three files, main.tf, outputs.tf, and variables.tf, to store all the Terraform configurations for the project.
scripts folder: This folder should contain the jumphost_init.sh file, which will include commands for installing the necessary packages on the jumphost.
.github/workflows folder: Create a terraform.yaml file in this folder to define the GitHub Actions configuration for the Terraform pipeline.

Once you've added these files, your project structure should look like this:

.
├── backend
└── .github/
    └── workflows/
        └── terraform.yml
├── docker-compose.yaml
├── frontend
├── scripts
│   └── jumphost_init.sh
└── terraform
    ├── main.tf
    ├── outputs.tf
    └── variables.tf

Pre-project setup checklist

You need to do the following before diving into this project:

Create an AWS access key and secret access key.
Set up an S3 bucket.
Generate a public SSH key.
Add your credentials (AWS access key, secret access key, and S3 bucket) to your GitHub Actions secrets.

Create an AWS access key and secret access key

These keys provide Terraform and GitHub Actions with programmatic access to your AWS account, allowing them to read or write data to your account.

Follow these steps to create your AWS keys:

Sign in to your AWS account, either as an IAM user or a root user
In the AWS console, search for IAM and select it.
Click Users in the sidebar, and select the Create user button
Enter a username (e.g., jumphost-terraform) and click Next.
Choose the Attach policies directly option.
Search for the AdministratorAccess policy and select it. (Note: This is just for the demo; in a real-world scenario, practice least privilege access.)
Click Next, review your user settings, and click Create user.
You should now see your user listed. Select the newly created user.
Navigate to the Security credentials tab.
Click Create access key in the Access key section.
Choose Third-party service, check the confirmation box, and click Next.
Optionally, add a description for the key.
Click Create access key.
Copy your Access key and Secret access key, and store them in a secure location (you won’t be able to view them again after leaving this page).
Click Done.

With that, you have created your Access and Secret access keys.

Create an S3 bucket

Next, create an S3 bucket to store Terraform's state files, which represent the current state of your infrastructure. By default, Terraform stores these files locally, but using S3 ensures that the state is centralized and accessible. Follow these steps to create your S3 bucket:

In the AWS console, search for S3 and select it.
Click Create bucket under the General purpose buckets section.
Choose a globally unique name for your bucket.
Click Create bucket.

Create an SSH key

You’ll need an SSH key to securely access your EC2 instance. Here's how to create one:

Open your terminal and navigate to the ~/.ssh directory. If it doesn’t exist, create it:

cd ~/.ssh  # Navigate to the directory if it exists
mkdir ~/.ssh  # Create the directory if it doesn't exist

2.Run the following command to generate your SSH key:

ssh-keygen -t ed25519

3.When prompted for the file location to save the key, enter a name for the key (e.g., key) and press Enter.

4.Press Enter for the rest of the prompts to accept the defaults. Your SSH key is now generated.

5.To view and copy your public key, run:

cat <name of the key>.pub

For example, if you had entered key when prompted, your command would be:

cat key.pub

Copy and save the content of this file as it is your public key and you would need it to provision and SSH into your instance.

Add the credentials to your GitHub secrets

Now that you have your AWS Access Key, Secret Access Key, and S3 Bucket you need to add these as secrets in GitHub Actions for your CI/CD pipeline.
Follow these steps to add your credentials to GitHub Secrets:

Log in to your GitHub account.
Navigate to your cloned repository.
Click the Settings tab.
In the left sidebar, click Secrets and variables, then select Actions.
Click New repository secret.
Add each of the following secrets with the corresponding values:
- Name: AWS_ACCESS_KEY_ID | Secret:
- Name: AWS_SECRET_ACCESS_KEY | Secret:
- Name: BUCKET_TF | Secret:
After entering each secret, click Add secret.

Provisioning the jumphost with Terraform

To provision the jumphost, we’ll use Terraform with a modular and organized setup. The configuration is divided into three core files: main.tf, variables.tf, and [outputs.tf], each serving a specific purpose:

main.tf defines the infrastructure resources. In this case, it describes the EC2 instance that Terraform will provision.
variables.tf declares reusable input variables, allowing you to customize the configuration in main.tf easily. This makes your setup more flexible and maintainable.
outputs.tf specifies the output values you want Terraform to return after provisioning, such as public IPs or instance IDs.

In the next step, you’ll copy the relevant code snippets into each of these files.

Define your Terraform variables in your `[variables.tf]` file

Create your Terraform variables by copying and pasting these variables in your variables.tf file, replacing the <your public key> with the public key you generated earlier:

variable "region" {
 default = "us-east-1"
}

variable "vpc_cidr" {
 default = "10.0.0.0/16"
}

variable "instance_type" {
 default = "t3.micro"
}

variable "ami_name_filter" {
 default = "ubuntu/images/hvm-ssd/ubuntu-jammy-22.04-amd64-server-*"
}

variable "allowed_ssh_cidr" {
 default = "0.0.0.0/0"
}

variable "key_name" {
 default = "jumphost_key"
}

variable "public_key" {
 description = "Your SSH public key"
 default     = "<your public key>" # Add your public key here
}

variable "environment" {
 default = "DevOpsProject"
}

variable "owner" {
 default = "Amarachi"
}

Here’s a breakdown of what each variable does:

region: Specifies the AWS region where resources will be deployed. Default is us-east-1.
vpc_cidr: Sets the IP range for the Virtual Private Cloud (VPC). Default is 10.0.0.0/16.
instance_type: Defines the EC2 instance type. We’re using t3.micro for a cost-effective option suitable for lightweight tasks.
ami_name_filter: Filters the Amazon Machine Image (AMI) for Ubuntu 22.04 (Jammy). Terraform will pick the latest version matching this pattern.
allowed_ssh_cidr: Determines which IP ranges are allowed to SSH into the instance. The default (0.0.0.0/0) allows access from anywhere—fine for testing, but should be tightened for production environments.
key_name: The name of your SSH key pair used to access the EC2 instance.
public_key: Defines a default SSH public key value that will be used to provision access to the jumphost.
environment: A tag to help identify which environment (e.g., Dev, Staging, Prod) the resources belong to.
owner: Tags resources with the owner’s name for accountability and resource tracking.

Next, you’ll continue by configuring the infrastructure in main.tf and defining outputs in outputs.tf.

Set your EC2 instance configuration using Terraform

Paste the following code into your main.tf file, replacing <name of the bucket> with the actual name of your bucket. This will define the properties of your EC2 instance.
https://gist.github.com/Iheanacho-ai/ff01f2e0ff30e30b95a6a4b5576c73d8

Here is a structure breakdown of what each Terraform block in the main.tf file does (If you're already familiar with Terraform, feel free to skip ahead to the Define your outputs in the outputs.tf file section.):

Terraform block

terraform {
 required_providers {
   aws = {
     source  = "hashicorp/aws"
     version = "~> 5.0"
   }
 }

 backend "s3" {
   bucket = "amara-jumphost"
   key    = "terraform.tfstate"
   region = "us-east-1"
 }
}

This Terraform block above defines two things:

Provider Configuration: The required _providers block specifies that the AWS provider will be used
Remote State Backend: The backend"s3" block stores the current Terraform state file in an S3 bucket. This bucket is the same bucket you created at the start of the project.

AWS provider

# This is the AWS provider
provider "aws" {
 region = var.region
}

The provider"aws" block configures the AWS provider to operate in the region specified in the region variable in your [variables.tf] file.

Ubuntu AMI

# Get latest Ubuntu AMI
data "aws_ami" "ubuntu" {
 most_recent = true

 filter {
   name   = "name"
   values = [var.ami_name_filter]
 }

 filter {
   name   = "virtualization-type"
   values = ["hvm"]
 }

 owners = ["099720109477"]
}

The code block above dynamically fetches the latest Ubuntu AMI available in AWS. Here is a breakdown of the data block:

data "aws_ami" "ubuntu": Declares a data source block to look up an AWS AMI named "ubuntu".
- most_recent = true: Ensures that Terraform selects the most recently created AMI from all the results from the filters.
filter block #1 — Name filter:
- name = "name": Filters AMIs by name.
- values = [var.ami_name_filter]: Uses the ami_name_filter variable defined in the [variables.tf] file to match AMI names for the filter.
filter block #2 — Virtualization type filter:
- name = "virtualization-type": Filters by virtualization type.
- values = ["hvm"]: Ensures only Hardware Virtual Machine (HVM) AMIs are returned, which is the standard for most modern EC2 instances.
owners = ["099720109477"]: Limits the search to AMIs owned by Canonical, the publisher of Ubuntu. This ID is Canonical’s official AWS account.

Networking Setup

This setup defines the networking infrastructure which your EC2 instance will live. It includes the following key components:

Virtual Private Cloud (VPC): An isolated, configurable network that provides foundational connectivity for your AWS resources.
Subnet: A segmented IP range within the VPC that dictates availability zones and routing for your EC2 instance.
Internet Gateway: Allows the EC2 instance to send and receive traffic from the internet by routing it in and out of the VPC.

Let's break down how each of these components is defined in Terraform.

resource "aws_vpc" "jumphost_vpc" {
 cidr_block           = var.vpc_cidr
 enable_dns_hostnames = true
 enable_dns_support   = true
}

This resource defines a dedicated VPC named jumphost_vpc with the CIDR block specified in your variables.tf file. DNS hostnames and DNS support are enabled to allow for easier internal and external name resolution.

Subnet

resource "aws_subnet" "jumphost_subnet" {
 cidr_block = cidrsubnet(aws_vpc.jumphost_vpc.cidr_block, 4, 1)
 vpc_id     = aws_vpc.jumphost_vpc.id
}

This Terraform block creates a subnet named jumphost_subnet within the jumphost_vpc VPC. It calculates the subnet’s CIDR block by dividing the VPC’s CIDR range into 16 smaller subnets (by increasing the subnet mask by 4 bits) and selects the second subnet (index 1). The subnet is associated with the VPC by referencing its ID.

Note: Terraform automatically handles the creation and referencing of these resource IDs.

Internet Gateway and Routing

resource "aws_internet_gateway" "jumphost_igw" {
 vpc_id = aws_vpc.jumphost_vpc.id

 tags = {
   Name = "main"
 }
}

resource "aws_route_table" "jumphost_route_table" {
 vpc_id = aws_vpc.jumphost_vpc.id

 route {
   cidr_block = "0.0.0.0/0"
   gateway_id = aws_internet_gateway.jumphost_igw.id
 }
}

resource "aws_route_table_association" "jumphost_route_table_assoc" {
 subnet_id      = aws_subnet.jumphost_subnet.id
 route_table_id = aws_route_table.jumphost_route_table.id
}

This Terraform configuration enables internet access for a subnet using the following AWS networking components:

aws_internet_gateway.jumphost_igw: Creates an Internet Gateway and attaches it to the specified VPC using vpc_id = aws_vpc.jumphost_vpc.id. This allows the VPC to communicate with the internet.
aws_route_table.jumphost_route_table: Creates a route table for the VPC. It includes a route that directs all outbound traffic (0.0.0.0/0) through the Internet Gateway created earlier.
aws_route_table_association.jumphost_route_table_assoc: Associates the route table with a specific subnet, enabling instances within that subnet to use the routing rules, i.e., to access the internet via the Internet Gateway.

 subnet_id      = aws_subnet.jumphost_subnet.id
 route_table_id = aws_route_table.jumphost_route_table.id

Security Group

# Security Group
resource "aws_security_group" "jumphost_SG" {
 name   = "jumphost_SG"
 vpc_id = aws_vpc.jumphost_vpc.id

 ingress {
   cidr_blocks = [var.allowed_ssh_cidr]
   from_port   = 22
   to_port     = 22
   protocol    = "tcp"
 }

 egress {
   from_port   = 0
   to_port     = 0
   protocol    = -1
   cidr_blocks = ["0.0.0.0/0"]
 }
}

This Terraform block creates a Security Group in AWS named jumphost_SG that wil be associated with the jumphost_vpc VPC. With this security group you specify:

Ingress Rule (Incoming traffic): This rule allows SSH access (port 22) from the IP range specified by the variable var.allowed_ssh_cidr.
Egress Rule (Outgoing traffic): This allows all outbound traffic to any IP address (0.0.0.0/0).

Key pair

resource "aws_key_pair" "jumphost_key" {
 key_name   = var.key_name
 public_key = var.public_key
}

This Terraform block creates and attaches the SSH key you generated earlier to your EC2 instance, allowing you to connect to it via SSH.
Here’s a breakdown of the components:

resource "aws_key_pair" "jumphost_key": Defines a new AWS EC2 key pair resource named jumphost_key.
key_name = var.key_name: Sets the key pair’s name using the value provided in the key_name variable defined in variables.tf.
public_key = var.public_key: Passes your previously created public SSH key to AWS using the public_key variable.

IAM Role & Instance Profile

resource "aws_iam_role" "jumphost_role" {
 name = "jumphost_role"

 assume_role_policy = jsonencode({
   Version = "2012-10-17"
   Statement = [
     {
       Action = "sts:AssumeRole"
       Effect = "Allow"
       Sid    = ""
       Principal = {
         Service = "ec2.amazonaws.com"
       }
     },
   ]
 })

 tags = {
   tag-key = "jumphost_tag_value"
 }
}

# This is an AWS IAM policy

resource "aws_iam_role_policy_attachment" "administrator_access_attach" {
 role       = aws_iam_role.jumphost_role.name
 policy_arn = "arn:aws:iam::aws:policy/AdministratorAccess"
}

resource "aws_iam_instance_profile" "jumphost_instance_profile" {
 name = "jumphost_instance_profile"
 role = aws_iam_role.jumphost_role.name
}

This Terraform code block sets up IAM permissions for your jump host with three component blocks:

aws_iam_role "jumphost_role": The role includes a trust policy that allows EC2 instances to assume the role using the sts:AssumeRole action. The trusted service is ec2.amazonaws.com.
aws_iam_role_policy_attachment "administrator_access_attach": This block attaches the AWS-managed AdministratorAccess policy to the jumphost_role, granting it full administrative permissions.
aws_iam_instance_profile "jumphost_instance_profile": This block creates an instance profile that will link the IAM role to the jumphost EC2 instance

This profile can be attached to EC2 instances so they can inherit the role’s permissions at runtime.

EC2 Instance

# EC2 Instance
resource "aws_instance" "jumphost" {
 ami                         = data.aws_ami.ubuntu.id
 instance_type               = var.instance_type
 associate_public_ip_address = true
 key_name                    = aws_key_pair.jumphost_key.key_name
 vpc_security_group_ids      = [aws_security_group.jumphost_SG.id]
 subnet_id                   = aws_subnet.jumphost_subnet.id
 iam_instance_profile        = aws_iam_instance_profile.jumphost_instance_profile.name

 tags = {
   Name        = "Jumphost"
   Environment = var.environment
   Owner       = var.owner
 }

 user_data = file("../scripts/jumphost_init.sh")
}

This Terraform block provisions the EC2 instance that will serve as your jumphost. It brings together all the components you defined earlier and ties them into a single resource:

ami = data.aws_ami.ubuntu.id: Uses the Ubuntu AMI you previously retrieved to launch the instance.
instance_type = var.instance_type: Specifies the EC2 instance type based on your provided variable.
associate_public_ip_address = true: Assigns a public IP address to the instance, allowing direct access over the internet.
key_name = aws_key_pair.jumphost_key.key_name: Associates the instance with the SSH key pair for secure remote access.
vpc_security_group_ids = [aws_security_group.jumphost_SG.id]: Attaches the instance to the predefined security group, controlling inbound and outbound traffic rules.
subnet_id = aws_subnet.jumphost_subnet.id: Places the instance in the designated subnet.
iam_instance_profile = aws_iam_instance_profile.jumphost_instance_profile.name: Applies the IAM instance profile, granting the instance appropriate permissions.
tags = {...}: Adds metadata for organizational purposes—such as the instance name, environment, and owner.
user_data = file("../scripts/jumphost_init.sh"): Runs a startup script upon instance launch, allowing for automated configuration and initialization.

In summary, this block ties everything together to create a fully functional jumphost with networking, access control, permissions, and startup configuration all pre-configured.

Define your outputs in the `outputs.tf` file

The outputs.tf file allows you to expose key information about your infrastructure after running terraform apply. These outputs make it easy to retrieve critical values such as public IP addresses or instance IDs, useful for debugging, connectivity, or automation.

To define outputs for your jumphost, paste the following code into your outputs.tf file:

output "jumphost_public_ip" {
 description = "The public IP of the jumphost"
 value       = aws_instance.jumphost.public_ip
}

output "jumphost_ssm_instance_id" {
 description = "Instance ID for use with AWS SSM"
 value       = aws_instance.jumphost.id
}

Let’s break down what each output does:

output "jumphost_public_ip": This outputs the public IP address of the EC2 jumphost. It's particularly useful when you need to SSH into the instance or connect via tools that require the IP.
- description: This describes the purpose of the output function.
- value: Points to aws_instance.jumphost.public_ip, which fetches the actual IP address of the jumphost
output "jumphost_ssm_instance_id": This outputs the EC2 instance ID, a key value if you plan to use AWS Systems Manager (SSM) for session-based access, allowing you to connect without SSH keys.
- description: This describes the purpose of the output function.
- value: Refers to aws_instance.jumphost.id, which returns the unique identifier of the EC2 instance. This is useful for SSM sessions and automation scripts.

Creating the initialization script

Once your Terraform configurations for the EC2 instance are in place, the next step is to create an initialization script that runs after the instance is launched. This script prepares the jumphost for interacting with the AWS EKS cluster, whether for creating clusters or running monitoring tools like Prometheus and Grafana, by installing the necessary dependencies.

The required tools are:

kubectl: Command-line tool for managing Kubernetes clusters and workloads.
helm: Package manager for Kubernetes, used to install charts such as Prometheus, Grafana, nginx-ingress, and more.
eksctl: Utility for creating and managing EKS clusters, including the underlying infrastructure.
awscli: AWS Command Line Interface for authenticating and managing AWS resources.

Note: If you're not planning to follow the full tutorial series, you may safely skip this section.

To install these dependencies, copy and paste the following script into your scripts/jumphost_init.sh file:
https://gist.github.com/Iheanacho-ai/cd3833e34add7d1b7cc67257dbaef104

The script prepares the instance with tools and services needed for interacting with and managing an Amazon EKS (Kubernetes) cluster.

Here's a breakdown of what it does, step by step:

Script setup and logging

#!/bin/bash
# For Ubuntu 22.04

set -e # Exit script immediately on first error.

# Log all output to file
exec >> /var/log/init-script.log 2>&1

echo "Starting initialization script..."

What this does:

#!/bin/bash: Specifies Bash as the interpreter for this script.
set -e: Ensures the script halts on any error, preventing unintended consequences.
exec >> /var/log/init-script.log 2>&1: Logs all output, both standard and error, to /var/log/init-script.log for easier troubleshooting.

Update the operating system

# Update system
sudo apt update -y
sudo apt upgrade -y

The script above updates the system's package lists and upgrades all installed packages to their latest versions. This step helps prevent compatibility or security issues during subsequent installations.

Install AWS CLI

# Install AWS CLI
curl "https://awscli.amazonaws.com/awscli-exe-linux-x86_64.zip" -o "awscliv2.zip"
sudo apt install unzip -y
unzip awscliv2.zip
sudo ./aws/install
echo "AWS CLI installed. Remember to configure credentials with 'aws configure'"

The bash script block above:

Downloads the AWS CLI installation archive.
Installs the unzip utility if it’s not already present.
Extracts the archive and installs the CLI.
Prompts you to configure your credentials for AWS access.

Install kubectl (Kubernetes CLI)

# Install Kubectl
sudo apt update
sudo apt install curl -y
sudo curl -LO "https://dl.k8s.io/release/v1.28.4/bin/linux/amd64/kubectl"
sudo chmod +x kubectl
sudo mv kubectl /usr/local/bin/
kubectl version --client

This script installs the Kubernetes command-line tool, kubectl. It allows you to interact with and manage Kubernetes resources within your EKS cluster.

Install eksctl

curl --silent --location "https://github.com/weaveworks/eksctl/releases/latest/download/eksctl_$(uname -s)_amd64.tar.gz" | tar xz -C /tmp
sudo mv /tmp/eksctl /usr/local/bin
eksctl version

This script installs eksctl.

Install Helm

sudo snap install helm --classic

This command installs Helm, a powerful package manager for Kubernetes. You'll use Helm to deploy applications like Prometheus, Grafana, and NGINX Ingress using pre-configured packages called “charts.”

Add Helm repositories

helm repo add prometheus-community https://prometheus-community.github.io/helm-charts
helm repo add grafana https://grafana.github.io/helm-charts
helm repo add ingress-nginx https://kubernetes.github.io/ingress-nginx
helm repo update

These commands add external Helm repositories to your environment:

prometheus-community: for monitoring tools like Prometheus
grafana: for powerful visualization dashboards
ingress-nginx: for managing external access to your Kubernetes services

Finally, helm repo update refreshes the list of available charts so you can install the latest versions.

Install Prometheus

helm install prometheus prometheus-community/kube-prometheus-stack --namespace monitoring --create-namespace

This command installs Prometheus using the kube-prometheus-stack Helm chart into the monitoring namespace. If the namespace doesn't already exist, it will be created automatically.

Install Grafana

helm install grafana grafana/grafana --namespace monitoring --create-namespace

This command installs Grafana in the same monitoring namespace. Grafana provides a powerful dashboard interface to visualize metrics collected by Prometheus.

Installs NGINX Ingress Controller

helm install ingress-nginx ingress-nginx/ingress-nginx

The command above installs the NGINX Ingress Controller, which acts as a gateway for routing external HTTP and HTTPS traffic to services running inside your EKS cluster.

Finish Script

helm repo update
echo "Initialization script completed successfully."

This section:

Updates your local Helm chart repository cache, ensuring access to the latest versions of available charts.
Prints a confirmation message to indicate that the initialization script has finished running successfully.

Automating Terraform deployments with GitHub Actions

Once you’ve written your Terraform configuration and initialization script, the next step is to automate the deployment process using GitHub Actions. This ensures that any changes made to your Terraform files are automatically applied to your infrastructure, keeping everything up to date without manual intervention.

To set this up, create a GitHub Actions workflow by copying the following YAML snippet into your .github/workflows/terraform.yaml:

https://gist.github.com/Iheanacho-ai/9d71fe4759dc8621de97967958cd60a5

Here is a breakdown of the GitHub Actions pipeline:

Workflow Name:

name: Terraform Jumphost Configuration

This line gives your workflow a descriptive name, "Terraform Jumphost Configuration," which will be visible in your GitHub Actions tab.

Triggers (on):

on:
 push:
   branches:
     - main
   paths:
     - terraform/**
 pull_request:
   branches:
     - main
   paths:
     - terraform/**

This section defines when this workflow will be automatically triggered:

push: This means the workflow will run when code is pushed to the repository.
- branches: - main: Specifically, it will only trigger when commits are pushed to the main branch.
- paths: - terraform/*: It only runs if the changes affect any files or subdirectories inside the terraform/ directory. The * wildcard ensures all nested files are included.
pull_request: The workflow will also run when a pull request is created, updated, or merged.
- branches: - main: It will only trigger for pull requests that target the main branch.
- paths: - terraform/**: Similar to the push event, it only runs if changes are made within the terraform/ directory.

Environment Variables (env):

env:
 AWS_ACCESS_KEY_ID: ${{ secrets.AWS_ACCESS_KEY_ID }}
 AWS_SECRET_ACCESS_KEY: ${{ secrets.AWS_SECRET_ACCESS_KEY }}
 BUCKET_TF_STATE: ${{ secrets.BUCKET_TF }}
 AWS_REGION: ${{ secrets.AWS_REGION }}
 TF_LOG: DEBUG

This section defines environment variables that are accessible to all jobs within the workflow. Sensitive values are securely pulled from GitHub Secrets using the secrets context (secrets.NAME), ensuring credentials are not exposed in plain text.
Here's what each variable does:

AWS_ACCESS_KEY_ID: Stores your AWS access key ID, securely retrieved from GitHub Secrets.
AWS_SECRET_ACCESS_KEY: Stores your AWS secret access key, also pulled from Secrets.
BUCKET_TF_STATE: Specifies the name of the S3 bucket where your Terraform state file will be stored.
AWS_REGION: Sets the AWS region for your operations (e.g., us-east-1).
TF_LOG: Enables debug-level logging for Terraform, which provides detailed output useful for troubleshooting.

Jobs (jobs):

 terraform:
   name: "Apply Terraform configuration on changes"
   runs-on: ubuntu-latest
   defaults:
     run:
       shell: bash
       working-directory: ./terraform

This section defines the tasks, called "jobs", that will be executed in your GitHub Actions workflow. In this case, there's a single job named terraform:

name: "Apply Terraform configuration on changes": A descriptive name for the job.
runs-on: ubuntu-latest: Specifies that the job will run in a clean, virtual machine hosted on the latest version of Ubuntu provided by GitHub Actions.
defaults: Defines default settings for all run steps within this job.
- shell: bash: Ensures that the commands in the run steps are executed using the Bash shell.
- working-directory: ./terraform: Sets the current working directory for all subsequent run steps within this job to the terraform directory in your repository. This is crucial because your Terraform configuration files are located there.

Steps (steps):

   steps:
   - name: Checkout code
     uses: actions/checkout@v4

   - name: Setup Terraform
     uses: hashicorp/setup-terraform@v3

   - name: Terraform Init
     run: terraform init -backend-config="bucket=$BUCKET_TF_STATE"

   - name: Terraform Format
     run: terraform fmt -check
     continue-on-error: true

   - name: Terraform Validate
     run: terraform validate

   - name: Terraform Plan
     id: plan
     run: terraform plan -no-color -input=false -out planfile
     continue-on-error: true

   - name: Terraform Plan Status
     if: steps.plan.outcome == 'failure'
     run: exit 1

   - name: Terraform Apply
     if: github.ref == 'refs/heads/main' && github.event_name == 'push'
     run: terraform apply -auto-approve -input=false -parallelism=1 planfile

This section defines the individual steps that will be executed within the terraform job, in sequential order:

Checkout code: This step leverages the official actions/checkout action (version 4) to clone your repository into the GitHub Actions runner, making your code available for the workflow.
Setup Terraform: Here, the hashicorp/setup-terraform action (version 3) is used to install and configure the Terraform CLI on the runner environment.
Terraform Init: This command initializes Terraform and configures the backend. Specifically, it uses the -backend-config option to point to your S3 bucket ($BUCKET_TF_STATE) where the Terraform state is stored securely.
Terraform Format: The terraform fmt-check command verifies that your Terraform code conforms to the standard formatting conventions.The setting continue-on-error: true allows the workflow to proceed even if formatting issues are detected, preventing the entire job from failing at this stage.
Terraform Validate: This step runs terraform validate to ensure that the Terraform configuration files are syntactically correct and internally consistent.
Terraform Plan: This generates an execution plan with the command terraform plan -no-color -input=false -out planfile.
- -no-color disables colored output for clearer logs.
- -input=false prevents Terraform from prompting for input interactively.
- -out planfile saves the generated plan to a file named planfile, ensuring that the apply step runs exactly what was planned.
- Similar to the formatting step, continue-on-error: true lets the workflow continue even if the plan generation encounters errors.
Terraform Plan Status: This step acts as a gatekeeper by checking the outcome of the plan step. If the plan failed (steps.plan.outcome == 'failure'), it runs exit 1 to terminate the job immediately, preventing a potentially harmful apply.
Terraform Apply: The final step applies the Terraform changes, but only when two conditions are met:
- The workflow was triggered by a push to the main branch (github.ref == 'refs/heads/main').
- The event type is a push event (github.event_name == 'push').
- The command terraform apply -auto-approve -input=false -parallelism=1 planfile applies the saved execution plan:
- -auto-approve skips manual confirmation.
- -input=false avoids interactive prompts.
- -parallelism=1 limits resource creation/modification to one at a time to avoid race conditions or ordering issues, though it may slow execution.

Running your CI/CD pipeline

Once you’ve configured your pipeline, the next step is to trigger it to create the Terraform infrastructure. To do so, push your code to GitHub. GitHub will automatically detect your push, read your .github/workflows file, and run the pipeline.

Refer to the GitHub documentation for guidance on pushing your locally hosted code to GitHub.

After pushing your code, go to your project repository on GitHub and click on the Actions tab to monitor your workflow.

Note: If you do not see any workflow in the Actions tab, double-check the folder name and make sure your terraform.yaml file is correctly located in the workflow folder within the .github directory.

Once the workflow completes, your infrastructure should be provisioned.

Verify and review your project

To confirm that Terraform has successfully provisioned your infrastructure, follow these steps:

Sign in to your AWS Console: Access your AWS console, then search for "EC2" in the search bar.
Check for Your EC2 Instance: After searching, you should see your EC2 instance listed in the console.
Get Your EC2 Instance's Public IP: To SSH into your EC2 instance, you need the public IP address. You can find this in your AWS console or from your GitHub workflow. In this case, we'll retrieve it from the GitHub workflow.

To get the public IP address from the GitHub workflow:
a. Click on your workflow run in the Actions page

b. Select your Job on the sidebar

    c. Expand the Terraform Apply step.

d. Scroll to the end of the step, and you should see thejumphost_public_ip value in the outputs section.

e. Copy this value; it’s your EC2 instance's public IP.

5.SSH into Your EC2 Instance: Now that you have the public IP, you can SSH into your EC2 instance. Use the following command:

ssh -i <path to your public key> ubuntu@<public_ip>

Replace the placeholders:

: This is the location of the key you created earlier, typically ~/.ssh/<name of the key>.
: This is the public IP you copied from the GitHub workflow.

For example, if your key's path is ~/.ssh/key and your public IP is 3.81.145.221, the command would look like this:

ssh -i ~/.ssh/key ubuntu@3.81.145.221

With this, you should now be logged into your EC2 instance, provisioned by Terraform.

Final thoughts

Terraform enables consistent provisioning, management, and versioning of infrastructure across multiple cloud providers. Regardless of who runs the pipeline that triggers the Terraform configuration you set up in this tutorial, the infrastructure will always be identical, with the same configuration. By automating these processes, Terraform reduces the potential for manual errors, boosts efficiency, and ensures your infrastructure is reproducible and scalable.

In this tutorial, you’ve created a jumphost on AWS, a secure server that will facilitate controlled and secure access to an EKS cluster you’ll set up later in the series.

But this is just the beginning of what you can achieve with Terraform and AWS. To dive deeper, check out the official Terraform with AWS documentation.

Automate testing and Docker image deployment to Amazon ECR with CI.

Amarachi Iheanacho — Thu, 26 Jun 2025 12:54:03 +0000

The frequency and speed of releases in modern software development requires robust CI/CD pipelines that ensure code quality, security, and reliable deployments. These pipelines eliminate the errors, that spring up from manual integration development and deployment, some of which are due to inefficient and insufficient testing, and some are just due to human errors from performing the same steps a million times.

In this article you'll build a comprehensive continuous integration(CI) pipeline that automatically tests your application, performs security scans, and pushes Docker images to Amazon ECR (Elastic Container Registry). It is the second part of this four-part DevSecOps series.

This pipeline implements DevSecOps best practices by integrating security at every stage, from code quality analysis with SonarCloud to vulnerability scanning with Snyk and Trivy. By the end of this guide, you'll have a production-ready pipeline that automatically validates your application before containerizing and storing it securely in AWS.

What this series contains

This four-part series walks you through building a modern DevSecOps pipeline for a containerized quiz application:

Provision a secure EC2 jumphost using Terraform and GitHub Actions (previous article)
Build a CI pipeline that tests your application and pushes Docker images to Amazon ECR (this article)
Set up an Amazon EKS cluster and deploy the application with ArgoCD
Add monitoring and observability using Prometheus and Grafana

Prerequisites

Ensure you have the following before proceeding with this article:

Completed the first part of the series. You should have a secure EC2 jumphost provisioned using Terraform and GitHub Actions
A basic understanding of Docker and containerization.

Project structure overview

This project will build on the EC2 jumphost project you had from the first part of the series.

So create a ci.yaml file in your .github/workflows folder. This file will hold the code for the CI pipeline responsible for testing, validating and pushing your application to the Amazon ECR repository. Your complete file structure should look like this:

.
├── backend/
├── frontend/
├── .github/
│   └── workflows/
│       ├── terraform.yaml
│       └── ci.yaml (new)
├── terraform/
└── scripts/

Pre-project setup checklist

Before getting right into building your CI pipeline you need to do the following:

Set up your AWS ECR repositories
Set up SonarCloud for your repository
Set up Snyk

Follow the rest of this section to complete the steps above.

Set up your AWS ECR repositories

The Amazon ECR repositories will hold the frontend and backend Docker images your CI pipeline would create.

You need your AWS account ID, and your AWS ECR repositories to effectively push your Docker images.

Get your account ID:

Sign in to your AWS Console.
Click your account name at the top right corner of the navigation bar
Copy your account ID from the dropdown menu.

Create your ECR repositories:

Search and navigate to Elastic Container Registry (ECR) in your console.
Create repositories for both frontend and backend by doing the following:

a.Click Create repository

b.Set Repository name to frontend.
c.Leave the remaining settings as default and click the Create button*.*

d. Repeat the steps above to create a second repository named backend.

Set up SonarCloud

SonarCloud provides code quality analysis, helping you identify bugs and vulnerabilities in the code you plan to package. To enable SonarCloud, you'll need four things: a SonarCloud account and project, a SonarCloud token, an organization token, and a SonarCloud project key.

Do the following to get your SonarCloud all set up:

Create a SonarCloud account and project:
1. Sign up for a free SonarCloud account using your GitHub account
2. Click on Analyze new project to import your organization
3. Select the quiz-application repository that will hold your CI pipeline (this is the same GitHub repository from part 1)
4. Select a new code definition to define what SonarCloud would define as new code.
5. Click the Create project button.
Generate a SonarCloud token:
1. Select your account’s icon at the top right of the page
2. Go to My Account → Security
3.Enter the name of your token
4.Select the Generate Token button to create the token
5.Copy the token
Get your organization key:
1. Select your account’s icon at the top right of the page
2. Select your organization (the same one that holds the quiz application GitHub repository)
3.Copy your organization key from the top right corner of the webpage.
Get a SonarCloud project key:
1. Select your organization
2. Select the project that holds your quiz-application repository.
3. Navigate to Administration -> Update Key.
4.Copy your Project Key.

Important: After setting up, make sure to disable automatic analysis to avoid conflicts with your CI configuration.

Disable automatic analysis
SonarCloud recommends using only one analysis method (either CI-based or automatic) to avoid duplicate results and conflicts.

Since you’re configuring analysis through a CI pipeline, you must disable Automatic Analysis for your project.

Here is how to do it:

Select your project
Navigate to Administration -> Analysis method
Toggle the Automatic Analysis button to disable automatic analysis.

Set up Snyk

Snyk scans for security vulnerabilities in your dependencies and Docker images.

Do the following to get a Snyk Auth Token for authenticating your CI pipeline:

Create a Snyk account.
Select the Choose integration option and connect Snyk to your GitHub repository.
Select your account at the bottom of the sidebar .
Select Account settings
Copy your authentication token from the Auth Token section

Configure your GitHub secrets

Now that you have all your credentials, add them to your GitHub secrets so that your CI pipeline can pull them into the workflow:

Select your project’s GitHub repository.
Navigate to the Settings → Secrets and variables → Actions
Click on New repository secret and add the following secrets, replacing the place holders with your actual values :
- AWS_ACCOUNT_ID: your-account-id
- SONAR_TOKEN: your-sonarcloud-token
- SONAR_ORGANIZATION_KEY: your-sonarcloud-org-key
- SONAR_URL: https://sonarcloud.io
- SONAR_PROJECT_KEY: your-project-key
- SNYK_TOKEN: your-snyk-api-token

Understanding the CI/CD pipeline architecture

Now that you have the file structure in place and your credentials set up, it's important to understand what this CI pipeline does.

The pipeline implements a comprehensive DevSecOps workflow with the following stages:

Code Testing: Runs unit tests, linting, and formatting checks.
Quality Analysis: Performs code quality scanning using SonarCloud.
Security Scanning: Assesses source code vulnerabilities with Snyk.
Container Building: Builds a Docker image and pushes it to Amazon ECR.
Image Security: Scans the Docker image for vulnerabilities using Trivy and Snyk.

The pipeline is triggered on both pull requests and pushes to the main branch, ensuring code quality and security throughout the development process.

Building the CI/CD workflow

With your project structure, credentials and basic knowledge of the CI pipeline all setup, copy and paste this code in your .github/workflow/ci-cd.yaml file.

https://gist.github.com/Iheanacho-ai/2ee426b821ddc2058c76956fafeb399e

After completing this section, your pipeline will be fully set up. When it runs, your applications will be tested, built into Docker images, tested again, and then pushed to AWS ECR.

But now, let's understand exactly what you just created.

Pipeline breakdown and analysis

Here is the breakdown of the pipeline in stages:

Stage 1: Application testing

The pipeline begins by thoroughly testing both the frontend and backend applications using the frontend-test and backend-test jobs.

Frontend testing through the **frontend-test** job

 frontend-test:
   runs-on: ubuntu-latest
   defaults:
     run:
       working-directory: ./frontend
   strategy:
     matrix:
       node-version: [20.x]
       architecture: [x64]
   steps:
     - name: Check-out git repository
       uses: actions/checkout@v4

     - name: USE NODEJS ${{ matrix.node-version }} - ${{ matrix.architecture }}
       uses: actions/setup-node@v4

     - name: Install project dependencies
       working-directory: ./frontend
       run: |
         npm i
        npm run lint
        npm install --save-dev --save-exact prettier
        npm run prettier
        npm test
       env:
         CI: true

     - name: Build
       run: npm run build
       working-directory:
         ./frontend

     - name: Analyze with SonarCloud
       uses: sonarsource/sonarcloud-github-action@v5.0.0
       env:
         SONAR_TOKEN: ${{ secrets.SONAR_TOKEN }}
       with:
         projectBaseDir: frontend
         args: >
           -Dsonar.organization=${{ secrets.SONAR_ORGANIZATION_KEY }}
          -Dsonar.projectKey=${{ secrets.SONAR_PROJECT_KEY }}
          -Dsonar.host.url=${{ secrets.SONAR_URL }}
          -Dsonar.login=${{ secrets.SONAR_TOKEN }}
          -Dsonar.sources=src/
          -Dsonar.verbose=true

In the code block above the frontend-test job runs tests on the frontend application with the following steps:

Check-out git repository: Uses the actions/checkout@v4 action to check out the frontend application code into the GitHub Actions runner.
USE NODEJS ${{ matrix.node-version }} - ${{ matrix.architecture }}: Sets the environment to use Node.js 20.x on Ubuntu
Install project dependencies: This step does the following:
- Sets the working-directory to /frontend
- Installs all the npm dependencies required to run your application
- Runs ESLint for code linting and Prettier for formatting
- Executes test suites with npm test
Build: Compiles the frontend application using the npm run build command
Analyze with SonarCloud: Uses the sonarsource/sonarcloud-github-action@v5.0.0 action to perform static code analysis, identifying bugs, vulnerabilities, and code smells. Refer to the SonarSource project available as a GitHub Action resource for more information on using SonarCloud in your GitHub Actions workflow.

Backend testing through the **backend-test** job

 backend-test:
   runs-on: ubuntu-latest
   defaults:
     run:
       working-directory: ./backend
   strategy:
     matrix:
       node-version: [20.x]
       architecture: [x64]
   steps:
     - name: Check-out git repository
       uses: actions/checkout@v4

     - name: USE NODEJS ${{ matrix.node-version }} - ${{ matrix.architecture }}
       uses: actions/setup-node@v4

     - name: Install project dependencies
       working-directory: ./backend
       run: |
         npm i
        npm run lint
        npm install --save-dev --save-exact prettier
        npm run prettier
        npm test
       env:
         CI:
           true

           # Setup sonar-scanner
     - name: Setup SonarQube
       uses: warchant/setup-sonar-scanner@v8

     - name: Analyze with SonarCloud
       uses: sonarsource/sonarcloud-github-action@v5.0.0
       env:
         SONAR_TOKEN: ${{ secrets.SONAR_TOKEN }}
       with:
         projectBaseDir: backend
         args: >
           -Dsonar.organization=${{ secrets.SONAR_ORGANIZATION_KEY }}
          -Dsonar.projectKey=${{ secrets.SONAR_PROJECT_KEY }}
          -Dsonar.host.url=${{ secrets.SONAR_URL }}
          -Dsonar.login=${{ secrets.SONAR_TOKEN }}
          -Dsonar.sources=.
          -Dsonar.verbose=true

The backend-test above mirrors the frontend-test job to run lints and comprehensive testing for the backend application.

Step 2: Security scanning

After successfully testing the application code, the pipeline proceeds to scan both the frontend and backend applications for security vulnerabilities using the frontend-security and backend-security jobs, respectively.

Frontend security with frontend-security job

 frontend-security:
   needs: frontend-test
   runs-on: ubuntu-latest
   defaults:
     run:
       working-directory: ./frontend
   steps:
     - name: Checkout frontend code
       uses: actions/checkout@master
     - name: Run Snyk to check for vulnerabilities
       uses: snyk/actions/node@master
       continue-on-error: true
       env:
         SNYK_TOKEN: ${{ secrets.SNYK_TOKEN }}

     - name: Install Snyk CLI
       uses: snyk/actions/setup@master
       with:
         version: latest
       env:
         SNYK_TOKEN: ${{ secrets.SNYK_TOKEN }}

     - name: Snyk Authenticate
       run: snyk auth ${{ secrets.SNYK_TOKEN }}

     - name: Snyk Code Test
       run: snyk code test --all-projects
       continue-on-error: true

The frontend-security job runs on Ubuntu and starts only after the frontend-test job has completed.
It performs a security vulnerability scan on the frontend application using the following steps:

Checkout frontend code: Checks out the frontend application code into the GitHub Actions runner.
Run Snyk to check for vulnerabilities:Uses the snyk/actions/node@master action to scan for security issues. The continue-on-error: true setting ensures that the job won’t fail even if vulnerabilities are detected.
Install Snyk CLI: Installs the latest version of the Snyk Command Line Interface tool.
Snyk Authenticate: Authenticates the Snyk CLI with the provided token from GitHub Secrets.
Snyk Code Test: Runs static code analysis on all projects in the frontend directory to detect vulnerabilities.

Backend security with backend-security job

 backend-security:
   needs: backend-test
   runs-on: ubuntu-latest
   defaults:
     run:
       working-directory: ./backend
   steps:
     - name: Checkout backend code
       uses: actions/checkout@master
     - name: Run Snyk to check for vulnerabilities
       uses: snyk/actions/node@master
       continue-on-error: true # To make sure that SARIF upload gets called
       env:
         SNYK_TOKEN: ${{ secrets.SNYK_TOKEN }}

     - name: Install Snyk CLI
       uses: snyk/actions/setup@master
       with:
         version: latest
       env:
         SNYK_TOKEN: ${{ secrets.SNYK_TOKEN }}

     - name: Snyk Authenticate
       run: snyk auth ${{ secrets.SNYK_TOKEN }}

     - name: Snyk Code Test
       run: snyk code test --all-projects
       continue-on-error: true

The backend-security job mirrors the frontend-security job and runs vulnerability scans on the backend application.

   defaults:
     run:
       working-directory: ./backend

Stage 3: Container image creation and security

This stage builds the frontend and backend applications into Docker images, pushes them to the AWS ECR repository, and then scans the images for security vulnerabilities using Trivy and Snyk.

Build, validate and push your frontend docker image with the frontend image job

https://gist.github.com/Iheanacho-ai/e8672ae025e5d4ec5be3646f42534027

The frontend-image job consists of a job definition and a series of steps that build the Dockerfile located in your frontend directory and push the resulting image to your frontend AWS ECR repository.

Below is a breakdown of the job definition and its steps.

Frontend-image job definition:

 frontend-image:
   needs: frontend-security
   runs-on: ubuntu-latest
   permissions:
     contents: read
     security-events: write
     actions: read
     id-token: write

This code block above specifies the following:

needs: frontend-security: Specifies that the job will only run after the frontend-security job completes successfully
permissions: Specifies the permissions required for this job, including:
- contents: read: Allows the job to read the repository content
- security-events: write: Enables uploading of vulnerability scan results.
- actions: read: Grants read access to GitHub Actions metadata.
- id-token: write: Allows the use of OpenID Connect (OIDC) tokens.

Once the environment is set up, the next step is to define the actions the frontend-image job will take, specifically, building and pushing the Docker image to a container registry and validating its security.

Frontend-image job steps

Here are the steps the job takes to build, push and scan the Docker images:

   steps:
     - name: Checkout the application code
       uses: actions/checkout@v4

     - name: Configure AWS credentials
       uses: aws-actions/configure-aws-credentials@v4
       with:
         aws-access-key-id: ${{ secrets.AWS_ACCESS_KEY_ID }}
         aws-secret-access-key: ${{ secrets.AWS_SECRET_ACCESS_KEY }}
         aws-region: ${{ secrets.AWS_REGION }}

     - name: Build and push frontend Docker image to ECR
       working-directory: ./frontend
       run: |
         aws ecr get-login-password --region ${{ secrets.AWS_REGION }} | docker login --username AWS --password-stdin ${{ secrets.AWS_ACCOUNT_ID }}.dkr.ecr.${{ secrets.AWS_REGION }}.amazonaws.com
        IMAGE_URI=${{ secrets.AWS_ACCOUNT_ID }}.dkr.ecr.${{ secrets.AWS_REGION }}.amazonaws.com/frontend
        docker build -t ${IMAGE_URI}:latest .
        docker push ${IMAGE_URI}:latest

     - name: Run Trivy vulnerability scanner
       uses: aquasecurity/trivy-action@master
       with:
         image-ref: "${{ secrets.AWS_ACCOUNT_ID }}.dkr.ecr.${{ secrets.AWS_REGION }}.amazonaws.com/frontend:latest"
         format: "sarif"
         output: "trivy-results.sarif"
         severity: "CRITICAL,HIGH"

     - name: Install Snyk CLI
       uses: snyk/actions/setup@master
       with:
         snyk-token: ${{ secrets.SNYK_TOKEN }}

     - name: Snyk Authenticate
       run: snyk auth ${{ secrets.SNYK_TOKEN }}

     - name: Snyk Container monitor
       run: snyk container monitor ${{ secrets.AWS_ACCOUNT_ID }}.dkr.ecr.${{ secrets.AWS_REGION }}.amazonaws.com/frontend:latest --file=Dockerfile
       working-directory: ./frontend

     - name: Run Snyk to check for vulnerabilities in the Docker image
       uses: snyk/actions/docker@master
       with:
         image: ${{ secrets.AWS_ACCOUNT_ID }}.dkr.ecr.${{ secrets.AWS_REGION }}.amazonaws.com/frontend:latest
         args: --file=frontend/Dockerfile --severity-threshold=high
       env:
         SNYK_TOKEN: ${{ secrets.SNYK_TOKEN }}
       continue-on-error: true

The frontend-image job does the following:

Configure AWS credentials: Sets up AWS credentials from GitHub Secrets so the job can interact with ECR.
Build and push frontend Docker image to ECR: This step authenticates Docker with AWS ECR, builds the Docker image, and pushes it to your ECR repository. It includes:
- aws ecr get-login-password ... | docker login ...: Logs into Amazon ECR using a token generated by AWS.
- IMAGE_URI…: Defines the full Docker image URI, pointing to your ECR repo.
- docker build -t ${IMAGE_URI}:latest .: Builds the Docker image from the ./frontend directory and tags it as <your-ecr-repo>:latest.
- docker push ${IMAGE_URI}:latest: Uploads the latest version of your image to the frontend repository in ECR
Run Trivy vulnerability scanner: Scans the pushed Docker image for known vulnerabilities using Trivy and outputs the results in SARIF format.
Install Snyk CLI: Installs the Snyk CLI tool to perform additional security checks.
Snyk Authenticate: Logs into Snyk using your Snyk token from GitHub Secrets.
Snyk Container monitor: Uploads the Docker image to Snyk for continuous monitoring and alerting about new vulnerabilities as they are discovered.
Run Snyk to check for vulnerabilities in the Docker image: Performs a vulnerability scan of the frontend:latest Docker image in ECR. The workflow will continue even if high-severity issues are detected.

Build, validate and push your backend docker image with the **backend image** job

https://gist.github.com/Iheanacho-ai/dabc139fe35d496fa45eb2e6bca01278

The backend-image job mirrors the frontend-image job, but operates on the backend service. It builds, scans, and pushes the Docker image from the ./backend directory to the backend repository in AWS ECR.

Running your pipeline

Once you’ve configured your pipeline, the next step is to trigger it to build, test, and push your Docker images to AWS ECR. To do this, simply push your code to GitHub. GitHub will automatically detect the push, read the .github/workflows file, and run the pipeline.

Refer to the GitHub documentation if you are unsure how to push your local code to GitHub.

After pushing your code, navigate to your project repository on GitHub and click the Actions tab to monitor your workflow.

Note: If you don’t see any workflows under the Actions tab, double-check that the ci.yaml file is placed correctly in the .github/workflows directory. Make sure there are no typos in folder or file names.

Once the workflow runs successfully, your Docker images will be available in the AWS ECR service.

What's next

With your CI/CD pipeline now successfully building and pushing secure Docker images to Amazon ECR, you're ready to move on to the next phase of the series.

In Part 3, you will:

Set up an Amazon EKS cluster using the jumphost from Part 1
Deploy your applications using the Docker images built in this pipeline
Implement GitOps practices with ArgoCD for automated deployments

This pipeline lays the foundation for your DevSecOps workflow, ensuring that only tested, secure, and validated code is deployed to production.

Final thoughts

Building a comprehensive CI/CD pipeline requires balancing speed, security, and reliability. This pipeline demonstrates how to integrate multiple security tools and best practices while maintaining development velocity. The automated testing, security scanning, and containerization process ensures that your applications are production-ready and secure.

Remember to regularly update your dependencies, review security scan results, and continuously improve your pipeline based on your team's needs and security requirements. The DevSecOps approach implemented here provides a solid foundation for scalable, secure application delivery.

In the next article, you’ll leverage these Docker images to deploy your application to a fully managed Kubernetes cluster with ArgoCD, completing the deployment automation loop.

What are Helm charts?

Amarachi Iheanacho — Sun, 20 Apr 2025 17:47:14 +0000

Package managers have been the norm throughout different fields of software engineering, from npm in JavaScript to pip in Python. They help simplify the installation, configuration, upgrade, and sharing of software and its dependencies, and Helm charts are no different.

When you deploy applications to Kubernetes, it often means managing dozens of YAML files for deployments, services, ingress rules, and configuration. And as your app grows, so does the complexity, making it harder to maintain consistency, update values, or replicate environments. This manual process can quickly become error-prone and time-consuming.

Helm addresses this challenge by packaging all those Kubernetes resources into a single, versioned chart. With Helm:

All the Kubernetes objects for your app live in a single chart.
You use values.yaml to customize configs per environment without editing the templates.
You can install or upgrade your entire app stack with a single command:

helm install myapp ./myapp-chart

You can publish your chart to a shared repository and let others reuse it with different configs.

In short, Helm charts bring the familiar benefits of package management, templating, and lifecycle automation to Kubernetes. They help teams standardize deployments, eliminate unnecessary duplication, and move faster — all while preserving the power and flexibility of Kubernetes itself. This article walks you through what Helm charts are, how they work, and how you can start using and creating them with confidence.

Prerequisites

To get the most out of this article, make sure you have the following in place:

A GitHub account. If you don’t have one, create a GitHub account here.
An Artifact Hub account. You can sign up for a free Artifact Hub account here.
A basic understanding of Git.
A basic understanding of Kubernetes.
A running Kubernetes cluster. You can use tools like Minikube, Kind, or any cloud provider such as AWS EKS, Google GKE, or Azure AKS.
Helm installed. To verify that Helm is installed, run the following command in your terminal:

helm version

You should see version information printed in your terminal if Helm is installed correctly:

Refer to the official documentation to install Helm if it is not already installed.

Core Helm concepts

Before diving into building and using Helm charts, it's important to understand some core concepts: Charts, Releases, Config, and Repositories. These are the building blocks that make Helm powerful and flexible for managing Kubernetes applications.

Chart: A Helm chart is a package that contains all the necessary files to describe a Kubernetes application, including templates for deployments, services, and other resources. Think of it as a blueprint for your app that can be reused, versioned, and shared.
Release: A release is an instance of a chart that has been deployed to a Kubernetes cluster. You can deploy the same chart multiple times with different configurations, and Helm will manage each as a separate release with its own lifecycle.
Config: Configurations in Helm are defined using a values.yaml file. This file lets you override default settings in the chart templates — such as replica counts, image tags, or environment-specific variables — without changing the chart structure itself.
Repository: A Helm repository is a place where charts are stored and made available for installation. Similar to npm or PyPI, you can publish your own charts or pull charts from public sources like ArtifactHub to quickly deploy popular open-source tools.

Helm chart anatomy

Understanding the structure of a Helm chart is essential for both using and creating charts effectively. Helm follows a standardized directory layout that organizes your Kubernetes manifests, configuration defaults, metadata, and dependencies.

Let’s explore each component of a typical Helm chart.

Directory structure

Here’s what a typical Helm chart folder looks like:

myapp-chart/
├── Chart.yaml
├── values.yaml
├── templates/
├── charts/
└── README.md (optional)

Chart.yaml: This file contains metadata about the chart, including its name, version, description, and maintainers. Helm uses this information to identify and manage the chart.

name: myapp
version: 0.1.0
description: A Helm chart for deploying MyApp

values.yaml: This file defines the default configuration values used by the templates in the chart. These values control various aspects of your Kubernetes resources, for example:

Which Docker image to use
The number of replicas
Exposed ports
Environment variables
Type of Kubernetes service (ClusterIP, LoadBalancer, etc.)

You can override these values at install time using the --values flag or --set on the command line, making the chart highly customizable and reusable across different environments.

Example:

replicaCount: 2
image:
  repository: myapp
  tag: latest

templates/: This directory contains Go template files that define the Kubernetes resources Helm will generate and deploy. Common files include:

deployment.yaml
service.yaml
ingress.yaml
configmap.yaml
hpa.yaml

These files resemble standard Kubernetes manifests but use template syntax ({{ ... }}) to inject dynamic values from values.yaml.

When you run:

helm install my-app ./my-chart

Helm reads values.yaml, plugs the values into the templates, and generates valid Kubernetes YAML.

To understand what a Helm template looks like, check out this demo deployment template.

In the deployment template, here are some of the most common things you will see:

include "template.name" . : Calls a reusable helper template (defined in _helpers.tpl), passing in the current context (.).
.Values: References values from values.yaml, or overrides via --set. Example: .Values.image.repository.
.Chart: Accesses the chart metadata. Example: .Chart.Name, .Chart.AppVersion.
.Template: Information about the current template file.
with <value>: Changes the context (.) inside the block to the given value.
if / else / end : Conditional logic. Example: {{ if .Values.autoscaling.enabled }}
toYaml: Converts an object to YAML format.
nindent: Indents lines to preserve YAML structure.

Other templates you would see in the templates/ folders are:

service.yaml – Defines how your app is exposed within or outside the cluster.
ingress.yaml – Configures domain-based access via Kubernetes Ingress.
_helpers.tpl – Stores reusable template snippets for labels, names, etc.
serviceaccount.yaml – Creates a ServiceAccount for access to the Kubernetes API.
hpa.yaml – Configures horizontal pod autoscaling.
configmap.yaml – Injects non-sensitive configuration into your pods.
secret.yaml – Injects sensitive data like credentials or API keys.
tests/ – Contains Helm test hooks to validate that the chart works after installation.
NOTES.txt – Provides post-installation instructions or tips displayed in the CLI.

Each of these templates can dynamically adjust based on values in the values.yaml file.

charts/: This optional directory is where you can include other Helm charts as dependencies (subcharts). For example, if your app relies on a PostgreSQL database, you can include the PostgreSQL chart here.

README.md (optional): Although not required, it’s a good practice to include a README.md file to document what the chart does, how to install it, configuration options, and usage examples. This is especially helpful when sharing your chart with others.

Installing and using a Helm chart

To better understand Helm charts and their significance, let's walk through creating one by templatizing a simple HTML web server built with Nginx. This server simply serves a static webpage that says:

“Hello, world! I hope you're getting the hang of this Helm chart business.”

Step 1: Create a Helm chart
Start by generating the chart structure with the following command:

helm create nginx-chart
cd nginx-chart

This command creates a folder named nginx-chart containing the standard Helm chart directory structure.

Step 2: Update the values.yaml File
In the root directory of your nginx-chart project, locate the values.yaml file. Open it and update the following values with the content below:

image:
  repository: amaraiheanacho/nginx-site
  pullPolicy: IfNotPresent
  tag: "latest"
service:
  type: NodePort
  port: 80

These values define the image source and how the service will be exposed.

Step 3: Confirm the template references
Go into the templates/ folder and review the deployment.yaml and service.yaml templates to ensure they correctly reference the values defined in values.yaml.

In the deployment.yaml template, you should see something like:

image: "{{ .Values.image.repository }}:{{ .Values.image.tag | default .Chart.AppVersion }}"
imagePullPolicy: {{ .Values.image.pullPolicy }}
ports:
  - name: http
    containerPort: {{ .Values.service.port }}
    protocol: TCP

Explanation:

image: References the image repository and tag from values.yaml — in this case, amaraiheanacho/nginx-site:latest.
imagePullPolicy: Uses the value of image.pullPolicy from values.yaml, typically set to IfNotPresent.
containerPort: Retrieves the port number (e.g., 80) from service.port in values.yaml.

While in the deployment.yaml file, you should see something like:

spec:
  type: {{ .Values.service.type }}

Explanation:

type: Uses the service.type value from values.yaml, which is NodePort. This makes your Nginx server accessible externally.

With these steps complete, you now have a working Helm chart for your Nginx web server.

Deploying the Helm chart

Once you have configured the values for your chart, you can deploy it to your Kubernetes cluster using the following command, replacing the :

helm install my-nginx-release <path to nginx-chart>

This command installs the chart as a release named my-nginx-release (you can use any name you prefer), using the configuration from the nginx-chart directory.

Viewing your application

If you're using Minikube, you can access the application directly with the following command:

minikube service <release-name>-<chart-name>

For example, if your release is named my-nginx-release and your chart is named nginx-chart, the command would be:

minikube service my-nginx-release-nginx-chart

This command opens the app in your default browser using Minikube’s service tunneling.

If you’re using any other Kubernetes cluster, use the following commands to retrieve the external URL of your app:

export NODE_PORT=$(kubectl get --namespace default -o jsonpath="{.spec.ports[0].nodePort}" services nginx-site)
export NODE_IP=$(kubectl get nodes --namespace default -o jsonpath="{.items[0].status.addresses[0].address}")
echo http://$NODE_IP:$NODE_PORT

This will output the full URL to access your deployed application.

Upgrading and rolling back releases

Once deployed, you can update your Helm chart and roll out changes in your release with:

helm upgrade my-nginx-release ./nginx-chart

This command applies any new changes in the chart (like updated images or values) to the existing release.

If something breaks during an upgrade, you can roll back to a previous version:

helm rollback my-nginx-release [REVISION]

To view available revisions, run:

helm history my-nginx-release

This will list the release history, including version numbers you can roll back to.

Upload your Helm chart to a repository

A Helm chart repository is a location where developers publish Helm charts, allowing others to easily install and deploy applications without needing to write code from scratch. One such popular registry is Artifact Hub, which you'll use in this tutorial.

To publish your Helm chart to Artifact Hub, follow these steps:

Step 1: Ensure that you are currently in your project’s directory
If you're not already in your Helm chart project directory (the one that contains the Chart.yaml file), change to it using:

cd <name of the project>

Step 2: Push your project to a GitHub repository
First, push your project to a public GitHub repository. Artifact Hub doesn't store charts directly—it indexes them from externally hosted, Helm-compatible repositories. GitHub Pages is a popular and simple option for this.

Check out the Pushing your first project to GitHub guide if you are new to GitHub.

Step 3: Package your Helm chart
Next, you need to package your Helm chart so it can be distributed and recognized by Helm.

1.From your chart's root directory, run the following command to generate a .tgz file (e.g., nginx-chart-0.1.0.tgz).

helm package .

2.Then, create an index.yaml file that references your packaged chart:

helm repo index . --url https://<GitHub-username>.github.io/<repository-name>

Replace:

<GitHub-username> with your GitHub username
<repository-name> with the name of your GitHub repository

3.You should now have two files in your project directory: the .tgz file and the index.yaml. Commit and push both files to your GitHub repository using the following command:

git add .
git commit -m "Add packaged chart and index.yaml"
git push

Step 4: Configure GitHub Pages
To serve your Helm chart, you need to enable GitHub Pages:

Go to your GitHub repository.
Click the Settings tab.
Select Pages from the left sidebar.
In the Build and deployment section, under Branch, choose the branch and folder where your chart files are located. For this guide, use:
- Branch: main
- Folder: / (root)
Click the Save button.

GitHub will now serve your Helm chart at:

https://<GitHub-username>.github.io/<repository-name>.

Note: If you don't see the 'Your site is live' message right away, wait a few moments and refresh the page. The message should appear shortly.

Step 5: Register your repository on Artifact Hub
Now you’re ready to publish your chart on Artifact Hub:

Sign in to Artifact Hub.
Click your profile icon and select Control Panel.
Go to the Repositories tab and click + Add.
Fill in the details:
1. Repository name: e.g., nginx-site
2. Display name: e.g., nginx-site
3. URL: Your GitHub Pages URL from Step 3
Click + Add to create your repository.

Once added, Artifact Hub will index your chart. Congratulations! You've successfully published your Helm chart to Artifact Hub.

Verify that your Helm chart was uploaded successfully

Now that your Helm chart has been uploaded, it's time to install and use it to start the Nginx server — all without writing a single line of code.

Step 1: Clean up any existing Nginx release
Before proceeding, make sure there are no existing Helm Nginx releases running. This will help you avoid confusing the release created from the Artifact Hub chart with the one created from your local chart. You can check for existing releases using:

helm list

If you see an Nginx release, delete it by copying the release name and running:

helm uninstall <release-name>

Replace <release-name> with the actual name of the Nginx pod you want to remove.

Step 2: Install your Helm chart
The process of installing a Helm chart is generally consistent across charts. Here's how to do it:

1.Add your Helm chart repository to your local list of Helm repositories:

helm repo add <local-repo-name> <GitHub-Pages-URL>

Replace <local-repo-name> with the name you want to use for the repository locally, and <GitHub-Pages-URL> with the URL of your GitHub Pages site where the Helm chart is hosted.

2.Update your Helm repositories to ensure you have the latest version:

helm repo update

3.Install your Helm chart by running the command below. Replace the placeholders with your actual values:

helm install <release name> <repository name>/<chart name>

<release-name>: A name you choose for this specific deployment (e.g., nginx-release)
<repository-name>: The name you gave the repository when adding it (e.g., nginx-chart)
<chart-name>: The name of the Helm chart (you can find this in the index.html generated and pushed to GitHub)

For example, if your release name is nginx-chart-release, the repository name is nginx-chart, and the chart name is also nginx-chart,the command would be:

helm install nginx-chart-release nginx-chart/nginx-chart

Step 3: Confirm the Deployment
To verify that your Nginx server is running, check the pods again:

kubectl get pods

You should see your Nginx pod listed and running.

Step 4: Access Your Nginx Web Server

If you're using Minikube, run the following to get the external URL:

minikube service <release-name>

For instance:

minikube service nginx-chart-release

If you're using another Kubernetes setup, run the following commands to get the Node IP and Node Port, then open the URL in your browser:

 export NODE_PORT=$(kubectl get --namespace default -o jsonpath="{.spec.ports[0].nodePort}" services nginx-chart-release)
  export NODE_IP=$(kubectl get nodes --namespace default -o jsonpath="{.items[0].status.addresses[0].address}")
  echo http://$NODE_IP:$NODE_PORT

And that’s it! You've successfully created a Helm chart, pushed it to your repository, and deployed it to your Kubernetes cluster using Helm.

Wrapping up

Helm charts are a game-changer for managing Kubernetes applications at scale. By turning complex, multi-file Kubernetes manifests into reusable, versioned packages, Helm simplifies application deployment, configuration, and maintenance. Whether you're working solo on side projects or collaborating with a team on production-grade systems, Helm lets you ship faster with fewer errors and greater consistency.

As you've seen throughout this article, understanding the building blocks of Helm charts, from the basic concepts to the anatomy of a Chart, gives you the tools to build and manage your own charts with confidence.

Start small by templating a basic service, tweaking some values, and installing it. Then gradually expand your charts to support real-world configurations, secrets, and dependencies. Like any good tool, the more you use Helm, the more indispensable it becomes.

Understanding Kubernetes by deploying a real-world application

Amarachi Iheanacho — Tue, 15 Apr 2025 20:24:59 +0000

Kubernetes is an open-source container orchestration platform that automates the deployment, scaling, and management of containerized applications. Originally developed by Google and now maintained by the Cloud Native Computing Foundation, Kubernetes has become the industry standard for managing applications in production. It allows developers and operations teams to focus more on building features rather than managing infrastructure, thanks to its ability to handle things like automatic scaling, self-healing, and service discovery out of the box.

In this article, we’ll explore the core components of Kubernetes by walking through the process of deploying a full-stack Todo application. You'll learn how different Kubernetes objects—such as Deployments, Services, ConfigMaps, and Persistent Volumes—work together to run and maintain an application in a cluster. This hands-on project will help you better understand how Kubernetes manages containerized workloads and why it's such a powerful tool for modern DevOps practices.

The project summary

In this project, you’ll deploy a full-stack Todo application to a Kubernetes cluster using Minikube. The front end of the application is built with CSS and JavaScript, while the back end is powered by Node.js and Express.js. The application stores its data in a MongoDB database.

To deploy this application in a Kubernetes cluster on Minikube, you'll follow these steps:

Create a MongoDB ConfigMap to store the MongoDB environment variables.
Create a MongoDB Deployment that defines how MongoDB pods should be configured.
Create a Persistent Volume and a Persistent Volume Claim to ensure that MongoDB data persists even if the cluster is restarted.
Create an internal service to expose MongoDB to the Todo application.
Create a Deployment for the Todo application that defines how its pods should run.
Create a ConfigMap for the Todo application to manage its environment variables.
Create an external service to expose the Todo application to the outside world.

All the configuration files for this tutorial can be found in the k8s folder of this GitHub repository:

https://github.com/Iheanacho-ai/FullStack-Todo-List-Application

Prerequisites

What you will need to get started with this tutorial:

Minikube. Run this command to check if you have Minikube installed:

minikube version

Refer to the official Minikube documentation to learn how to install Minikube if you do not have it installed.

Basic knowledge of Docker and Docker compose.

Definition of terms

You need to understand the components that make up this project and how these components interact together. These components are:

Pods: The smallest deployable unit in Kubernetes. Even though Kubernetes is a container orchestration tool, it doesn't manage containers directly — it manages Pods. A Pod typically holds one or two containers (or applications) that share the same storage, network, and lifecycle.
Deployments: A Deployment manages the desired state of your Pods — at scale. Think of it as an instruction manual that tells Kubernetes how many replicas of your Pod should be running. It makes sure those Pods stay up and running, and handles updates seamlessly through rolling updates.
ConfigMap: A ConfigMap lets you separate your configuration data from your application code. It’s like a .env file but managed by Kubernetes. This allows you to inject environment-specific settings into your Pods without touching the app itself. You can update the config as often as needed, and share it across multiple Pods.
Service: A Service exposes a set of Pods as a network-accessible service. This matters because Pods are ephemeral — they restart often and get new IP addresses each time. Services give you a stable way to reach your Pods using consistent IPs and DNS names, no matter how often the underlying Pods change.
Persistent Volume (PV): A Persistent Volume is a piece of storage within your cluster — either statically provisioned by an admin or created dynamically. Think of it as a hard drive that lives in your cluster. It helps ensure that your application’s data persists beyond your pod or cluster’s lifecycle.

Persistent Volumes can come from different sources, such as hostPath (local storage), NFS (network file systems), cloud providers like AWS EBS, GCE Persistent Disks, or dynamic provisioning through CSI drivers.

Persistent Volume Claim (PVC): A Persistent Volume Claim is a user's request for storage. With a PVC, you can ask for a specific size and type of storage without knowing how it’s provided. It connects your app to a Persistent Volume behind the scenes.

Step 1: Setting up the project

Create a folder where your project will live and change your current directory into the folder by running this:

mkdir <name of your project>
cd <name of your project>

Step 2: Create a ConfigMap to store MongoDB environment variables

Now that you've set up your project directory, the next step is to create a ConfigMap that stores configuration data for your MongoDB instance. Specifically, this ConfigMap will define the name of the database that MongoDB should create when it starts up.

To create the MongoDB ConfigMap:

Create a new file named mongodb-configmap.yaml in your project’s root directory.
Paste the following YAML into the file:


apiVersion: v1
kind: ConfigMap
metadata:
 name: mongodb-configmap
data:
 mongo-initdb-database: todo_list

What this file does:

apiVersion: v1: Specifies the API version used by Kubernetes for this resource. v1 is the standard version for ConfigMaps.
kind: ConfigMap: Declares that this file defines a Kubernetes ConfigMap, which is used to store configuration data in key-value pairs.
metadata: Contains metadata about the ConfigMap. Here, we set the name as mongodb-configmap, which you'll use to reference this ConfigMap in your MongoDB Deployment later.
data: This section holds the actual configuration values. In this case, we’re setting a key named mongo-initdb-database with a value of todo_list. This value will be passed as an environment variable to the MongoDB container, instructing it to create a database named todo_list when it initializes.

Step 3: Set up a Persistent Volume for storing MongoDB data

Next, you’ll define the Persistent Volume that MongoDB will use to store its data. In this setup, the volume will point to a folder on your local machine. However, you can also point this volume to a remote storage solution such as an NFS share or a cloud provider's block storage (like AWS EBS, Google Persistent Disk, or Azure Disk). Refer to Kubernetes documentation on Persistent Volume to learn more.

To create this Persistent Volume:

Create a file named mongodb.yaml in the root directory of your project. This file will contain all the necessary Kubernetes configurations for MongoDB: the Persistent Volume, the Persistent Volume Claim, the Deployment, and the internal Service that your Todo application will communicate with.
Paste the following YAML into your mongodb.yaml file to define the Persistent Volume:


apiVersion: v1
kind: PersistentVolume
metadata:
 name: mongodb-volume
 labels:
   type: local
spec:
 storageClassName: ""
 capacity:
   storage: 1Gi
 accessModes:
   - ReadWriteOnce
 hostPath:
   path: "/mnt/data"

Here’s what each part of the code means:

apiVersion: v1: This tells Kubernetes to use version 1 of its API, which is the standard for defining core resources like volumes.
kind: PersistentVolume: This specifies that you’re creating a Persistent Volume (PV) — a reusable chunk of storage that exists outside of pods.
metadata.name: mongodb-volume: This sets the name of the volume. You’ll refer to this name later when creating a PersistentVolumeClaim.
labels: Labels are optional key-value tags that help organize and identify Kubernetes resources.
type: local: This is a custom label you’ve added to indicate that this storage is local (on your own machine) rather than in the cloud. It’s just for your own reference — Kubernetes doesn’t enforce it.
spec: This section defines how the volume behaves:
- storageClassName: "": Leaving this blank means you don’t want Kubernetes to automatically provision storage. Instead, you’re manually defining it. If someone wants to use this storage, they’ll need to request it by name (mongodb-volume).
- capacity.storage: 1Gi: This volume provides 1 gigabyte of storage space.
- accessModes: ReadWriteOnce: Only one pod can read and write to this volume at a time.
- hostPath.path: "/mnt/data": This tells Kubernetes to store MongoDB’s data in the /mnt/data folder on your computer.

In simpler terms, the code block above is saying:

“I’m creating 1GB of storage on my local machine using the /mnt/data folder. This storage is named mongodb-volume, and it can be used by only one pod at a time. MongoDB will store its data here, ensuring that even if the MongoDB pod crashes or restarts, the data remains safe."

Step 4: Create a PersistentVolumeClaim to request storage from the Persistent Volume

Creating a Persistent Volume (PV) alone is not enough to provide storage for your pods. Your pods must request a specific amount of storage from the PV, and this is done using a PersistentVolumeClaim (PVC).

To create a PVC, add the following YAML block to your mongodb.yaml file, directly below the Persistent Volume definition:


---
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
 name: mongodb-volume-claim
spec:
 storageClassName: ""
 accessModes:
   - ReadWriteOnce
 resources:
   requests:
     storage: 50Mi

This configuration defines a PersistentVolumeClaim named mongodb-volume-claim that asks for 50 megabytes of storage.

As long as a matching Persistent volume (in this case, MongoDB) meets this requirement, Kubernetes will bind the two together, allowing your pod to use that space.

When you are done with this step, your mongodb.yaml file will look like this:


apiVersion: v1
kind: PersistentVolume
metadata:
 name: mongodb-volume
 labels:
   type: local
spec:
 storageClassName: ""
 capacity:
   storage: 1Gi
 accessModes:
   - ReadWriteOnce
 hostPath:
   path: "/mnt/data"


---
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
 name: mongodb-volume-claim
spec:
 storageClassName: ""
 accessModes:
   - ReadWriteOnce
 resources:
   requests:
     storage: 50Mi

Step 5: Set up a MongoDB Deployment to manage your MongoDB pods

Now that you’ve created both the Persistent Volume and the PersistentVolumeClaim, it’s time to create the Deployment that will run your MongoDB pod.

Copy this YAML file block into your mongodb.yaml file to define the MongoDB Deployment:

apiVersion: apps/v1 
kind: Deployment
metadata: 
  name: todo-mongodb
  labels:
    app: todo-mongodb
spec: 
  replicas: 1
  selector: 
    matchLabels: 
      app: todo-mongodb
  template:
    metadata:
      labels:
        app: todo-mongodb
    spec:
      containers:
      - name: todo-mongodb
        image: mongo
        ports:
        - containerPort: 27017
        env:
        - name: MONGO_INITDB_DATABASE
          valueFrom: 
            configMapKeyRef:
              name: mongodb-configmap
              key: mongo-initdb-database
        volumeMounts:
        - name: mongodb-volume
          mountPath: /data/db
      volumes:
      - name: mongodb-volume
        persistentVolumeClaim:
          claimName: mongodb-volume-claim

The code block creates a Kubernetes Deployment for MongoDB named todo-mongodb that runs one replica of the MongoDB container. Here is the breakdown:

API Version, Kind & Metadata

apiVersion: apps/v1 
kind: Deployment
metadata: 
  name: todo-mongodb
  labels:
    app: todo-mongodb

apiVersion: apps/v1: Tells Kubernetes to use version 1 of the apps API, which is designed for managing deployments and similar resources.
kind: Deployment: This specifies that you are creating a Deployment, responsible for managing and scaling your MongoDB application.
metadata.name: todo-mongodb: Sets the Deployment's name to todo-mongodb.
metadata.labels: app: todo-mongodb: Assigns the label todo-mongodb to the Deployment.

Deployment specification

spec: 
  replicas: 1
  selector: 
    matchLabels: 
      app: todo-mongodb
  template:
    metadata:
      labels:
        app: todo-mongodb

replicas: 1: This tells Kubernetes to run only one instance (or copy) of the MongoDB pod at a time.
selector.matchLabels: This defines which pods the Deployment should manage. It does this by matching a label. In this case, it's looking for pods with the label app: todo-mongodb. Only pods with this label will be controlled (i.e., created, updated, or deleted) by this Deployment.
template.metadata.labels: These are the labels applied to any new pods created by the Deployment. This part ensures that each pod is given the label app: todo-mongodb, which matches the selector above — so Kubernetes knows these pods belong to this Deployment.

Pod Specification (spec)

    spec:
      containers:
      - name: todo-mongodb
        image: mongo
        ports:
        - containerPort: 27017

Containers: This section defines the list of containers that will run in each pod.
- name: todo-mongodb: This assigns a name to the container within the pod.
- image: mongo: This tells Kubernetes to use the official MongoDB image from Docker Hub when creating the container.
- ports: This exposes port 27017 on the container, which is MongoDB’s default port.

Environment Variable from ConfigMap

        env:
        - name: MONGO_INITDB_DATABASE
          valueFrom: 
            configMapKeyRef:
              name: mongodb-configmap
              key: mongo-initdb-database

env: Sets environment variables for the todo-mongodb container.
name: MONGO_INITDB_DATABASE: This environment variable specifies the default database MongoDB should create on startup.
valueFrom.configMapKeyRef: Instructs Kubernetes to dynamically retrieve the environment variable’s value from from the mongodb-configmap ConfigMap you created earlier rather than hardcoding it.
- name: mongodb-configmap: Indicates the ConfigMap from which to fetch the data.
- key: mongo-initdb-database: Points to the specific key in the ConfigMap that holds the value for the environment variable.

Mounting Storage into the Container

        volumeMounts:
        - name: mongodb-volume
          mountPath: /data/db

volumeMounts: Tells Kubernetes to attach a volume to this container.
- name: mongodb-volume: This references the PersistentVolume you created earlier as the volume to mount to this container

Defining the Volume

      volumes:
      - name: mongodb-volume
        persistentVolumeClaim:
          claimName: mongodb-volume-claim

volumes: Defines the storage volumes available to the pod.
name: mongodb-volume: Indicates that one of these volumes is named mongodb-volume—this is the volume you later attach to the pod via the volumeMounts key.
persistentVolumeClaim: Tells Kubernetes to use a PersistentVolumeClaim for obtaining the storage resource.
claimName: mongodb-volume-claim: Specifies the name of the PersistentVolumeClaim to use, which is the one you created to request storage from the PersistentVolume.

When you are done with this section, your mongodb.yaml file will look like this:

[https://gist.github.com/Iheanacho-ai/82d1072bf832f676623c847a70b9c420]

Step 6: Create an internal Service to connect MongoDB with the Todo application

For your application to work properly, the Todo application must connect to the MongoDB database. To allow this connection, we need to expose the MongoDB Pod using a Service.

Paste the following YAML block into your mongodb.yaml file to create the service:

--- 
apiVersion: v1
kind: Service
metadata: 
  name: todo-mongodb-service
spec:
  selector: 
    app: todo-mongodb
  ports:
    - protocol: TCP
      port: 27017
      targetPort: 27017
  clusterIP: None

The code block above:

apiVersion: v1: Specifies that this YAML uses version 1 of the Kubernetes API.
kind: Service: Specifies that you're creating a Service resource, which helps expose a set of pods on the network.
metadata: name: todo-mongodb-service: Sets the name of the Service to todo-mongodb-service.
spec: Defines the desired behavior of the Service.
selector: app: todo-mongodb: Tells the Service to target pods with the label app: todo-mongodb.
ports: Lists the port configuration for the Service.
- protocol: TCP: Uses TCP as the communication protocol.
- port: 27017: Exposes port 27017 on the Service, which is the port clients connect to.
- targetPort: 27017: Directs the traffic to port 27017 on the selected Pods.
clusterIP: None: This makes the Service headless, which means Kubernetes won’t assign it a Cluster IP. Instead of routing traffic through a single, stable IP, the Service lets other Pods communicate directly with the IP addresses of individual MongoDB Pods. This is especially useful for databases, where each Pod might maintain its own state and needs to be reached directly—rather than through a load balancer.

Refer to the Kubernetes documentation on Services to learn more about different Service types and use cases.

When you are done with this step, your mongodb.yaml file will look like this:

[https://gist.github.com/Iheanacho-ai/5376054e00cb9dc2571e364efc32e620]

Step 7: Apply the configuration to deploy your MongoDB application

Now that you’ve defined all the necessary components for MongoDB — including the ConfigMap, Deployment, Service, PersistentVolume, and PersistentVolumeClaim — it’s time to apply them and bring your MongoDB environment to life.

To do this, follow the steps below:

Apply the ConfigMap first: The ConfigMap contains configuration data that the MongoDB deployment will need at startup. So, it must be created before the pod tries to read from it.

kubectl apply -f mongodb-configmap.yaml

2.Apply the MongoDB resources: This will create your MongoDB Deployment, Service, Persistent Volume, and PersistentVolumeClaim, all defined in your mongodb.yaml file.

kubectl apply -f mongodb.yaml

3.Check that everything is running correctly: Your pods and services may take a few moments to fully start. To check their status, run:

kubectl get pods
kubectl get svc

Step 8: Set up a ConfigMap to manage environment variables for your Todo application

Now that you have brought your MongoDB environment to life, you need to move on to the Todo application.

Similar to the MongoDB application, you would need to define the ConfigMap that will hold configuration values for the Todo application.

To create the ConfigMap for the Todo application:

Create a todo-configmap.yaml file in your project’s root directory
Paste this YAML code block into the todo-configmap.yaml file.

apiVersion: v1
kind: ConfigMap
metadata:
  name: todo-configmap
data:
  deployment: "local"
  environment: "development"
  db: "mongodb://todo-mongodb-service:27017/todo_list"
  db_name: "todo_list"

In the ConfigMap above, you name the ConfigMap, todo-configmap and then define in it four environment variables:

deployment: "local": This explains that the application is deployed locally.
environment: "development": Defines that the application is running in a development environment
db: "mongodb://todo-mongodb-service:27017/todo_list": This is the MongoDB connection string. It tells your app:
- Connect to the MongoDB Service called todo-mongodb-service
- Use port 27017
- Use the todo_list database
db_name: This holds the name of the database

Step 9: Setting up a Deployment for your Todo application

Next, let’s create a Deployment to manage the pods for your Todo application.

Copy the YAML below into a file named todo-deployment.yaml:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: todo-list
  labels:
    app: todo-list
spec:
  replicas: 2
  selector:
    matchLabels:
      app: todo-list
  template:
    metadata: 
      labels:
        app: todo-list
    spec:
      containers:
      - name: todo-list
        image: amaraiheanacho/amaratodo:latest
        ports:
        - containerPort: 8000
        env:
        - name: DEPLOYMENT
          valueFrom:
            configMapKeyRef:
              name: todo-configmap
              key: deployment
        - name: ENVIRONMENT
          valueFrom: 
            configMapKeyRef:
              name: todo-configmap
              key: environment
        - name: DB
          valueFrom:
            configMapKeyRef:
              name: todo-configmap
              key: db
        - name: DB_NAME
          valueFrom:
            configMapKeyRef:
                name: todo-configmap
                key: db_name

Breaking down this configuration into sections:

ApiVersion, Kind, and Metadata


apiVersion: apps/v1
kind: Deployment
metadata:
  name: todo-list
  labels:
    app: todo-list

The configuration above tells Kubernetes that it defines a Deployment named todo-list.

Deployment level Specification: This section defines how the Deployment should behave.

spec:
  replicas: 2
  selector:
    matchLabels:
      app: todo-list
  template:
    metadata: 
      labels:
        app: todo-list

This bit of configuration does the following:

replicas: 2: Runs two pods of your Todo application for high availability.
selector.matchLabels: Tells Kubernetes that this Deployment manages pods with the label app: todo-list.
template: This is the blueprint Kubernetes uses to create the pods.
- metadata.labels: This gives every pod created by the Deployment a label of app: todo-list.

Container Spec: This describes the containers the pods should run.

    spec:
      containers:
      - name: todo-list
        image: amaraiheanacho/amaratodo:latest
        ports:
        - containerPort: 8000

name: todo-list: The name of the container
image: amaraiheanacho/amaratodo:latest: The Docker image used to run your app, pulled from Docker Hub.
ports.containerPort: 8000: The port your app listens on inside the container.

Environment Variables: These are environment variables passed into your container from the todo-configmap ConfigMap you created earlier:

        env:
        - name: DEPLOYMENT
          valueFrom:
            configMapKeyRef:
              name: todo-configmap
              key: deployment
        - name: ENVIRONMENT
          valueFrom: 
            configMapKeyRef:
              name: todo-configmap
              key: environment
        - name: DB
          valueFrom:
            configMapKeyRef:
              name: todo-configmap
              key: db
        - name: DB_NAME
          valueFrom:
            configMapKeyRef:
                name: todo-configmap
                key: db_name

This section retrieves values from your todo-configmap ConfigMap. These values are then injected into the container as environment variables, which include:

Environment Variable	Value comes from key
DEPLOYMENT	`deployment` in ConfigMap
ENVIRONMENT	`environment` in ConfigMap
DB	db in ConfigMap
DB_NAME	db_name in ConfigMap

Step 10: Create an external Service to expose your Todo application to external traffic

To access the Todo application from outside the cluster, you need to expose it using a Kubernetes Service — just like you did with MongoDB. However, unlike MongoDB, which only needs to be accessible to other pods in the cluster, the Todo app needs to be open to the Internet.

To do this, you’ll create an external Service.

Paste the following YAML block into your todo-deployment.yaml file to do so:

---
apiVersion: v1
kind: Service
metadata:
  name: todo-list-service
spec:
  selector: 
    app: todo-list
  type: LoadBalancer
  ports:
    - protocol: TCP
      port: 8000
      targetPort: 8000
      nodePort: 30000

Here’s what this configuration does:

name: todo-list-service: This names the Service so you can refer to it easily.
selector: app: todo-list: This Service routes traffic to any pod with the label app: todo-list.
type: LoadBalancer: This exposes the Service to the outside world.
- On cloud platforms, this would create a real Load Balancer (like AWS ELB).
- On Minikube, it actually creates a NodePort behind the scenes to simulate external access.
nodePort: 30000: This makes the Todo app accessible on port 30000 of your host machine (like your laptop or VM).
- For example, you can open http://localhost:30000 to access the app.
Tip: To understand how this differs from the MongoDB Service, refer back to the MongoDB section.

When you are done with this section, this is how your todo-deployment.yaml file would look like:

[https://gist.github.com/Iheanacho-ai/39736da41c400cefb062bd26fd4eb191]

Step 11: Apply the configuration to launch your Todo application

Finally, let's bring your Todo application to life:

First, apply your ConfigMap by running the command below. This will load the environment variables your Todo app needs:

kubectl apply -f todo-configmap.yaml

2.Next, deploy your Todo application pods and expose them via a service by applying the deployment YAML:

kubectl apply -f todo-deployment.yaml

3.Your pods may take a few moments to start fully. To check their status, run:

kubectl get pods

Look for a STATUS of Running for the todo-list pods.

4.To view all the services running in your cluster (including your Todo app), run:

kubectl get svc

5.Find the name of the Todo service (e.g., todo-list-service) and use it to start your app in the browser with:

minikube service <name-of-your-todo-service>

For example, if your service is called todo-list-service, run:

minikube service todo-list-service

This command will open your Todo application in your default browser.

You have deployed a Full stack Todo application into a mini Kubernetes Cluster using Minikube.

Wrapping up

This article explained the building blocks of understanding Kubernetes and stacked these blocks on top of each other to deploy a full-stack Todo application into a Kubernetes cluster propped up by Minikube. Check out the official Kubernetes documentation to dive deeper and explore all the possibilities.

What is an F1 score?

Amarachi Iheanacho — Thu, 10 Oct 2024 06:37:35 +0000

Artificial intelligence has integrated into different facets of our everyday lives, from virtual assistants and personalized recommendations to healthcare diagnostics and fraud detection; we are twice as likely to interact with a piece of software or tool powered by AI than we were a couple of years ago. While this is a positive development, it raises an important question: how can we trust the predictions or outputs of AI-powered solutions? This concern is especially important in situations where inaccurate predictions could result in significant losses, both financial and even in terms of human life.

In this article, we will explore performance metrics like the F1 score for evaluating the effectiveness of classification models, how it’s calculated, and why it’s often preferred over other performance metrics like precision or recall when evaluating classification models.

Understanding the importance of F1 score in classification models

Classification models are algorithms that analyze and categorize complex data sets into predefined classes or labels. These models are used across various sectors, such as anomaly detection, medical diagnosis, text classification, and more. For example, in anomaly detection, classification models help label data points as either "anomalous" or "non-anomalous."

Similarly, in medical diagnosis, a classification model might be used to detect cancer by categorizing patient data into "cancerous" or "non-cancerous" groups.

In such examples, “false positives” and “false negatives” in classification models can have serious consequences. So how can we trust the predictions of these models? The F1 score offers one way to evaluate how well a classification model recognizes and categorizes data into different subsets. To fully understand the F1 score, let's explore three important concepts:

The possible outcomes of a classification model
What are precision and recall performance metrics
How precision and recall combine to give a more comprehensive assessment of a model’s performance which is captured by the F1 score.

Now that we've outlined the significance of classification models, it's important to take a closer look at their prediction outcomes. These outcomes form the foundation for performance metrics such as precision, recall, and, more importantly, the F1 score.

Understanding the possible outcomes of a classification model

A classification model prediction typically falls into one of these four categories:

True Positives: These are events or data points that were correctly predicted as positive.
True Negatives: These are events that were correctly predicted as negative.
False Positives: These are events that were incorrectly predicted as positive but were actually negative.
False Negatives: These are events that were incorrectly predicted as negative but were actually positive.

These four outcomes form the basis of precision and recall, which together make up the F1 score.

What are precision and recall?

Now that we understand these four outcomes, let's use them to explain precision and recall.

Precision
The precision performance metric determines the quality of positive predictions by measuring their correctness. In other words, it measures how many of the positive predictions made by the model were actually correct. Precision is calculated by dividing the number of true positive outcomes by the sum of the true positives and false positives.


Precision = True Positives / (True Positives + False Positives)

Example:

To better understand precision, let’s consider a pool of 500 emails, and a spam filter that has been employed to figure out how many of these emails are spam.

Suppose the filter identifies 120 emails as spam, but only 100 of those emails are actually spam. In this case, the precision of the spam filter would be:


Precision = 100 / (100 + 20) = 0.833

This means that 83.3% of the emails that the filter identified as spam were actually spam.

While precision focuses on the accuracy of positive predictions, recall assesses the model's overall ability to identify all actual positive cases.

Recall
Recall, also known as sensitivity, measures a model’s ability to accurately detect positive events. In simpler terms, it indicates how many of the actual positive instances were correctly identified by the model. Recall can be calculated using the formula below:


Recall = True Positive / (True positive + False Negative)

Example:

Let's return to the spam email filter example. We saw that out of the filter’s prediction of 120 spam emails, 100 were indeed spam. However, what if there were actually 200 spam emails in total? Then in this scenario, the recall would be:


Recall = 100/ 200 = 0.5

This means that the filter correctly identified 50% of all actual spam emails.

While precision and recall provide valuable insights into a model’s performance, relying solely on one without considering the other can give an incomplete picture.

Limitations of using precision as a classification metric without recall (and vice versa)

Considering precision without recall, and vice versa, can lead to a misleading evaluation of a model's performance, especially in scenarios where class distribution is imbalanced or where different types of errors (false positives vs. false negatives) have varying consequences.

Limitations of Precision without Recall

Precision alone focuses solely on the correctness of the positive predictions, ignoring how well the model captures all possible positives. A model with very high precision might seem impressive, but if it misses a large number of actual positive instances (low recall), it could be underperforming. This often occurs in cases where a model is extremely cautious about making positive predictions, leading to fewer but more accurate positive results. This cautious approach minimizes false positives but increases false negatives.

For example, imagine a medical diagnosis model designed to detect a rare disease. If the model has perfect precision but low recall, it correctly identifies all the positive cases it flags as having the disease. However, if it only flags 2 out of 50 actual positive cases, its recall is very low. This means that while every diagnosed patient truly has the disease (precision is 100%), the model is missing the vast majority of patients who actually have it, making it unreliable for early diagnosis and treatment.

Limitations of Recall without Precision

Similarly, focusing on recall alone means you're only considering how many true positives are identified out of the total actual positives without regard to how many false positives the model produces. A high recall could indicate the model captures most positive instances, but it might be over-predicting positives, leading to a flood of false positives and reduced accuracy in actual predictions.

Using the medical diagnosis example, imagine a medical diagnosis model with 100% recall that flags every patient as having the disease to ensure it never misses a single case. While the recall is perfect, the precision is incredibly low because many healthy individuals will be wrongly diagnosed. This makes the model impractical, as it would result in unnecessary anxiety and treatments for people who do not actually have the disease.

This highlights the importance of a comprehensive metric combining precision and recall—the F1 score.

What is an F1 score?

An F1 score can be understood as the harmonic mean of precision and recall, combining both these metrics into one comprehensive assessment that neither performance metric can offer alone.

The F1 score is described as the harmonic mean of both precision and recall for two important reasons:

The F1 score gives both of these metrics equal weights, ensuring that a good F1 score signifies that the model has a good balance between precision and recall.
Unlike the arithmetic mean, the harmonic mean prevents a high precision score from disproportionately affecting the overall F1 score when recall is low, and vice versa.

The F1 score can be calculated as:


F1 - score = 2 * (precision * recall) / (precision + recall)

So using the original example of the spam filter, with a precision of 0.8333 and a recall of 0.5, the F1 score of the spam filter would be:


F1 score = 2 * (0.8333 * 0.5) / ( 0.8333 + 0.5 )

F1 score = 0.625

Calculating a model's F1 score can provide a clearer, more balanced measure of its performance, especially in cases where both precision and recall are critical.

Interpreting the F1 score

Similar to most performance metrics, the F1 score ranges from 0 to 1, with 0 representing the worst possible score and 1 representing the best possible score a model can get.

A high F1 score indicates that the model has good precision and recall, showing a well-balanced performance. Conversely, a low F1 score may suggest a trade-off between precision and recall or indicate that the model performs poorly on both metrics.

This comprehensive insight provided by the F1 score is particularly crucial in anomaly detection, as it helps evaluate the model's ability to accurately recognize and identify anomalous events.

F1 score in anomaly detection

Anomaly detection, once a labor-intensive process, has become much more efficient with the rise of artificial intelligence. Advanced tools like Eyer, an AI-powered anomaly detection platform, have streamlined this process by automating the identification of unusual data patterns.

At its core, anomaly detection involves analyzing data to identify patterns or behaviors that deviate significantly from the norm. These deviations, often referred to as anomalies or outliers, can signal critical events such as fraud, system failures, or network intrusions. By using Eyer's sophisticated algorithms, these anomalies can be detected earlier and with greater accuracy, enabling organizations to respond to potential threats in real-time.

Given the potential consequences of relying on ineffective anomaly detection tools, it’s crucial to trust the performance of platforms like Eyer. One way to measure this trust is through the F1 score, which provides valuable insights into the balance between precision and recall.

For a deeper dive into Eyer's performance, including its F1 score testing results, check out the official documentation and read all about Eyer’s findings on the F1 performance testing of the core algorithm of Eyer.

In summary

Many of the artificial intelligence models we encounter in our daily lives are classification models. These models help us determine whether data has specific characteristics, ranging from something as simple as identifying spam emails to more critical applications like diagnosing cancer in patients.

Since we often don’t know the correct answers to the questions posed by classification models, it’s essential to trust these systems to make accurate predictions and draw the right conclusions from the data. This is where the F1 score comes into play.

The F1 score offers a balanced evaluation of a classification model’s performance by considering both precision and recall. Its value lies in providing a comprehensive measure that neither precision nor recall can fully capture. This makes the F1 score particularly vital in high-stakes scenarios like anomaly detection and medical diagnosis, where both false positives and false negatives can have serious consequences. By understanding and calculating the F1 score, we gain deeper insights into the effectiveness of AI-powered classification models, allowing us to develop more reliable and trustworthy systems. Tools like Eyer, which incorporate the F1 score into their evaluations, demonstrate how this metric can enhance decision-making in real-world AI applications.

Ultimately, using the F1 score not only helps validate the performance of these models but also ensures that they align with the critical needs of various sectors. Whether in healthcare, finance, or cybersecurity, understanding the strengths and weaknesses of classification models through the F1 score can lead to better outcomes and increased confidence in automated decisions. As reliance on AI grows, prioritizing robust evaluation metrics like the F1 score will be essential for building the next generation of intelligent systems that we can trust.

Lastly, check out Eyer for an F1 score-approved, AI-powered anomaly detection tool to monitor your systems.

The role of baselines in anomaly detection

Amarachi Iheanacho — Mon, 29 Jul 2024 08:51:15 +0000

Artificial intelligence and machine learning are quickly making their way into every facet of life, including art, customer service, engineering, and, more recently, anomaly detection, particularly through tools like Eyer.

Anomaly detection was once a repetitive and labor-intensive task, involving countless hours of peering into and analyzing large datasets to identify irregularities or anomalies. However, tools like Eyer now leverage artificial intelligence to automate the process of reading and analyzing large datasets to detect anomalies. But how do you determine if a data point is an anomaly? What constitutes normal behavior? These are the questions that baselines provide some answers to, and this article explores what baselines are and how they are used in anomaly detection and other industries.

What is a baseline?

In anomaly detection, baselines serve as reference points or models that represent the normal behavior of a system or dataset under normal conditions. These baselines are crucial for identifying deviations in the data that may indicate anomalies or outliers. A baseline includes lower and upper boundaries, creating a band within which a metric is expected to stay under normal conditions.

Baselines are typically created using historical data. They can be derived from the mean or median of the dataset. Alternatively, you can define baselines using percentiles. For example, any data point outside the 5th or 95th percentile, which in this case are the lower and upper threshold of the baseline, might be flagged as an anomaly.

Additionally, you can also derive baselines with learning models like linear regression or decision trees. These models can capture relationships in the data and highlight deviations from those relationships. Additionally, clustering algorithms like K-means can be used to define normal clusters of data points. Points that don't fit well into any cluster can be considered anomalies.

While baselines are normally derived from historical data, you must note that they are typically subject to change and, therefore, continuously update as new data flows in.

Now that you understand baselines let's dive into the various methods for identifying baselines for your dataset.

What is baseline detection?

As the name suggests, baseline detection is the process of discovering what a baseline for a dataset is. Introduced briefly in the previous section, there are different methods of baseline detection:

Statistical methods: These techniques rely on statistical properties of the data to define a range of normalcy; these techniques include:
- Mean and standard deviation: This approach defines a normal range based on the mean value and its standard deviation. Data points outside a certain number of standard deviations from the mean can be considered anomalies.
- Percentiles: This approach defines normal behavior using percentiles. For example, the 5th percentile and the 95th percentile might represent the lower and upper bounds of normal behavior. Points that fall outside this range are flagged as anomalies.
Time series analysis: When dealing with data collected over time, specific methods can be used to identify the underlying baseline trend:
- Autoregressive models: These models predict future values based on past data points, essentially creating a baseline for what the next data point should look like.
- Moving average: This method smooths out short-term fluctuations by averaging a series of past data points. This helps highlight the longer-term trends, making it easier to identify deviations from the baseline.
Machine learning models: Machine learning offers powerful tools to automatically learn the baseline from your data. Some of these tools are:
- Simple models: Linear regression, for instance, can establish a baseline by capturing the underlying relationships within the data. Deviations from this baseline might indicate anomalies.
- Clustering: Clustering algorithms like K-means can group similar data points together. Points that don't fit well into any cluster are potential outliers or anomalies.

Why does baseline detection matter?

Baselines and baseline detection are important for different applications. Some of these applications are:

Anomaly detection: This is one of the primary use cases that comes to mind when discussing baseline detection. By identifying data points or events that stray significantly from the established norm, anomaly detection helps us spot potential problems. This is crucial in industries like observability, where tools like Eyer leverage baselines to flag anomalies for further investigation.
Quality control: In manufacturing processes, baselines can be established for various parameters like temperature, pressure, or component dimensions. Baseline detection helps identify products deviating from these expected values, potentially indicating defects. This allows for early intervention and ensures product quality.
Predictive maintenance: Baseline detection can be used to monitor equipment performance over time. By establishing baselines for normal operating parameters such as vibration levels, temperature, and energy consumption, deviations can be identified before they become critical failures. This allows for proactive maintenance, minimizing downtime and repair costs.

Finding these deviations from the norm is precisely what makes baseline detection so valuable. Next, let's take a closer look at a specific use case–anomaly detection with Eyer–dissecting how this new age tool approaches baselining.

Eyer’s approach to baselining using multiple baselines

Eyer is an AI-powered observability tool that leverages baselining for discovering anomalies in a system. Eyer approaches baselining in a very interesting way: it understands that each metric is unique and caters to each as such. For each unique metric, Eyer builds baselines using a combination of autoregressive and clustering models. These baselines, which are built from historical data, consist of upper and lower thresholds.

The term "baselines" is intentional because Eyer can build up to three baselines for a single metric: a primary (or main) baseline and one to two secondary baselines. These baselines can account for different normal behaviors of the same metric on the same day. For example, on some Mondays at noon, CPU utilization might be at 30%, while on others, it could be at 70%, and both are considered normal. However, if 30% utilization is slightly more frequent, it will be the primary baseline, with 70% as a secondary baseline.

The main baseline represents the most frequent behavior and is considered anomaly-free. The secondary baselines represent less frequent behaviors that could still be normal but might occasionally conceal some anomalies.

The thresholds that makeup baselines are learned automatically and are dynamic. They are learned and relearned based on past behaviors, and these thresholds are adopted and learned if any changes occur in the system. So, there is no need for manual actions to set up the monitoring systems, as the AI algorithm learns by itself.

But what role does baselining play in an Eyer anomaly alert?

How does Eyer build out an anomaly alert using baselining?

With these multiple baselines defining normal behavior, it becomes easier to spot anomalies in the data.

It is easy to think of any data point that exists outside the established baselines as an anomaly, but it isn't always marked as one. The data point behavior needs to meet a couple of requirements before being classified as an anomaly.

The verification phase determines whether a deviation is an anomaly. In the first part of the verification phase, some deviations can be ruled out through trend analysis. For example, if the data points are only slightly outside the baselines but the overall trend appears normal, they are not considered deviations and thus not considered anomalous.

After this, a 15-minute verification window is used to monitor data for anomalies. If data deviates from normal behavior for at least 8 minutes within this window, that behavior is classified as anomalous, and the corresponding data point is flagged as an anomaly.

Conversely, if a data point falls outside the baseline for less than 8 minutes within the 15-minute verification window, the anomaly is considered closed.

However, identifying a data point as anomalous is just the beginning. The next step is figuring out how anomalous that data point really is.

Classification of anomaly alerts
An alert can include anomalies on several metrics. Each anomaly on each metric has an assigned severity. The overall severity of the alert is based on the severity of the anomalies contained in the alert.

The severity of the anomaly on a single metric
After confirming a data point as an anomaly, Eyer assigns it a weight based on how significantly it deviates from the baselines. These weights are categorized as follows:

Maximum weight: A data point receives a maximum weight of 2 if it exists far outside all predefined baselines.
Medium weight: This weight, valued at 1, is assigned to a data point that exists beyond the primary baseline but remains within one of the secondary baselines.
Zero weight: When a data point temporarily returns to the main baseline after deviating, it receives a weight of zero.

Depending on how long an anomaly remained outside the main or secondary baselines—these weighted deviations are averaged to form the anomaly's history. This average of weighted deviations is then translated into an anomaly score ranging from 0 to 100, where 0 indicates a critical anomaly, and 100 indicates an anomaly-free state.

This anomaly score, which you can refer to as AS, is then used to describe the severity and likelihood of behavior in a data point being anomalous and potentially impactful. The higher the AS, the less likely the behavior is anomalous. Here's a breakdown of what the AS signifies:

AS > 85: No anomaly. Anomaly scores above 85 indicate that the behavior in the data point can be thought of as primary expected behavior, with minor deviations.
60 < AS <= 85: Low severity. If the anomaly score is greater than 60 and less than or equal to 85, it indicates a low-severity anomaly. This means the data point exhibits minor anomalous behaviors similar to those observed in recent days, weeks, and months. Although the likelihood of the behavior being an anomaly is low, it may occasionally conceal anomalous behavior.
30 < AS <= 60: Medium severity. If the anomaly score is between 30 and 60, it indicates a medium-severity anomaly. This means that the data point behavior may be anomalous but also resembles patterns seen previously, making it less certain as an anomaly.
AS <= 30: Severe. If the anomaly score is less than or equal to 30, it indicates that the anomaly is severe. This means that there is a prevalence of new unseen behavior.

In addition to classifying anomalies by their severity, another perk of Eyer and its anomaly detection is that the metrics are not only learned in isolation. Eyer also uses correlations to group related metrics and their anomalies together, combining them in a single alert and making it easier for root cause analysis.

Correlations in Eyer alerts
Correlations help describe the degree to which two or more variables move in relation to one another. In Eyer, correlations help identify how different metrics influence each other or exhibit similar patterns.

Most metrics have a natural correlation. For example, Process CPU is correlated with the number of executions. This is because each execution of a process consumes CPU resources. As the number of executions increases, the cumulative CPU load from these executions also increases.

After using these baselines to identify anomalies in a metric, determining the severity of those anomalies, and understanding which metrics might be affected by correlations, Eyer packages all this information and sends it out in a comprehensive and succinct alert.

You can see an example of an Eyer anomaly alert in the code block below:

{
  "new": [],
  "updated": [
    {
      "severity": "medium",
      "started": "2024-06-26T18:43:00Z",
      "ended": null,
      "updated": "2024-06-26T19:27:00Z",
      "id": "667c6193d58419f64f4cb403",
      "items": [
        {
          "node": {
            "id": 64,
            "name": "Operating System. undefined",
            "system": {
              "id": 1,
              "name": null
            }
          },
          "metrics": [
            {
              "id": "2ce746c5-1ee3-45d1-b23f-bae56bc5d51a",
              "name": "Committed Virtual Memory Size",
              "metric_type": "int",
              "aggregation": "avg",
              "severity": "severe",
              "started": "2024-06-26T18:42:00Z",
              "updated": "2024-06-26T19:12:00Z"
            },
            {
              "id": "5523ee20-2af2-4b8e-8390-3d2cb4410018",
              "name": "System CPU Load",
              "metric_type": "double",
              "aggregation": "avg",
              "severity": "medium",
              "started": "2024-06-26T19:25:00Z",
              "updated": "2024-06-26T19:26:00Z"
            },
            {
              "id": "a59df24a-e9ec-4c4c-a087-ea1375d4b9c7",
              "name": "Process CPU Load",
              "metric_type": "double",
              "aggregation": "avg",
              "severity": "medium",
              "started": "2024-06-26T19:26:00Z",
              "updated": "2024-06-26T19:27:00Z"
            }
          ]
        }
      ]
    }
  ],
  "closed": [
    {
      "severity": "low",
      "started": "2024-06-26T18:49:00Z",
      "ended": "2024-06-26T19:37:00Z",
      "updated": "2024-06-26T19:37:00Z",
      "id": "667c62f7d58419f64f4cb426",
      "items": []
    }
  ]
}

In the alert above, you have the new alerts array, the updated array, and the closed array of alerts. Check out Alerts- structure and data explained, to understand the structure of the alerts.

According to this alert, an anomaly update has happened in the Operating system node.

This anomaly alert has an overall medium severity because it includes one severe anomaly in the Committed Virtual Memory Size metric. The other metrics in the alert, System CPU Load, and Process CPU Load, have medium anomalies.

The metrics array, which contains both affected and correlated metrics, shows anomalies in the Committed Virtual Memory Size, System CPU Load, and Process CPU Load metrics.

Conclusion

This article has helped you understand the role that baselining plays in machine learning, specifically anomaly detection using historical data.

While "baseline" might seem like a simple reference point, it is the foundation upon which many crucial models and their results are built. Anomaly detection tools like Eyer use baselines to determine if a data point's behavior is anomalous and to gauge the extent of the anomaly. This discernment sets the stage for proactive monitoring and timely intervention, ensuring system reliability and performance.

To learn more about Eyer baselines and start using the Eyer anomaly detection solution, visit the Eyer website.

How to use Eyer and Grafana to query and visualize anomalies in CPU and memory metrics

Amarachi Iheanacho — Mon, 29 Jul 2024 08:43:03 +0000

Anomaly detection, also known as outlier detection, is the practice of identifying data points that deviate significantly from the rest of a data set. Traditionally, this was the domain of statisticians and analysts who spent hours poring over data to find these anomalies. However, like many fields, anomaly detection has evolved over time, leading to the development of solutions like Eyer.

With the rise of machine learning (ML) and artificial intelligence (AI), ML algorithms can now automatically learn underlying patterns within vast datasets, process the data, and effectively identify anomalies that might escape even the most trained human eye.

This article introduces Eyer as the AI-powered anomaly detection tool under review and demonstrates how it can be used to identify anomalies in CPU and memory metrics in a host server or machine.

Prerequisites

To get started with the tutorial, you must have the following:

The Eyer connector agents installed on production or production-like hosts. If you have not installed these agents, refer to the Eyer documentation for installation instructions.
The installed agents must be running continuously for at least a week. This allows the Eyer machine learning pipeline to learn the normal behavior of your Boomi integrations. For more information, refer to the official documentation on Onboarding, preprocessing, and filtering data.
A Boomi Atom installed locally.

Understanding what Eyer is and how it works.

Eyer is an AI-powered observability tool that provides deep insights into your Boomi integrations. It utilizes machine learning to analyze various metrics and identify unusual patterns or data points that deviate significantly from the norm. This anomaly detection capability helps you proactively address potential issues before they impact your integrations.

To gather and deliver data to Eyer's machine learning pipeline, the connector employs a range of agents, including web servers (like Jetty or Tomcat), Jolokia, and Telegraf. Each agent plays a crucial role in this process, for example:

The web server hosts and serves the Jolokia agent. During installation, you can choose to use Apache Tomcat to serve the Jolokia agent instead of Jetty or any other preferred server.
The Jolokia agent helps monitor and manage Java applications through a web browser. It acts as a bridge, allowing you to access and control parts of your Java program using simple web requests, and returns the information in an easy-to-read format (JSON).
The Telegraf agent collects and sends metrics and events from various sources to different databases and systems. It will be responsible for collecting data from your Boomi Atom and sending it to the machine learning pipeline.

Eyer’s anomaly detection works because of the continuous data stream from your Boomi Atom to Eyer’s machine learning pipeline. It is important to note that the remaining events in this tutorial, which involve querying and visualizing anomalies, occur after anomaly detection has been enabled on the Boomi Atom, requiring at least 7 days of a steady data stream.

Simulating stress for the servers holding the Boomi Atom

Once the Eyer team confirms your anomaly detection enablement, you can begin querying for anomalies in your environment.

This guide simulates a production environment by running a Windows virtual machine continuously (24/7) for at least a week. It also injects anomalies by increasing the CPU load on the virtual machine hosting the Boomi Atom you're monitoring.

Since this guide uses a Windows operating system virtual machine, it utilizes the Windows tool CpuStress v2.0 to maximize CPU utilization.

While maximizing CPU load offers a valuable way to understand Eyer's capabilities, you can introduce anomalies across different Boomi Atom metrics, including memory, disk usage, and system load.

Getting started with CpuStres
To get started with CpuStres, download the executable file from the CpuStres v2.0 download page. Once the download is complete, extract the CPUSTRES.zip file and run it to open the CPU Stress modal.

You will see your CPU cores in this modal. To activate three or four of these cores, click on each one, navigate to the Thread tab, and select the Activate button from the Thread dropdown.

Additionally, set the Activity level to high to increase the load on the CPU cores. To ensure these CPU load stress tests are registered as an anomaly, keep CpuStres running for at least 8 minutes.

Configuring the Eyer connector to query the data on anomalies

After simulating anomalous behavior in your host machine, use the Eyer connector to query the information on these anomalies.

To query this data on anomalies, log into your Boomi Atmosphere account. Go to the Integration page, click Create New, and select Process from the dropdown menu.

This action will open the Start Shape sidebar. Choose the Connector radio button. Next, in the Connector field, search and select the Eyer-Partner connector.

Next, click the + button in the Connection field to open the connection page.

Leave the Server and the Eyer authentication key fields as their default values.

In the Custom Authentication Credentials field, click the Encrypted button and fill it out with your Eyer authentication key.

Click the Save and Close button to return the Eyer connector sidebar.

Creating Eyer-Partner operation
In the sidebar, select a Get action and then click the + button on the Operation field to create a new Eyer operation.

Clicking the + button opens up the Eyer operation’s page. On this page, click the Import Operation button to create a new operation.

This action opens up the Eyer-Partner Connector Operation Import modal. Fill out this modal with the following information:

Atom: Select the Atom you are running the process in from your dropdown
Connection: Select the Eyer connection you made for this process

Click on the Next button to save your operation. Then, select the Object Type that fits your purpose:

Anomalies returns a list of anomaly alerts grouped by correlation
Anomalies with metrics return a list of anomaly alerts grouped by correlation metrics, including their respective values and baseline values at the time of the alert (new/updated)

In this example, we select the Anomalies with metrics object type. Click on the Next button to save your Object Type preference, and click the Finish button to see your Eyer response profile loaded on your Operation page.

Next, you need to define the operation values. These values define the information required in anomaly alerts. For the Eyer-Partner connector, you can define operation values using either the Options or Dynamic operation property.

Options are great for static operation values.
Dynamic operation properties are better when the start and end values are always changing. To learn more about the distinction between options and dynamic operation properties, check the official documentation on Configuring the Eyer connector.

This guide will use Dynamic Operation properties to determine the Operation’s value.

Setting operation value with Dynamic operation properties
To set up the Dynamic Operation properties, navigate to the Dynamic Operation Properties tab and click the Add Dynamic Operation Property.

This action opens up a Parameter Value modal; in this modal, select the following options:

Input → Query from
Type → Date/Time
Date Mask → yyyy-MM-dd’T’HH:mm:ssZ
Date Type → Last Successful Run Date

These Parameter Value options tell the Eyer-Partner Connector to start the query for anomalies since the last test.

Click the OK button to return to the Dynamic Operation Properties tab.

Next, create a new Dynamic Operation Property, filling in the Parameter Value with the following information:

Input -> Query to
Type -> Date/Time
Date Mask -> yyyy-MM-dd’T’HH:mm:ssZ
Data Type -> Current Date

These values tell the Eyer-Partner Connector to query the current date for anomalies.

Click the OK button to save the parameter value and return to the sidebar.

Click the OK button to save the Dynamic Operation Property configuration and return to the Boomi process canvas.

Sending out the email
With Boomi, you have multiple options for receiving these anomalies. This guide uses the Boomi Mail connector. To learn how to configure the Mail connector, check out the Boomi Mail connector documentation.

Here are the anomalies from the CPU stress test received in the mail.

{
  "new": [],
  "updated": [
    {
      "severity": "medium",
      "started": "2024-06-26T18:43:00Z",
      "ended": null,
      "updated": "2024-06-26T19:27:00Z",
      "id": "667c6193d58419f64f4cb403",
      "items": [
        {
          "node": {
            "id": 64,
            "name": "Operating System. undefined",
            "system": {
              "id": 1,
              "name": null
            }
          },
          "metrics": [
            {
              "id": "2ce746c5-1ee3-45d1-b23f-bae56bc5d51a",
              "name": "Committed Virtual Memory Size",
              "metric_type": "int",
              "aggregation": "avg",
              "severity": "severe",
              "started": "2024-06-26T18:42:00Z",
              "updated": "2024-06-26T19:12:00Z"
            },
            {
              "id": "5523ee20-2af2-4b8e-8390-3d2cb4410018",
              "name": "System CPU Load",
              "metric_type": "double",
              "aggregation": "avg",
              "severity": "medium",
              "started": "2024-06-26T19:25:00Z",
              "updated": "2024-06-26T19:26:00Z"
            },
            {
              "id": "a59df24a-e9ec-4c4c-a087-ea1375d4b9c7",
              "name": "Process CPU Load",
              "metric_type": "double",
              "aggregation": "avg",
              "severity": "medium",
              "started": "2024-06-26T19:26:00Z",
              "updated": "2024-06-26T19:27:00Z"
            }
          ]
        }
      ]
    }
  ],
  "closed": [
    {
      "severity": "low",
      "started": "2024-06-26T18:49:00Z",
      "ended": "2024-06-26T19:37:00Z",
      "updated": "2024-06-26T19:37:00Z",
      "id": "667c62f7d58419f64f4cb426",
      "items": []
    }
  ]
}

This alert has anomalies whose values have been updated. This is because the environment used in this tutorial has been running for a while and has experienced different anomalies and changes to these anomalies. In your environment, these anomalies might appear in the new object.

The anomalies are in the Operating System node. A node is a group of metrics that work together. Refer to the official documentation to understand the list of nodes and the metrics underneath these nodes.

This node has a couple of anomalies on the following metrics:

Committed Virtual Memory Size: This metric is flagged as severe, indicating that the Committed Virtual Memory size metric significantly deviates from past observed behavior and has the highest likelihood of being a disruptive anomaly. To learn more about the severity property, check out the official documentation on Alerting.
System CPU Load: This metric indicates the overall CPU load on the system. It has a medium severity, meaning that the metric occasionally deviates from the previously observed and learned behavior. A medium severity indicates a moderate probability that this is an anomaly.
Process CPU Load: This metric indicates the CPU load of a specific process and has a severity value of medium.

Additionally, you can see a Closed Anomalies array containing a previously detected low severity anomaly that has been resolved.

Deciphering the data using Grafana

Now that you have received the alert about the anomalies in the host system let's view these alerts on a Grafana dashboard.

Grafana is fantastic for many reasons, one of which is that it simplifies the visualization of your JSON data and aids in monitoring system metrics. To learn more about how Grafana can benefit you, check out this article on Observability with Grafana and Eyer.

Setting up Grafana with Eyer
To set up and connect Grafana to visualize your Eyer data, follow these steps:

1.Log in to your Grafana account.
2.Launch Grafana Cloud:

In the Grafana Cloud portal page, click the "Launch" button. This will take you to your Grafana Cloud page. Click the "Launch" button again to go to the Dashboard page.

3.Add a new connection:

On the Dashboard page, navigate to the left-hand side menu and select the "Add new connection" tab.
In the "Add new connection" page, select "InfluxDB."

4.Add a new data source:

On the InfluxDB page, click “Add new data source.”

5.Configure the data source settings: On the settings page, set the following configuration fields:

Set “Query language” to “Flux.”
Set “URL” to “https://westeurope-1.azure.cloud2.influxdata.com.”
In the “Auth” section, turn off basic auth.
Under “InfluxDB Details,” enter the “Organization” and “Token” values you received with your InfluxDB details.

6.Save and test the connection:

Click “Save and test.” If the connection works, a notification should pop up, and you can proceed to the next step.

If it doesn't work, double-check your settings. If the problem persists, send a support request or contact us on the official Eyer Discord channel.

7.Create a dashboard:

Click the "building a dashboard" link in this connection pop-up. This will take you to the “Start your new dashboard by adding a visualization” page.

8.Import a dashboard:

On the next page, click “Import a dashboard” to go to the Import dashboard page.
Click “Upload dashboard JSON file” on this page and select the JSON file you received with your InfluxDB details.

You should now have a dashboard containing the core metrics monitored by Eyer, including multiple baselines.

In the image above, you can see some of the core metrics monitored by Eyer, including their data points and primary and secondary baselines, represented in different colors. These data points and baselines are plotted on a time axis (x-axis) and a value axis (y-axis). The different colored lines and shaded areas represent the following:

Data points on your metrics are in yellow
The primary baselines, which indicate the main behaviors of your system, are in red.
The secondary behaviors and baselines are distinguished by two different shades of blue. For more information on baselines and the behaviors they represent, refer to the documentation on Onboarding, preprocessing, and filtering of the data.

It is important to note that the purple shading in the graph results from the overlap between the main and secondary baselines, which are red and blue, respectively.

Understanding the anomalies from the Grafana dashboards
To understand how to recognize anomalies from the Grafana dashboards, this section will look at the Committed Virtual Memory Size, Process CPU Load, and the System CPU Load metrics.

In the images above, the Process CPU Load and System CPU Load data points exist outside the primary baseline (red-shaded areas) but within the secondary baselines, coinciding with their medium severity level.

However, an interesting anomaly observation is the Committed Virtual Memory Size, with data points existing outside the main and secondary baselines. This observation coincides with its severity level.

In summary

Machine learning and artificial intelligence is changing almost everything around us, especially the monitoring and observability space. With modern software development becoming more and more complex, AI-powered insights can be the difference between quickly identifying and resolving issues or experiencing prolonged downtime and performance degradation.

This article demonstrates the power of AI-powered observability by walking through the process of injecting anomalies into a system, querying these anomalies with the Eyer connector, and visualizing them using Grafana.

However, this is just the beginning of what AI-powered insights can do for you. To learn more about Eyer and Grafana and to get started, check out the official Eyer documentation.

Automating user creation with Bash Scripting

Amarachi Iheanacho — Thu, 04 Jul 2024 11:23:41 +0000

Managing users and groups is a fundamental aspect of system administration. Whether you're overseeing a small personal server or a large enterprise network, having a streamlined process for user creation is essential for maintaining security, organization, and efficiency. One of the most powerful tools for automating this task is Bash scripting.

This article walks you through solving user management issues with a Bash script. The script will cover creating accounts, assigning them to personal and general groups, and managing and securing their passwords.

This project is available on GitHub. Check out the repository for the complete script.

The problem statement

You are presented with a problem.

Your company has hired many new developers, and you need to automate the creation of user accounts and passwords for each of them.

As a SysOps engineer, write a Bash script that reads a text file containing the employees’ usernames and group names, where each line is formatted as username;groups.

The text file can also specify multiple groups for the user, formatted as username; group1, group2.

In addition to the multiple groups specified by the text file, each user must have a personal group named after their username.

The script should create users and groups as specified, set up home directories with appropriate permissions and ownership, and generate random user passwords.

Additionally, store the generated passwords securely in /var/secure/user_passwords.csv, and log all actions to /var/log/user_management.log.

How do you automate this workflow with Bash scripting?

Setting up the project

Before diving head first into creating the script itself, let's define what it needs to automate. The script must:

Read User and Group Information: The script will rely on a text file containing user and group information
Create User and Group: For each user specified in the file, the script will create a user account and a personal group
Assign Additional Groups: If additional groups are listed for a user (e.g., user;group1,group2), the script will also assign the user to those groups
Create Home Directories: Each user will have a dedicated home directory created.
Generate Random Passwords: Secure random passwords will be generated for each user and stored in /var/secure/user_passwords.csv
Log Actions: The script will log all its activities to /var/log/user_management.log

Creating the user and group text file
The Bash script relies on a text file to define the users and groups it needs to create.

To create this text file, navigate to your project’s root directory and create a file named text_file.txt. This file should contain lines formatted as follows:



    villanelle; sudo, dev
    eve; dev, www-data

You can replace the usernames and groups with any names you’d like.

Now that you have the text file prepared let's create the Bash script that interacts with it.

Creating the Bash script
Within your project's root directory, create a new file named create_user.sh. This script will handle user creation, group assignment, activity logging, and more.

This script will be made up of different parts, and these are:

1.Ensuring root privileges

The script requires elevated privileges to perform actions like creating users, groups, and modifying permissions. So, you will begin by checking if the user running the script has root access.
In your create_user.sh file, add the following commands to check if the user is root:



    #!/bin/bash
    # Check if the current user is a superuser, exit if the user is not
    if [ "$EUID" -ne 0 ]; then
      echo "Please run as root"
      exit 1
    fi

This code ensures only users with root access can execute the script. If you're not logged in as root, running the script will display an error message and exit.

2.Check if the text file was passed in as an argument

Next, you need to ensure the script receives the text file (text_file.txt) as an argument. To perform this check, add the following lines of code to your create_user.sh file:



    # Check if the file was passed into the script
    if [ -z "$1" ]; then 
        echo "Please pass the file parameter"
        exit 1
    fi

In the code block above, these commands:

[ -z "$1" ]: This checks if the first argument ($1) is empty.
echo "Please pass the file parameter": This message informs the user if the script is missing the required file.
exit 1: Exits the script with an error code if the check fails.

By including this code, you guarantee the script receives the necessary text file to function correctly.

3.Create environment variables for the file

Next, you will create environment variables to hold the paths for the input text file (text_file.txt), the log file (/var/log/user_management.log), and the password file (/var/secure/user_passwords.csv).
To create these variables, add the following lines of code to your create_user.sh file:



    # Define the file paths for the log file, and the password file
    INPUT_FILE="$1"
    LOG_FILE="/var/log/user_management.log"
    PASSWORD_FILE="/var/secure/user_passwords.csv"

4.Create the log and password files

Next, create the log and password files and give them the necessary permissions with this command:



    # Generate logfiles and password files and grant the user the permissions to edit the password file
    touch $LOG_FILE
    mkdir -p /var/secure
    chmod 700 /var/secure
    touch $PASSWORD_FILE
    chmod 600 $PASSWORD_FILE

The commands in the code block above are:

touch $LOG_FILE: Creates a /var/log/user_management.log file
mkdir -p /var/secure: Creates a /var/secure directory that will hold the password file
chmod 700 /var/secure: Sets the permissions so that only the user has read, write, and execute permissions for the /var/secure directory
touch $PASSWORD_FILE: Creates a /var/secure/user_passwords.csv file
chmod 600 $PASSWORD_FILE: Sets the permissions so that only the user has read and write permissions for the /var/secure/user_passwords.csv file

5.Generate the passwords

Next, create the log_message() and generate_password() functions. These functions will handle creating log messages for each action and generating user passwords:



    # Generate logs and passwords 
    log_message() {
        echo "$(date '+%Y-%m-%d %H:%M:%S') - $1" >> $LOG_FILE
    }

    generate_password() {
        openssl rand -base64 12
    }

Here's what each function does:

log_message(): This function appends a log message with the current date and time (formatted as %Y-%m-%d %H:%M:%S) to the $LOG_FILE. It takes a positional parameter $1 representing the message to be logged.
generate_password(): This function uses OpenSSL to generate a random password each time it is called, which is then printed to standard output.

To learn more about the OpenSSL library, refer to the official OpenSSL documentation

6.Creating the users and groups

You have verified that the user is running this script as a superuser. Additionally, you have created variables that hold different file paths pointing to the log, password, and input files.

Next, the script should loop through each entry in the input text file, split these entries by usernames and groups, and then create the users and their respective groups.

To achieve this, include the following commands in your create_user.sh file:



    # Read the input file line by line and save them into variables
    while IFS=';' read -r username groups || [ -n "$username" ]; do
        username=$(echo "$username" | xargs)
        groups=$(echo "$groups" | xargs)
        # Check if the personal group exists, create one if it doesn't
        if ! getent group "$username" &>/dev/null; then
            echo "Group $username does not exist, adding it now"
            groupadd "$username"
            log_message "Created personal group $username"
        fi

        # Check if the user exists
        if id -u "$username" &>/dev/null; then
            echo "User $username exists"
            log_message "User $username already exists"
        else

            # Create a new user with the created group if the user does not exist
            useradd -m -g $username -s /bin/bash "$username"
            log_message "Created a new user $username"
        fi

        # Check if the groups were specified
        if [ -n "$groups" ]; then
            # Read through the groups saved in the groups variable created earlier and split each group by ','
            IFS=',' read -r -a group_array <<< "$groups"
            # Loop through the groups 
            for group in "${group_array[@]}"; do

                # Remove the trailing and leading whitespaces and save each group to the group variable
                group=$(echo "$group" | xargs) # Remove leading/trailing whitespace
                # Check if the group already exists
                if ! getent group "$group" &>/dev/null; then
                    # If the group does not exist, create a new group
                    groupadd "$group"
                    log_message "Created group $group."
                fi

                # Add the user to each group
                usermod -aG "$group" "$username"
                log_message "Added user $username to group $group."
            done
        fi

        # Create and set a user password
        password=$(generate_password)
        echo "$username:$password" | chpasswd
        # Save user and password to a file
        echo "$username,$password" >> $PASSWORD_FILE
    done < "$INPUT_FILE"

    log_message "User created successfully"

    echo "Users have been created and added to their groups successfully"

Let’s break down the code snippet to understand what each part does:

Read the Input File Line by Line:



   while IFS=';' read -r username groups || [ -n "$username" ]; do
       # Code to create the user groups
    done < “$INPUT_FILE”

Explanation:

while …; do … done: This loop iterates over each line in the input field and executes the commands within the do block for each of the line
- IFS=';': Sets the Internal Field Separator (IFS) to a semicolon (;). This tells the read command to split each line in the input file based on semicolons.
- read -r username groups: Reads each line of the input file and splits it into two variables: username and groups. You will need these variables for creating usernames and groups
- || [ -n "$username" ]: This ensures that the loop continues processing the last line even if it doesn't end with a newline character.
Trimming Whitespace:



    username=$(echo "$username" | xargs)
    groups=$(echo "$groups" | xargs)

Explanation:
- This step removes any leading or trailing spaces from the username and groups variables. Extra spaces can cause issues with user and group creation.
- xargs: This command removes any whitespace at the beginning or end of the variable values.

Checking and Creating the Personal Group:



    if ! getent group "$username" &>/dev/null; then
      echo "Group $username does not exist, adding it now"
      groupadd "$username"
      log_message "Created personal group $username"
    fi

Explanation:
- getent group "$username" &>/dev/null: This checks if a group with the username exists. If it doesn't, the groupadd command creates the group, and a log message is recorded.

Checking and Creating the User:



    if id -u "$username" &>/dev/null; then
      echo "User $username exists"
      log_message "User $username already exists"
    else
      useradd -m -g $username -s /bin/bash "$username"
      log_message "Created a new user $username"
    fi

Explanation:

id -u "$username" &>/dev/null: This checks if a user with the specified username exists. If the user does not exist, the useradd function is used to create one, and a log message is recorded.
useradd -m -g "$username" -s /bin/bash "$username": This command creates a new user with the specified name ($username), a home directory (-m), the user's name as the primary group (-g $username), and the Bash shell as the default login shell (-s /bin/bash). For more details, check out how to create users in Linux using the useradd command.
Checking and Assigning Groups:



     # Check if the groups were specified
    if [ -n "$groups" ]; then
        # Read through the groups saved in the groups variable created earlier and split each group by ','
        IFS=',' read -r -a group_array <<< "$groups"

        # Loop through the groups 
        for group in "${group_array[@]}"; do
            # Remove the trailing and leading whitespaces and save each group to the group variable
            group=$(echo "$group" | xargs) # Remove leading/trailing whitespace

            # Check if the group already exists
            if ! getent group "$group" &>/dev/null; then
                # If the group does not exist, create a new group
                groupadd "$group"
                log_message "Created group $group."
            fi

            # Add the user to each group
            usermod -aG "$group" "$username"
            log_message "Added user $username to group $group."
        done
    fi

Explanation:

[ -n "$groups" ]: This checks if the $groups variable is not empty
IFS=',' read -r -a group_array <<< "$groups": This splits the $groups variable by commas, storing each group name as a separate element in an array named group_array.
for loop: This iterates through each group name in the group_array and runs the following commands:
- group=$(echo "$group" | xargs): This removes any leading or trailing spaces from the current group name in the loop.
- if ! getent group "$group" &>/dev/null: This checks if a group exists. If the group does not exist, the groupadd function creates the group, and a log message is recorded.
usermod -aG "$group" "$username": This command adds the user ($username) to the current group ($group)
Generating and Setting a User Password:



    password=$(generate_password)
    echo "$username:$password" | chpasswd
    echo "$username,$password" >> $PASSWORD_FILE

Explanation:

password=$(generate_password): Calls the generate_password() function created earlier and stores its output in a password variable
echo "$username:$password" | chpasswd: Sets the user's password using the password variable
echo "$username,$password" >> $PASSWORD_FILE: Saves the username and password to the password file at the path var/secure/user_passwords.csv
Feeding the Input File into the While Loop:



    done < "$INPUT_FILE"

Explanation:
- done < "$INPUT_FILE": This redirection operator, <, tells the while loop to read its input from the file specified by $INPUT_FILE

When you are done with this section, your create_user.sh file should look like this:

https://gist.github.com/Iheanacho-ai/a572c299428c68e309b549d8d4d4cb4e

With this, you have successfully created a script that effectively manages users and groups in your system.

Testing this script

Once you've written your script, it's time to verify that it works as intended. Here's how to test it:

Running the Script in a Linux Environment

You'll need a terminal that supports Linux commands to run the script. Some options include:

2.Making the Script Executable

Before running the script, you need to grant it execute permission with this command:



    chmod +x create_user.sh

3.Running the Script

Next, execute the script with this command:



    ./create_user.sh ./text_file.txt

If your script is running as it should, you should see this in your terminal:

Next, check your /var/log/user_management.log file to see your logs by running this command:

cat /var/log/user_management.log

Finally, check your /var/secure/user_passwords.csv file with this command to see the users and their passwords:

cat /var/secure/user_passwords.csv

In summary

Throughout this article, you have walked through using Bash to manage users, groups, and their passwords. You have also logged all the actions into a file so that you and anybody else can look back on them and troubleshoot. But this is only the tip of the iceberg when it comes to Bash's capabilities.

With Bash, you can automate a wide variety of administrative tasks, streamline your workflows, and enhance the efficiency of your system management. Whether it's scheduling regular maintenance tasks with cron jobs, managing system updates, or monitoring system performance, Bash provides a powerful
toolset for system administrators.

So stay curious and check out Bash resources for more resources on scripting with Bash for Linux systems.

Deploying a static website with AWS EC2 using Nginx

Amarachi Iheanacho — Mon, 01 Jul 2024 13:26:55 +0000

Amazon Web Services (AWS) is one of the most popular cloud computing platforms worldwide. It offers a comprehensive suite of services that enable developers and businesses to build, deploy, and scale applications with ease.

One of the key advantages of AWS is its flexibility, allowing users to choose from a variety of services to suit their specific needs. This guide will focus on the AWS EC2 service, teaching you how to leverage its virtual machine capabilities to create your own server environment specifically designed to host your static website using the efficient and lightweight Nginx web server.

Prerequisites

To get started with this tutorial, you must have the following:

An AWS account: If you don't have one already, you can create a free tier account AWS website.
Basic understanding of HTML and CSS

Creating the Static website

To start this project, you need to create the static website you want to serve with your NGINX server. This tutorial uses a simple HTML and CSS webpage.



<!DOCTYPE html>
<html lang="en">
<head>
    <meta charset="UTF-8">
    <meta name="viewport" content="width=device-width, initial-scale=1.0">
    <title>My Information</title>
    <style>
        body {
            font-family: Arial, sans-serif;
            margin: 20px;
            padding: 0;
            text-align: center;
        }
        .container {
            max-width: 600px;
            margin: 0 auto;
            border: 1px solid #ccc;
            padding: 20px;
            border-radius: 8px;
            box-shadow: 0 0 10px rgba(0,0,0,0.1);
        }
        h1 {
            color: #333;
        }
    </style>
</head>
<body>
    <div class="container">
        <h1>Hello there, its great that you are checking out my article!</h1>    
    </div>
</body>
</html>

Creating an EC2 instance in your AWS console

An Amazon Web Service EC2 instance is one of the most popular AWS services worldwide. It is a virtual server in the AWS Cloud that provides the computing resources your applications and services need to run, such as CPU, memory, storage, and networking.

To create an EC2 instance, follow these steps:

Log in to your AWS console.
Next, click the search icon at the top, type in EC2, and select it from the menu. This action redirects you to the Resources page.
In the Resources page, click on Instances (running) to get redirected to the Instances page on your AWS console. On the Instances page, click the Launch instance button to define configuration settings for your EC2 instance.
On the Instances page, click the Launch Instance button and configure your instance as follows:
- Name and Tags: Give your EC2 instance a recognizable name.
- Amazon Machine Image (AMI): An AMI is a template used to create virtual servers in Amazon EC2. It contains the operating system, software packages, and configurations needed for launching instances.

This tutorial will use the default Ubuntu AMI.

Instance Type: Select an instance type. This tutorial will use the default t2.micro instance type, which offers 1 vCPU and 1 GiB memory. If you prefer a different instance type with greater system capabilities, simply click the dropdown and choose from the various available options.
Key Pair (Login): Key pairs provide a secure method for connecting to your instance. To create a new key pair, click the Create new key pair link, enter a name for the key pair, and click Create key pair once more to download your newly created key pair.

Network Settings: Network settings define the firewall rules that limit or allow website traffic to your instance. In this section, check the boxes for Allow SSH traffic from Anywhere, Allow HTTPS traffic from the Internet, and Allow HTTP traffic from the Internet.

5.Launch your Instance: Once you've reviewed your configuration, click the Launch Instances button to create your virtual machine on AWS.

Logging into your AWS virtual machine
After creating your AWS EC2 instance, click on the instance ID to navigate to the Instances page.

On this page, select your instance by checking the checkbox next to it, then click the Connect button at the top to initiate the connection.

This action will take you to the Connect to instance page, where you should click the Connect button to establish a connection to your EC2 instance.

Once connected, the EC2 instance will open, and you will see the Ubuntu terminal.

Now that your EC2 instance is all setup, the next step is to configure the NGINX web server to handle web requests and serve your static website.

Installing the Nginx server

Nginx is an open-source web server designed to handle HTTP requests. It processes requests from web browsers and delivers the corresponding web content.
Nginx excels at efficiently delivering static content; it can handle many connections at once, making it suitable for high-traffic websites. Additionally, Nginx is great as a reverse proxy, forwarding requests to other servers or services running on your EC2 instance. To learn more about Nginx, please check out the official Nginx documentation.

To create an Nginx server in your EC2 instance. Run the following commands in your virtual machine Ubuntu terminal:

1.Run this command to switch to the root user and gain the elevated privileges needed to download Nginx:



sudo -i

2.After logging in as the root user, use these commands to update the package index and install NGINX in your system:



apt-get update
apt-get install nginx

3.Next, check the status of the Nginx with this command:



service nginx status

Running the service nginx status command provides information about the status of the NGINX service, including whether it is running or stopped. If the NGINX server is running correctly, you will see the corresponding status in your terminal.

4.To view the default webpage hosted by the NGINX server, copy the Public IP address of your EC2 instance and paste it into your web browser.

You should see a static website like this:

Serving the static website

To serve your static website, replace the HTML code on the index page of the NGINX server with your own website’s HTML code.
To find the index webpage in the NGINX server, navigate to the /var/www/html directory and list the files located there using this command:



cd  /var/www/html/
ls

In this directory, you will see the index.nginx-debian.html file, which is the index page of the NGINX server. To view the content of this file, run the following command:



cat index.nginx-debian.html

The next step is to replace the HTML code in the index.nginx-debian.html file with the HTML code of your static website.

To do this, open the index.nginx-debian.html file in an editor of your choice. This guide will use the nano editor:



nano index.nginx-debian.html

Next, use the arrow keys to navigate and edit the file. When you are done with your edits, press Ctrl + O (the letter 'O', not zero) to save the file. Nano will then prompt you for the file name, index.nginx-debian.html. Press Enter to confirm and save the file.

To exit Nano, press Ctrl + X.

Refresh your Public IP page in your web browser to see your static website.
Congratulations, you have successfully deployed your static website on an AWS EC2 instance using NGINX.

In summary

This article introduces AWS EC2 instances, one of Amazon Web Services' most popular offerings. It guides you through creating and configuring your own EC2 instance, connecting to it, and setting up NGINX to serve your static website. This hands-on approach equips you with the fundamentals of web hosting and cloud infrastructure management.

However, this is just the beginning. AWS offers a wide range of services that are worth exploring. As you follow my journey, we will cover some of these services. Additionally, you can dive deeper into NGINX for more complex configuration options and learn about security best practices for managing EC2 instances.

Happy coding!

Observability with Grafana and Eyer

Amarachi Iheanacho — Sat, 22 Jun 2024 10:57:48 +0000

Modern infrastructure is becoming increasingly complex, with microservices, cloud deployments, and distributed architectures making it challenging to understand how everything functions together. This complexity has begged the need for the unparalleled visibility that observability promises.

Observability provides a comprehensive view of your system, allowing you to identify issues before they escalate. Tools like Eyer play a crucial role in achieving observability. Eyer helps gather and analyze system data, revealing anomalies, affected nodes, and potential future problems. With this insight, you can quickly pinpoint issues using Eyer, leading to less downtime and a smoother user experience.

However, the raw data from Eyer might be difficult for non-technical individuals or teams to understand. This is where Grafana comes in. As a powerful visualization tool, Grafana transforms this data into clear and insightful dashboards, making it accessible to everyone who needs it.

This article explores Eyer, its importance in modern observability discussions, and the added value of integrating it with Grafana.

Understanding Eyer and its capabilities

Eyer is an AI-powered observability tool that provides insights into your Boomi integrations. Boomi has become an integration superpower, uniting diverse applications and data sources with its simple and intuitive drag-and-drop design. With Eyer, you can take that impeccable user experience to the next level.

By installing and using the Eyer connector, you can collect data from your Boomi integrations, send it to the Eyer machine learning pipeline, and gain insights into what's wrong with your Boomi process.

The machine learning pipeline learns the user Boomi Atom’s behavior and establishes what normal behavior or baselines are for your Atom. So, any significant and prolonged deviations from the normal behavior are flagged.

For example, if your Boomi Atom is using more memory than normal or CPU utilization is higher than usual, the Eyer connector will send you a JSON alert. You can choose to receive this alert conveniently via email or even as a file saved directly on your host machine, thanks to the flexibility of Boomi's connectors.

JSON format alerts are advantageous for many reasons: they are structured, human-readable, lightweight, language-agnostic, and can be easily integrated into various systems for automated processing and response. However, while JSON alerts do not have inherent visualization capabilities, tools like Grafana lend them the ability to visualize data over time.

Grafana: The solution to all your visualization problems

Grafana is an open-source analytics and interactive visualization web application tool used to monitor application performance. This section explores how Grafana allows Eyer users to query, visualize, and understand their JSON alerts.

Benefits of the Grafana integration with Eyer

By integrating Grafana with Eyer, developers have access to powerful visualization capabilities. Some key benefits of this integration include:

Visualization: If you only remember one thing from this article, remember that Grafana is the king of data visualization. This visualization is amazing for democratizing data use. Visual representation allows users to quickly understand the data and see patterns and trends that might be missed when looking at raw JSON.

Historical analysis: Another powerful feature of Grafana is its ability to store and visualize historical alert data. Imagine trying to understand a month's worth of system activity by manually reviewing individual JSON alerts; this gets tiring quickly. Grafana offers a much better solution. By aggregating all the data for a specific metric into a single graph, you can easily see trends over days, weeks, or months. This historical view allows you to identify potential issues, forecast future resource needs, and gain insights into long-term performance patterns.

Collaboration and sharing: Grafana makes it easy to share dashboards and visualizations with team members. That way, more people can watch and understand what's happening in your systems. These shared insights make it easier for teams to work effectively to address and resolve issues.

Open-source, extensible: As an open-source tool, Grafana is free to use and allows users to access and modify the source code, enabling customization to meet specific needs. Its extensibility is one of its core strengths, with a vast ecosystem of plugins available that extend its functionality, including integrations with a wide range of data sources, custom visualizations, and alerting mechanisms. This flexibility makes Grafana adaptable to various use cases and industries.

Large community support: Grafana benefits from a large and active community of users and developers. This community support is invaluable, providing a wealth of shared knowledge, tutorials, forums, and plugins. The collaborative nature of the community ensures continuous improvements and updates, keeping Grafana at the forefront of monitoring and visualization tools. This robust support network also means that users can easily find help and resources to solve problems and optimize their platform use.

Integrating Eyer with Grafana: In addition to being easy to use, one of the things that makes Eyer stand out is its clear documentation. To learn how to integrate Eyer with Grafana, check out the Grafana section on the Eyer documentation.

Summing it up

The more complex modern infrastructure becomes, the more visibility you need to ensure that these infrastructures do not collapse underneath its own complexity. Observability tools like Eyer give you this visibility. With Eyer acting as a watchdog over your processes and Boomi integrations, you can sleep well at night knowing that if something is about to or does go wrong, you will be alerted immediately.

Eyer's strengths are elevated even further with the integration of visualization tools like Grafana, which translates these Eyer JSON into clear dashboards. These dashboards allow you to see, at a glance, the health of your Boomi integrations.

With Grafana visualizations, you can quickly identify trends, predict potential problems, and troubleshoot issues. In short, Eyer and Grafana working together provide you with the comprehensive visibility you need to ensure the smooth operation of your complex modern infrastructure, giving you peace of mind and allowing you to focus on more strategic initiatives.

To gain AI-powered insights and visualization for your Boomi integration, check the Eyer website and join the Discord community for more information and support.

Giving Back to the Boomi Community: How Your Contributions Make a Difference

Amarachi Iheanacho — Fri, 07 Jun 2024 20:11:02 +0000

Everybody wants to be part of a community—a group of people who validate a person’s thoughts and feelings and help them out during difficult situations. In the Boomi community by Eyer, this group of people are Boomi engineers.

The community provides a sense of belonging and support that transcends individual achievements, fosters a culture of collaboration, and forges friendships that can last a lifetime. However, as with any partnership or relationship of any substance, the community and its people thrive on the principle of give and take.

In this article, you will learn what giving back to the Boomi community can do for you and, more importantly, the best way to give back.

What do you gain from giving back to the Boomi community?

Helping your community is undeniably a good thing, but sometimes that “warm fuzzy feeling" isn't enough motivation for everyone. The good news is that giving back offers a ton of benefits beyond just feeling good. Here are some of the advantages you can gain by getting involved:

Skills development: Helping out community members is a guaranteed way to enhance your Boomi integration skills. It's a fantastic opportunity to learn new techniques, refine existing skills, and apply your experience to solve interesting problems in new ways.
Networking opportunities: Giving back and volunteering are amazing ways to meet like-minded people who share your passion for Boomi and mentorship. These activities guarantee valuable connections that can benefit you personally and professionally.
Build a professional brand: By consistently sharing your Boomi knowledge or volunteering to help others, you'll rapidly establish yourself as the go-to expert for all things Boomi. This includes opportunities, inquiries, and much more, and the best part is that your reputation extends beyond the Boomi ecosystem!
Leaving a positive impact: Contributing to the Boomi community is a powerful way to leave a positive mark. Sharing your knowledge and skills empowers others to grow and achieve their goals. Your insights can inspire and uplift fellow developers, creating a supportive and innovative space for everyone. This not only strengthens the entire community but also solidifies your reputation as a valuable and generous member.

What are the different ways to contribute to the Boomi community?

While how you contribute to a community can vary based on its needs (some might value open-source contributions or leadership roles), here are some universal ways to give back, especially within the Boomi community by Eyer:

Time commitment: Actively participate in discussions within the Boomi community by Eyer. Provide insightful solutions and clear explanations to Boomi developers.

Volunteer at Boomi-sponsored, Eyer-sponsored, and Boomi-related events in your local tech community. Lend a hand with logistics and setup or even lead breakout sessions on specific Boomi topics.

Skill-based contributions: One of the most efficient ways to become a thought leader in the Boomi community is to share your expertise. You can create blog posts, tutorials, or short guides addressing common integration challenges other Boomi developers face.

Guide and support fellow Boomi users, particularly those new to the platform. Offer advice, answer questions on the Boomi community forum or the Boomi community by Eyer discord, and help them navigate the integration world.

Acts of kindness (within the Boomiverse): Finally, if you are all out of time and you see yourself not being able to commit as much as you would like to, you can contribute to the community by recognizing valuable contributions made by other members by upvoting their responses in forum discussions. This helps elevate quality content and ensures others find the information they need.

Extend a warm welcome to new members in the forums or online events. Offer to answer basic questions and help them navigate the Boomiverse’s resources.

Additionally, when someone goes above and beyond to help you, acknowledge their effort with a positive comment or a "thank you."

Wrapping up

Hopefully, this article was enough to incentivize you to contribute more to your Boomi communities. Helping Boomi developers out, volunteering, and showing gratitude in the smallest ways are some of the best ways to provide value.

Sure, the idea is to give without expecting anything in return, but you can think of the rewards as a natural consequence of doing good. People will trust your Boomi expertise more because they've seen it in action and benefited from it. They can vouch for your character because you chose to volunteer when you didn't have to. This is an amazing position in a world run by referrals and recommendations.

So, take the first steps, join the Boomi community by Eyer, and start your journey today!

Forem: Amarachi Iheanacho

Securing your AWS EKS cluster

Understanding the EKS security landscape

Control plane security

Network security

Pod security

Secrets management

Image security

Monitoring and logging

Wrapping up your EKS security journey

Provision an AWS EC2 jumphost using Terraform and GitHub Actions

What this series will contain

Clone the quiz application

Prerequisites

Project structure

Pre-project setup checklist

Create an AWS access key and secret access key

Create an S3 bucket

Create an SSH key

Add the credentials to your GitHub secrets

Provisioning the jumphost with Terraform

Define your Terraform variables in your [variables.tf] file

Set your EC2 instance configuration using Terraform

Define your outputs in the outputs.tf file

Creating the initialization script

Automating Terraform deployments with GitHub Actions

Running your CI/CD pipeline

Verify and review your project

Final thoughts

Automate testing and Docker image deployment to Amazon ECR with CI.

What this series contains

Prerequisites

Project structure overview

Pre-project setup checklist

Set up your AWS ECR repositories

Set up SonarCloud

Set up Snyk

Configure your GitHub secrets

Understanding the CI/CD pipeline architecture

Building the CI/CD workflow

Pipeline breakdown and analysis

Stage 1: Application testing

Step 2: Security scanning

Stage 3: Container image creation and security

Running your pipeline

What's next

Final thoughts

What are Helm charts?

Prerequisites

Core Helm concepts

Helm chart anatomy

Directory structure

Installing and using a Helm chart

Deploying the Helm chart

Viewing your application

Upgrading and rolling back releases

Upload your Helm chart to a repository

Verify that your Helm chart was uploaded successfully

Wrapping up

Understanding Kubernetes by deploying a real-world application

The project summary

Prerequisites

Definition of terms

Step 1: Setting up the project

Step 2: Create a ConfigMap to store MongoDB environment variables

Step 3: Set up a Persistent Volume for storing MongoDB data

Step 4: Create a PersistentVolumeClaim to request storage from the Persistent Volume

Step 5: Set up a MongoDB Deployment to manage your MongoDB pods

Step 6: Create an internal Service to connect MongoDB with the Todo application

Step 7: Apply the configuration to deploy your MongoDB application

Step 8: Set up a ConfigMap to manage environment variables for your Todo application

Step 9: Setting up a Deployment for your Todo application

Step 10: Create an external Service to expose your Todo application to external traffic

Step 11: Apply the configuration to launch your Todo application

Wrapping up

What is an F1 score?

Understanding the importance of F1 score in classification models

Understanding the possible outcomes of a classification model

What are precision and recall?

Limitations of using precision as a classification metric without recall (and vice versa)

Define your Terraform variables in your `[variables.tf]` file

Define your outputs in the `outputs.tf` file