Forem: M. Oly Mahmud

Running Kubernetes in Docker (KIND) Locally While Your Cluster Lives in Google Cloud Shell

M. Oly Mahmud — Tue, 31 Mar 2026 08:07:54 +0000

You want to develop with Kubernetes locally using KIND, but your laptop doesn't have enough resources. Google Cloud Shell has plenty of compute, but it's not meant for long-running clusters. So run KIND in Cloud Shell and control it from your machine.

The benefits of it:

Cloud Shell has more compute than your dev machine
Your laptop stays clean
No Docker Desktop overhead

Create Your KIND Cluster in Cloud Shell

First, the cluster config. The important part is extraPortMappings—this exposes ports 80 and 443 to Cloud Shell.

kind: Cluster
apiVersion: kind.x-k8s.io/v1alpha4
name: streamx-cluster
nodes:
  - role: control-plane
    image: kindest/node:v1.35.1
    extraPortMappings:
      - containerPort: 80
        hostPort: 80
        protocol: TCP
      - containerPort: 443
        hostPort: 443
        protocol: TCP
  - role: worker
    image: kindest/node:v1.35.1
  - role: worker
    image: kindest/node:v1.35.1

Create it and verify:

kind create cluster --config kind-config.yaml
kubectl cluster-info --context kind-streamx-cluster

Export the Kubeconfig

KIND generates a kubeconfig automatically. Export it to a file you can move:

kind export kubeconfig --name streamx-cluster --kubeconfig my-cluster-config.yaml
cat my-cluster-config.yaml

Copy the Kubeconfig to Your Local Machine

gcloud cloud-shell scp cloudshell:~/my-cluster-config.yaml localhost:~/my-cluster-config.yaml

Set Up Port Forwarding

Your cluster's API server is in Cloud Shell on 127.0.0.1:46151 (check your kubeconfig). Tunnel it through SSH:

gcloud cloud-shell ssh --ssh-flag="-f" --ssh-flag="-N" --ssh-flag="-T" --ssh-flag="-L 46151:127.0.0.1:46151"

The flags:

-f runs in the background
-N just forward ports, don't run a remote command
-T no pseudo-terminal
-L 46151:127.0.0.1:46151 forwards your local port to the remote one

The tunnel stays open as long as your Cloud Shell session is active.

Connect kubectl Locally

export KUBECONFIG="~/my-cluster-config.yaml"
kubectl get nodes

You should see your control plane and worker nodes. If you get a certificate error, check that your SSH tunnel is running.

Deploy Nginx

Create nginx-deployment.yaml:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
  labels:
    app: nginx-deployment
spec:
  replicas: 3
  selector:
    matchLabels:
      app: nginx-deployment
  template:
    metadata:
      labels:
        app: nginx-deployment
    spec:
      containers:
      - name: nginx
        image: nginx:latest
        ports:
        - containerPort: 80

And nginx-service.yaml:

apiVersion: v1
kind: Service
metadata:
  name: nginx-nodeport-service
spec:
  type: NodePort
  selector:
    app: nginx-deployment
  ports:
    - protocol: TCP
      port: 80
      targetPort: 80
      nodePort: 32000

Deploy it:

kubectl apply -f nginx-deployment.yaml
kubectl apply -f nginx-service.yaml
kubectl port-forward svc/nginx-nodeport-service 8080:80

Open http://localhost:8080. You're looking at Nginx running in a pod in Cloud Shell.

Thanks for reading

Part-4: Automating EC2 Infrastructure using Terraform | Amazon Web Services (AWS)

M. Oly Mahmud — Thu, 19 Feb 2026 06:11:34 +0000

Earlier, we created an EC2 instance by hand in the AWS Console. Now we’ll do the same thing with Terraform.

In this guide, we will walk through how to use Terraform to create an EC2 instance on AWS, generate an SSH key, and install Nginx when the server boots. All of it is automated using code.

Prerequisites

You should have:

An AWS account
Terraform installed on your machine
An IAM user with an access key and secret key
A general idea of how EC2 works
A basic understanding of Terraform (providers, resources, variables, outputs)

Directory Structure

Here’s the Terraform project layout we will use:

.
├── instance.tf
├── key_pair.tf
├── output.tf
├── provider.tf
├── terraform.tfvars
└── variables.tf

Each file handles a specific part of the deployment.

Provider Configuration

Start with the provider definition in provider.tf:

terraform {
  required_providers {
    aws = {
      source  = "hashicorp/aws"
      version = "6.15.0"
    }
  }
}

provider "aws" {
  region     = var.region
  access_key = var.access_key
  secret_key = var.secret_key
}

This tells Terraform to use the AWS provider and defines how to authenticate.
In practice, you should avoid storing credentials in code or tfvars files — use the AWS CLI (aws configure) or environment variables for safer authentication.

Defining Variables

In variables.tf, define the parameters Terraform will use.

variable "access_key" {
  type = string
}

variable "secret_key" {
  type = string
}

variable "region" {
  type    = string
  default = "eu-north-1"
}

variable "file_name" {
  description = "Local file name for private key"
  type        = string
}

These variables make the configuration reusable. For example, you can switch AWS regions or key names without touching the main code.

Creating an SSH Key Pair

key_pair.tf handles SSH key generation and registration with AWS.

resource "tls_private_key" "rsa-4096-key" {
  algorithm = "RSA"
  rsa_bits  = 4096
}

resource "local_file" "tf_key" {
  content  = tls_private_key.rsa-4096-key.private_key_pem
  filename = var.file_name
}

resource "aws_key_pair" "demo-key-pair-tf" {
  key_name   = "demo-key-pair-tf"
  public_key = tls_private_key.rsa-4096-key.public_key_openssh
}

The TLS provider generates a 4096-bit RSA key.
The local_file resource writes the private key locally as a .pem file.
The aws_key_pair resource uploads the public key to AWS.

Once deployed, you’ll use the .pem file for SSH access to your EC2 instance.

Defining the EC2 Instance

instance.tf defines both the EC2 instance and the security group.

resource "aws_instance" "web-server" {
  ami             = "ami-0a716d3f3b16d290c"
  instance_type   = "t3.micro"
  key_name        = aws_key_pair.demo-key-pair-tf.key_name
  security_groups = [aws_security_group.demo-sg.name]

  user_data = <<-EOF
  #!/bin/bash
  apt update -y
  apt install nginx -y
  systemctl enable nginx
  systemctl start nginx
EOF

  tags = {
    Name = "web-server"
  }
}

What happens here

Terraform launches an Ubuntu 24.04 EC2 instance using the AMI ID above.
A user_data script runs automatically on boot:
- Updates packages
- Installs and starts Nginx
- Enables it to start on boot
By the time Terraform finishes, Nginx is already serving traffic.

Security Group

resource "aws_security_group" "demo-sg" {
  name = "demo-sg"

  ingress {
    description = "SSH access"
    from_port   = 22
    to_port     = 22
    protocol    = "tcp"
    cidr_blocks = ["0.0.0.0/0"]
  }

  ingress {
    description = "HTTP access"
    from_port   = 80
    to_port     = 80
    protocol    = "tcp"
    cidr_blocks = ["0.0.0.0/0"]
  }

  ingress {
    description = "HTTPS access"
    from_port   = 443
    to_port     = 443
    protocol    = "tcp"
    cidr_blocks = ["0.0.0.0/0"]
  }

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

It allows:

SSH (22) for remote access
HTTP (80) and HTTPS (443) for web traffic
All outbound traffic for updates and package installations

Outputting Useful Information

In output.tf, display key connection details after provisioning:

output "aws_instance_public_ip" {
  value = aws_instance.web-server.public_ip
}

output "aws_instance_public_dns" {
  value = aws_instance.web-server.public_dns
}

After terraform apply, you’ll see the public IP and DNS name printed on your terminal.

Deploying the Infrastructure

Create a terraform.tfvars file to provide variable values:

region = "eu-north-1"

access_key = "YOUR_ACCESS_KEY"
secret_key = "YOUR_SECRET_KEY"
file_name  = "demo-key.pem"

You can also use environment variables to assign values for access_key and secret_key.

export TF_VAR_access_key="YOUR_ACCESS_KEY"
export TF_VAR_secret_key="YOUR_SECRET_KEY"

Once all files are in place, run:

terraform init
terraform plan
terraform apply

Terraform will:

Generate a key pair
Create a security group
Launch the EC2 instance
Run the Nginx installation script
Print the public IP and DNS

Open the public IP in your browser.
You should see the Nginx welcome page — that confirms a successful automated deployment.

Verifying from the Instance

You can SSH in if you want to verify Nginx status:

chmod 400 demo-key.pem
ssh -i demo-key.pem ubuntu@<public_ip>
sudo systemctl status nginx

Cleaning Up

When you’re done testing:

terraform destroy

This removes the instance, key pair, and security group.
Terraform tracks all managed resources, so cleanup is safe and predictable.

Conclusion

We've automatically deployed a secure, Nginx-powered EC2 instance using Terraform.

AWS Elastic Compute Cloud (EC2) | Amazon Web Services (AWS)

M. Oly Mahmud — Mon, 15 Dec 2025 15:53:42 +0000

Amazon EC2 offers cloud-based virtual machines, commonly found within AWS. Rather than using real computers, users run these on remote systems. We'll guide you through setting up an Nginx web host gradually. During this process, key concepts will be explained clearly but briefly.

Step 1: Sign in to AWS Console

Head to the AWS Management Console then sign in. This interface serves as your central hub for using AWS tools.

Step 2: Go to EC2 Dashboard

Amazon EC2 (Elastic Compute Cloud) offers on-demand computing power in the cloud. It's like leasing virtual servers from Amazon’s infrastructure, yet you can adjust resources anytime based on demand.

With EC2, pricing follows usage - no need to buy fixed hardware. Instances start or stop within minutes, offering flexibility through scalable access instead of permanent setups

Look up EC2 and open it.

You’ll notice a sight similar to this one.

Next, select instances.

Step 3: Launch a New Instance

An instance is basically a virtual computer hosted on AWS systems. While setting up one, you’re reserving hardware resources such as processing power, RAM, disk space, along with software to run it.

Click Launch Instance.

Step 4: Name the Instance

Assign a name - such as web-server- to the instance. Use this tag to recognize it within the AWS dashboard.

Step 5: Choose an AMI

An AMI serves as a ready-made blueprint for launching virtual machines. It includes:

The operating system (like Ubuntu, Amazon Linux, or Windows)
Optional application software
Configuration settings

For example, choosing Ubuntu 24.04 means your instance will boot up with that OS installed, ready for use.

Select an AMI (Amazon Machine Image).

Step 6: Choose Instance Type

Instance types define processing speed, RAM size, connection efficiency, or disk space.

For example:

t3.micro: compact, affordable - ideal for practice or light tasks
m5.large: a solid choice for everyday applications due to its well-rounded performance
c6g.xlarge: built for intense computing workloads

AWS provides various instance type groups tailored to specific needs - like general computing, high-performance processing, or enhanced memory capabilities - alongside options powered by GPUs.

Select an instance type - it sets the hardware for your server. I’ll go with t3.micro this time.

Step 7: Create a Key Pair

Upon logging into a regular computer, one enters a username followed by a password. In contrast, EC2 relies on key pairs - set up by AWS - for verification. Each key pair includes two parts:

A public key stored in AWS
A private key (a .pem file) save it on your computer

While connecting via SSH, AWS verifies your private key against the one stored publicly on the machine - confirming alignment without requiring a password. That method allows safe login through cryptographic validation instead of credentials.

If access is lost to the private key file, login becomes impossible - store it securely. Alternatively, losing this file blocks entry entirely; handle with care.

Select create key pair then proceed.

Call it something. Leave the rest as is.

Generate the key pair now.

Step 8: Configure Security Groups

A security group acts like a digital barrier, managing data flow to your system. This setup specifies accessible ports alongside permitted users. While it blocks unwanted connections, it allows approved communications through designated channels.

With this arrangement, it’s necessary to permit:

SSH (port 22): this allows terminal access to your instance
HTTP (port 80): this means users reach the web server through a browser

For practice, allow these ports from any IP address (0.0.0.0/0). In real use, restrict SSH access to just your IP - this improves safety.

Step 9: Launch the Instance

Click Launch Instance. After that, AWS sets up your virtual machine.

In just moments, you’ll see it appear on your EC2 dashboard.

Step 10: Connect to the Instance

Select an instance, then choose Connect. With the SSH Client option selected, execute the AWS-provided command in your terminal - it appears as follows:

ssh -i "demo-key-pair.pem" ubuntu@<Public-IP>

This links your computer to the EC2 server safely; alternatively, different choices are available.

Step 11: Install Nginx

Once linked, execute this command :

sudo apt update && sudo apt install -y nginx

This refreshes your package manager while setting up the Nginx web server.

Step 12: Access the Server in a Browser

Take the Public IPv4 address from your instance on the EC2 dashboard - enter it into a web browser.

You ought to view the Nginx welcome screen - this shows the server’s active and reachable online.

Step 13: Terminate the Instance

Once testing finishes, shut down the instance - skipping this step could lead to ongoing charges. Here's how:

Go to the EC2 dashboard
Select your instance
Click Instance State → Terminate instance

Terminating a server removes it forever. When temporary shutdown is needed, use Stop instead - this keeps your data safe. Choosing one action or another depends on whether files should stay intact after halting operations.

Wrapping Up

So, we've explored:

EC2 delivers adjustable virtual machines through the cloud
A single instance means a virtual machine actively operating within the cloud environment
An AMI serves as the operating system plus application blueprint needed to start instances
Instance types define the hardware power and performance of your server
Key pairs protect access through public-private verification methods
Security groups work like firewalls deciding which users reach your system, by setting clear entry rules based on trusted sources

AWS Identity and Access Management (IAM)

M. Oly Mahmud — Sun, 07 Dec 2025 15:03:21 +0000

AWS IAM decides who gets into your account. So, it sets limits on the actions people can take. Also, it picks which tools they’re allowed to use. Get clear on users, groups, roles, and rules - one by one - and things start making sense fast.

IAM Users

A person needing AWS access is set up as an IAM user. They’re given a name, plus a sign-in password for the web interface. Access codes might also be added - these help when using command tools or software kits.

What someone adds

Username
Password (for console)
Access keys (for CLI)
MFA settings

Beginner-friendly example

You bring on a new person called Ali. Then you set up:

User: ali
Console login: yes
MFA: enabled

Ali’s set up as a user, yet lacks access rights. Rather than assigning each permission separately, toss him into a group instead.

IAM Groups

Groups help give access to multiple people together. Put rules on a group - everyone inside gains that access straight away.

Common group examples

developers
read-only
admins

Example inside this topic

If you’ve got five coders, here’s what could happen:

Group: developers
Policy: Read-only access to EC2 and S3

Next, bring Ali into the team. Right away, he’s given access to develop - no extra actions needed.

IAM Roles

A role acts like a short-term ID for AWS services - or even users - when they need access. It doesn't come with passwords or permanent keys. Instead, AWS hands out time-limited credentials once it's activated.

Roles are best for giving AWS services permission to talk to other AWS services.

Where roles get applied

EC2 → S3
Lambda → CloudWatch
Temporary access sessions

Example: EC2 instance listing S3 buckets

Let’s say your EC2 instance needs to run aws s3 ls to see all S3 buckets.

You do this:

Create a role

   Role name: EC2S3ListRole
   Trusted entity: EC2

Attach a policy that allows listing S3 buckets:

   {
     "Version": "2012-10-17",
     "Statement": [
       {
         "Effect": "Allow",
         "Action": "s3:ListAllMyBuckets",
         "Resource": "*"
       }
     ]
   }

Attach the role to your EC2 instance.

Now the instance can list S3 buckets safely without storing access keys.

IAM Policies

Policies come as JSON files showing which actions can be allowed or blocked. A user, group, or role only works once a policy is linked to it.

A policy contains

Effect: Allow or Deny
Action: What can be done
Resource: Where the action applies
Condition: Optional extra rules

A basic case within this subject

A policy to list all S3 buckets:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": "s3:ListAllMyBuckets",
      "Resource": "*"
    }
  ]
}

A policy to read objects in one bucket:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": "s3:GetObject",
      "Resource": "arn:aws:s3:::my-example-bucket/*"
    }
  ]
}

We attach these policies to a group or a role depending on who needs the access.

A Practical Way to Master AWS IAM

We go step by step through a full training run - create an IAM user, review permissions, attach a policy, assign an EC2 instance role, after that test everything using AWS CLI commands.

The main goal is to understand how users, groups, roles, and policies work together.

1. Start With IAM Users

Create a new IAM user

Open the AWS Console and go to IAM.

Select Users from the left menu.
Choose Create user.
Enable Access to the AWS Management Console.
Pick Autogenerated password and leave everything else as default.

Continue to the next page.
On the permissions page, keep the defaults and go next.
Review everything and create the user.
Download the credentials CSV file.

Return to the user list.

Test login

Copy the sign-in URL shown on the user details page.
Paste it into an incognito window.
Log in with the autogenerated password.
The console will ask you to reset the password.
After logging in, you will see the default AWS console but with no permissions.

2. Test Lack of Permissions

This is important because it shows how IAM actually blocks actions.

Try creating an S3 bucket

Search for S3 in the AWS search bar.

Open the S3 service.

Select Create bucket.
Add a globally unique bucket name.

Keep everything default and try to create it.

You’ll get an error like:

To create a bucket, the s3:CreateBucket permission is required.
User is not authorized to perform: s3:CreateBucket …

This confirms the user has zero permission by default.

3. Add Permissions Using a User Group

Go back to the root account.

Create an S3 access group

Go to IAM > User groups.
Click Create group.
Name it s3-manager.

Add your IAM user (for example, “random”).
Search for AmazonS3FullAccess and attach it.

Create the group.

Test again as the IAM user

Log in again as the IAM user.
Go to S3 > Create bucket.
Try creating the bucket again.

This time the bucket should be created successfully.

4. Add EC2 Permissions Through Another Group

Back to the root account.

Create EC2 admin group

Go to IAM > User groups.
Create a group named ec2-admin.
Attach the AmazonEC2FullAccess policy.
Add your IAM user to this group.

Now the user has both S3 full access and EC2 full access.

5. Launch an EC2 Instance

Go to EC2.
Click Launch instance.
Name it management-server.
Choose Amazon Linux 2023.
Instance type: t2.micro.
Use the default VPC and defaults for other settings.
Create a key pair and download it.
Allow SSH from anywhere.
Launch the instance.

Connect

Use SSH or the EC2 “Connect” button.

Test access

Run:

aws s3 ls

You’ll see:

Unable to locate credentials. You can configure credentials by running "aws configure".

This shows that an EC2 instance does not inherit the logged-in user’s permissions.
Instances need IAM roles, not IAM users.

6. Create an IAM Role for EC2

Back to the root account.

Create a role

Go to IAM > Roles.
Choose Create role.

Select AWS service.
Pick EC2 as the use case.
Continue.
Search for AmazonS3FullAccess and attach it.

Name the role s3-manager.
Create the role.

Attach the role to the instance

Go to EC2 > Instances.
Select your instance management-server.
Actions > Security > Modify IAM role.

Choose s3-manager.
Update the role.

7. Test the Role on the EC2 Instance

Connect again to the instance.

Run:

aws s3 ls

This time it should list your buckets.

)

You’ve now validated:

IAM user without permissions
IAM group with permissions
IAM policy attachment
EC2 instance role
Credential-less CLI access through instance role

This is the exact workflow used in real AWS environments.

8. Clean Up

Delete everything you created:

S3 bucket
IAM user
IAM groups
IAM role
EC2 instance
Key pair

Conclusion

AWS IAM makes more sense when you picture how each piece connects. People get identified by users, while groups bundle up permissions neatly. Roles hand out short-term access to AWS tools instead of permanent keys. Policies lay down the rules on which actions actually work. Try logging in as someone with limited rights - it shows what restrictions feel like firsthand. Toss a user into a group and watch their powers change without touching individual settings. Hook a role to an EC2 machine, then see it talk to other services solo. These moves prove how IAM locks things down tight. Learn this core stuff and you’ll tweak access without second-guessing every click.

Unit Testing Using Spring Boot, JUnit and Mockito

M. Oly Mahmud — Fri, 31 Oct 2025 00:00:00 +0000

Testing is very important to develop a good software. In this guide. We'll see how to perform unit testing in a Spring Boot app. I'll try to make it as simple as possible.

1. What is Unit Testing?

Unit testing is the process of testing individual parts (units) of your application. In unit testing, we test the functions or methods, in isolation.

The goal is to make sure each unit works as expected.

Examples of unit testing are,

Testing if a method correctly saves a todo item.
Testing if fetching by ID returns the correct item.
Testing if delete operation calls the repository properly.

2. Project Overview

Here’s the structure of our Spring Boot project:

src/main/
├── java/com/example/unittesting
│   ├── controller/TodoController.java
│   ├── entity/Todo.java
│   ├── repository/TodoRepository.java
│   ├── service/TodoService.java
│   ├── service/impl/TodoServiceImpl.java
│   └── UnitTestingApplication.java
└── resources/
    └── application.properties

src/test/
└── java/com/example/unittesting
    └── service/TodoServiceImplTest.java

We’ll focus on the service layer tests because they are perfect for unit testing with Mockito (no need to connect to the real database).

3. Entity Layer

The Todo entity represents a single task.

@Entity
@Data
@AllArgsConstructor
@NoArgsConstructor
public class Todo {
    @Id
    @GeneratedValue(strategy = GenerationType.IDENTITY)
    private Long id;
    private String title;
    private boolean completed;
}

This is a simple JPA entity with id, title, and completed fields.

4. Repository Layer

@Repository
public interface TodoRepository extends JpaRepository<Todo, Long> {
}

This interface extends JpaRepository, giving you built-in CRUD operations.

We won’t test this layer directly because Spring Data JPA already provides these methods. Instead, we’ll mock it in our service tests.

5. Service Layer

The TodoService defines our business operations:

public interface TodoService {
    List<Todo> getAllTodos();
    Todo getTodoById(Long id);
    Todo createTodo(Todo todo);
    Todo updateTodo(Long id, Todo todo);
    void deleteTodo(Long id);
}

The implementation:

@Service
public class TodoServiceImpl implements TodoService {
    private final TodoRepository todoRepository;

    public TodoServiceImpl(TodoRepository todoRepository) {
        this.todoRepository = todoRepository;
    }

    @Override
    public List<Todo> getAllTodos() {
        return todoRepository.findAll();
    }

    @Override
    public Todo getTodoById(Long id) {
        return todoRepository.findById(id).orElse(null);
    }

    @Override
    public Todo createTodo(Todo todo) {
        return todoRepository.save(todo);
    }

    @Override
    public Todo updateTodo(Long id, Todo todo) {
        return todoRepository.save(todo);
    }

    @Override
    public void deleteTodo(Long id) {
        todoRepository.deleteById(id);
    }
}

This layer is perfect for unit testing because it calls the repository and contains logic we can verify.

6. Writing Unit Tests with Mockito and JUnit 5

Our test class:

src/test/java/com/example/unittesting/service/TodoServiceImplTest.java

@ExtendWith(MockitoExtension.class)
class TodoServiceImplTest {

    // Mock the repository to avoid using a real database
    @Mock
    private TodoRepository todoRepository;

    // Inject the mock into our service implementation
    @InjectMocks
    private TodoServiceImpl todoServiceImpl;

    // ---------- Test 1 ----------
    @Test
    void createTodo_shouldSaveAndReturnTodo() {
        // Arrange: create a sample Todo and mock repository behavior
        Todo todo = new Todo(1L, "Buy groceries", false);
        when(todoRepository.save(todo)).thenReturn(todo);

        // Act: call the method
        Todo created = todoServiceImpl.createTodo(todo);

        // Assert: check if returned object is correct
        assertNotNull(created);
        assertEquals(1L, created.getId());
        assertEquals("Buy groceries", created.getTitle());
        assertFalse(created.isCompleted());
        verify(todoRepository, times(1)).save(todo); // verify repository interaction
    }

    // ---------- Test 2 ----------
    @Test
    void getAllTodos_shouldReturnAllTodos() {
        // Arrange
        Todo todo1 = new Todo(1L, "Buy groceries", false);
        Todo todo2 = new Todo(2L, "Cook dinner", true);
        when(todoRepository.findAll()).thenReturn(List.of(todo1, todo2));

        // Act
        List<Todo> todos = todoServiceImpl.getAllTodos();

        // Assert
        assertEquals(2, todos.size());
        verify(todoRepository, times(1)).findAll();
    }

    // ---------- Test 3 ----------
    @Test
    void getTodoById_shouldReturnTodoIfExists() {
        // Arrange
        Todo todo = new Todo(1L, "Buy groceries", false);
        when(todoRepository.findById(1L)).thenReturn(Optional.of(todo));

        // Act
        Todo found = todoServiceImpl.getTodoById(1L);

        // Assert
        assertNotNull(found);
        assertEquals(1L, found.getId());
        verify(todoRepository, times(1)).findById(1L);
    }

    // ---------- Test 4 ----------
    @Test
    void updateTodo_shouldUpdateAndReturnUpdatedTodo() {
        // Arrange
        Todo existing = new Todo(1L, "Buy groceries", false);
        Todo updated = new Todo(1L, "Buy groceries and cook dinner", true);

        when(todoRepository.save(existing)).thenReturn(updated);

        // Act
        Todo result = todoServiceImpl.updateTodo(1L, existing);

        // Assert
        assertNotNull(result);
        assertEquals("Buy groceries and cook dinner", result.getTitle());
        assertTrue(result.isCompleted());
        verify(todoRepository, times(1)).save(existing);
    }

    // ---------- Test 5 ----------
    @Test
    void deleteTodo_shouldCallRepositoryDeleteById() {
        // Arrange
        doNothing().when(todoRepository).deleteById(1L);

        // Act
        todoServiceImpl.deleteTodo(1L);

        // Assert
        verify(todoRepository, times(1)).deleteById(1L);
    }
}

Key Points:

@ExtendWith(MockitoExtension.class) integrates Mockito with JUnit 5.
@Mock creates a mock version of TodoRepository.
@InjectMocks injects the mock into the service class.
when(...).thenReturn(...) defines mock behavior.
verify(...) ensures the repository methods were called as expected.

7. Test Configuration

We’re using an in-memory H2 database, though we don’t really hit it during unit testing since we mock the repository.

src/main/resources/application.properties

spring.application.name=unit-testing
spring.datasource.url=jdbc:h2:mem:testdb
spring.datasource.driver-class-name=org.h2.Driver
spring.datasource.username=sa
spring.datasource.password=sa
spring.jpa.hibernate.ddl-auto=create-drop
spring.jpa.show-sql=true

This setup helps when you run integration tests later.

8. Running the Tests

If you’re using IntelliJ or VS Code, you can simply right-click the test class and choose Run Tests.

Or run it from the terminal:

./mvnw test

You’ll see all test cases executed successfully:

BUILD SUCCESS

9. Summary

In this guide, we've seen how to:

Structure a Spring Boot project for testing
Use Mockito to mock dependencies
Write unit tests for CRUD operations in the service layer
Verify repository interactions

The Basics of Software Testing

M. Oly Mahmud — Wed, 29 Oct 2025 00:00:00 +0000

Today, we'll explore one of the most annoying things for a Software Engineer. It's Software Testing!
No, I'll not make it complex. My goal is to simplify software testing.

Software testing means checking the software we have developed. It helps us catch mistakes before the users face those mistakes. Testing makes software more stable and safer to use.

Think about a food delivery app. If a food delivery app crashes when you place an order, or a banking app sends money to the wrong account, people will lose trust in it. Testing helps prevent those problems in the production environment

But Why Should I Do This Annoying Testing

Nobody writes perfect code the first time. You don't even know how many bugs you've developed. Testing finds bugs and errors early, before they turn into a bigger issue. It also saves time and effort later.

1. Unit Testing

Unit testing is the process of testing small parts of your code. Suppose you have a single function, method, or class. In unit testing, you will test those functions, classes are properly working or not

For example, you have developed an e-commerce app. Now, you might test a function called calculateDiscount(price, percent). If the price is 100 and the discount is 10%, the result should be 90.

If that test passes, your calculation works fine. Unit tests are quick to run and help catch bugs early before they spread.

Common tools we use in unit testing are JUnit (Java), Testify (Go), PyTest (Python), Jest (JavaScript)

2. Integration Testing

Integration testing is the tests that checks how different parts of your app work when they are connected. Even if each part works fine by itself, they can fail when connected. Don't get confused. It's very simple.

If we take an example of a food delivery app. In a food delivery app, the order system talks to the payment system. Integration testing makes sure that when a user orders food, payment is processed and a confirmation is sent. So, our integration test checks that the order system and payment system work together.

This kind of test finds problems with data exchange between parts of your app or the database connections.

Common tools:
JUnit (Java), Go’s httptest package, Postman, Spring Boot Test

3. End-to-End (E2E) Testing

In End-to-End testing, we mimic the behavior of the software. In E2E, the tests are written like a user were using the software.

Again, we'll see the example of an e-commerce. What type of feature do you expect to see in an e-commerce app? You’ll test signing in, adding an item to the cart, paying, and receiving confirmation. If all steps work perfectly, then the E2E test is passed.

E2E testing makes sure the full system is perfect.

Common tools:
Cypress, Selenium, Playwright, Puppeteer

Difference Between Unit, Integration, and End-to-End Testing

Type	What It Tests	Example	Scope
Unit Test	One small part of code	Checking if `calculateDiscount()` returns the right value	Small
Integration Test	How parts work together	Order system and payment system working together	Medium
End-to-End Test	The full user flow	From login to checkout in an e-commerce app	Large

You can think of it like building a car:

Unit testing checks if each part (like the engine or brakes) works properly on its own.
Integration testing checks if the engine connects correctly with the transmission.
End-to-end testing takes the car for a drive to see if everything works together smoothly.

Other Useful Types of Testing

Performance Testing: Checks how fast your app runs under load. For example, how your website performs when 10,000 users visit at once.
Security Testing: Looks for vulnerabilities that attackers might exploit. For example, checking if users can access data they shouldn’t.
Usability Testing: Ensures your app is easy to use. Real users try it and share feedback.
Regression Testing: Makes sure new changes don’t break existing features.
Smoke Testing: A quick check to see if basic features work after deployment.

Conclusion

A well-tested software is very important. If a software fails in production, it makes a negative impact on a company. So, software testing is a must.

Building A Real-Time Communication System Using Go and WebSocket

M. Oly Mahmud — Fri, 10 Oct 2025 16:30:20 +0000

Real-time applications like chat systems, dashboards, or multiplayer games rely on persistent, low-latency communication between client and server. Traditional HTTP is request-response only, but it can’t push data to the client unless the client keeps polling. That’s where WebSockets come in.

In this article, we’ll explore how WebSockets work, how connections are established and managed in Go using the Gorilla WebSocket library, and how to safely handle multiple concurrent clients with Go’s concurrency primitives.

We’ll build on a simple Go project using only the standard net/http router and Gorilla WebSocket.

What is a WebSocket?

A WebSocket is a full-duplex communication channel over a single TCP connection. Once established, both client and server can send messages to each other anytime without re-establishing the connection.

Unlike HTTP:

WebSockets stay open until one side closes it.
Communication happens through lightweight frames, not HTTP requests.
Data can flow in both directions independently.

How a WebSocket Connection is Formed

The WebSocket handshake starts as a standard HTTP GET request with an Upgrade header:

GET /ws HTTP/1.1
Host: localhost:8080
Upgrade: websocket
Connection: Upgrade

If the server accepts it, it responds with a 101 Switching Protocols status, upgrading the connection to WebSocket. From that point, the connection is no longer HTTP, it’s a persistent socket.

In Go, this upgrade is handled by Gorilla’s Upgrader:

var upgrader = websocket.Upgrader{
    ReadBufferSize:  1024,
    WriteBufferSize: 1024,
    CheckOrigin:     func(r *http.Request) bool { return true },
}

The CheckOrigin function lets us control which clients can connect. Setting it to always return true allows all origins, good for development, not for production.

Connection Establishment and Storage

When a client connects to /ws, the handler upgrades the request:

conn, err := upgrader.Upgrade(w, r, nil)
if err != nil {
    log.Println("Upgrade error:", err)
    return
}

Once upgraded, conn is a *websocket.Conn, which represents an open connection to a client.
We store each connection in memory along with the client’s username (sent in the request header):

mu.Lock()
Connections = append(Connections, map[string]*websocket.Conn{username: conn})
mu.Unlock()

We use a global slice of maps to keep track of all connected users.
A sync.Mutex ensures that concurrent reads and writes to the Connections slice are thread-safe, since multiple clients can connect or disconnect at the same time.

Reading and Writing Messages

After establishing the connection, the server starts listening for messages:

for {
    messageType, msg, err := conn.ReadMessage()
    if err != nil {
        log.Printf("[%s] read error: %v", username, err)
        break
    }

    log.Printf("[%s] says: %s", username, msg)

    resp := fmt.Sprintf("Response to %s: %s", username, msg)
    conn.WriteMessage(messageType, []byte(resp))
}

ReadMessage() blocks until a new message arrives. When it does, it returns the message type, the payload, and any error.

The messageType is important because WebSockets can carry different kinds of messages.

WebSocket Message Types

TextMessage (1): UTF-8 encoded text.
BinaryMessage (2): Arbitrary binary data.
PingMessage (9): Sent by one peer to check if the connection is alive.
PongMessage (10): Sent automatically in response to a ping.
CloseMessage (8): Sent when either side wants to terminate the connection.

Most applications only use text and binary frames, but ping/pong frames are crucial for keeping the connection healthy.

Detecting and Closing Idle Connections

In a real-world system, we don’t want idle connections hanging around forever.
We can use SetReadDeadline() to close connections that haven’t received messages for a specific time:

const idleTimeout = 60 * time.Second
conn.SetReadDeadline(time.Now().Add(idleTimeout))
conn.SetPongHandler(func(string) error {
    conn.SetReadDeadline(time.Now().Add(idleTimeout))
    return nil
})

This means:

The server expects a message or pong frame every 60 seconds.
Each time one arrives, the deadline resets.
If the timer expires without activity, ReadMessage() returns a timeout error, and we close the connection.

This is how we automatically disconnect idle clients while keeping active ones alive.

Cleaning Up Disconnected Clients

When a connection closes, we must remove it from our global store to prevent memory leaks:

func removeConnection(username string) {
    mu.Lock()
    defer mu.Unlock()

    var updated []map[string]*websocket.Conn
    for _, m := range Connections {
        if _, ok := m[username]; !ok {
            updated = append(updated, m)
        }
    }
    Connections = updated
}

This ensures that only active connections remain in memory.

Sending Messages to Specific Clients

Sometimes, you need to send data to a particular user. We can look up the connection by username and send directly:

func SendMessageToSpecificUser(w http.ResponseWriter, r *http.Request) {
    body, _ := io.ReadAll(r.Body)
    targetUser := string(body)

    mu.Lock()
    defer mu.Unlock()

    for _, item := range Connections {
        for username, conn := range item {
            if username == targetUser {
                conn.WriteMessage(websocket.TextMessage, []byte("hi "+username))
                log.Printf("Sent message to %s", username)
                w.Write([]byte("sent"))
                return
            }
        }
    }
    w.Write([]byte("user not found"))
}

This can easily be extended to support broadcasting messages to all clients or to a subset (like chat rooms).

Concurrency and Multithreading in WebSocket Handling

Each HTTP request in Go runs in its own goroutine.
That means every WebSocket connection gets a dedicated goroutine when the handler runs:

mux.HandleFunc("/ws", handlers.WebsocketHandler)

Inside that goroutine:

The for loop reading messages is blocking, but isolated to that connection.
sync.Mutex ensures shared data structures (like Connections) remain safe when multiple goroutines modify them simultaneously.
The Go scheduler handles concurrency efficiently, thousands of WebSocket connections can run in parallel on a single server.

This concurrency model is what makes Go such a great fit for real-time applications.

Putting It All Together

Let’s walk through building and testing the complete WebSocket setup from scratch.

Project Setup

Create your project:

mkdir websocket-chat-appp
cd websocket-chat-appp
go mod init websocket-chat-appp

Install Gorilla WebSocket:

go get github.com/gorilla/websocket

Project structure:

websocket-chat-app/
│── go.mod
├── main.go
└── handlers/
    └── websocket_handlers.go

main.go

package main

import (
    "log"
    "net/http"
    "websocket-chat-app/handlers"
)

func main() {
    mux := http.NewServeMux()
    mux.HandleFunc("/ws", handlers.WebsocketHandler)
    mux.HandleFunc("/show", handlers.PrintConnections)
    mux.HandleFunc("POST /send", handlers.SendMessageToSpecificUser)

    log.Printf("Server started on :8080")
    http.ListenAndServe(":8080", mux)
}

handlers/websocket_handlers.go

package handlers

import (
    "fmt"
    "io"
    "log"
    "net/http"
    "sync"
    "time"

    "github.com/gorilla/websocket"
)

// Global variables to store all active connections
var (
    Connections []map[string]*websocket.Conn
    mu          sync.Mutex
)

var upgrader = websocket.Upgrader{
    ReadBufferSize:  1024,
    WriteBufferSize: 1024,
    CheckOrigin:     func(r *http.Request) bool { return true },
}

// WebsocketHandler handles new WebSocket connections
func WebsocketHandler(w http.ResponseWriter, r *http.Request) {
    username := r.URL.Query().Get("username")
    if username == "" {
        http.Error(w, "username query param required", http.StatusBadRequest)
        return
    }

    conn, err := upgrader.Upgrade(w, r, nil)
    if err != nil {
        log.Println("Upgrade error:", err)
        return
    }

    mu.Lock()
    Connections = append(Connections, map[string]*websocket.Conn{username: conn})
    mu.Unlock()

    log.Printf("[%s] connected", username)

    go handleConnection(username, conn)
}

// handleConnection reads messages and handles connection lifecycle
func handleConnection(username string, conn *websocket.Conn) {
    defer func() {
        removeConnection(username)
        conn.Close()
        log.Printf("[%s] disconnected", username)
    }()

    const idleTimeout = 60 * time.Second
    conn.SetReadDeadline(time.Now().Add(idleTimeout))
    conn.SetPongHandler(func(string) error {
        conn.SetReadDeadline(time.Now().Add(idleTimeout))
        return nil
    })

    for {
        msgType, msg, err := conn.ReadMessage()
        if err != nil {
            log.Printf("[%s] read error: %v", username, err)
            break
        }

        log.Printf("[%s] says: %s", username, msg)
        resp := fmt.Sprintf("Response to %s: %s", username, msg)
        conn.WriteMessage(msgType, []byte(resp))
    }
}

// removeConnection cleans up disconnected clients
func removeConnection(username string) {
    mu.Lock()
    defer mu.Unlock()

    var updated []map[string]*websocket.Conn
    for _, m := range Connections {
        if _, ok := m[username]; !ok {
            updated = append(updated, m)
        }
    }
    Connections = updated
}

// PrintConnections displays all connected usernames
func PrintConnections(w http.ResponseWriter, _ *http.Request) {
    mu.Lock()
    defer mu.Unlock()

    fmt.Fprintln(w, "Connected users:")
    for _, conn := range Connections {
        for username := range conn {
            fmt.Fprintln(w, "-", username)
        }
    }
}

// SendMessageToSpecificUser sends a message to a specific user
func SendMessageToSpecificUser(w http.ResponseWriter, r *http.Request) {
    body, _ := io.ReadAll(r.Body)
    targetUser := string(body)

    mu.Lock()
    defer mu.Unlock()

    for _, item := range Connections {
        for username, conn := range item {
            if username == targetUser {
                conn.WriteMessage(websocket.TextMessage, []byte("hi "+username))
                log.Printf("Sent message to %s", username)
                w.Write([]byte("sent"))
                return
            }
        }
    }
    w.Write([]byte("user not found"))
}

Running the Server

Start the Go server:

go run main.go

Output:

2025/10/09 22:10:41 Server started on:8080

Testing with Postman

Now, let's see how our app works.
Open Postman, then make a WebSocket connection to localhost:8080/ws. Here I am using passing mugdho as the username, in the header.

Let's make another WebSocket request. Here I am using "mila" as the username in the header.

Let's see the connected users using HTTP REST API.

Now I am sending messages from the connection "Mugdho"

But I'm not sending any messages from "Mila". So the connection is closed.

Now, establish both connections again and send a message to a specific user. I am sending a message to "Mila".

Let's see if Mila received the message or not.

As you can see, Mila received the message successfully.

Summary

Here’s what we covered:

How WebSockets work and how they differ from HTTP
How to establish and upgrade a connection using Gorilla WebSocket
Message types and how to read/write frames
How to detect idle clients using SetReadDeadline and close them cleanly
Storing and managing connections safely with sync.Mutex
Concurrency in Go each WebSocket runs in its own goroutine

AWS Global Infrastructure | Amazon Web Services

M. Oly Mahmud — Fri, 10 Oct 2025 04:57:00 +0000

In our last session, we saw how cloud computing allows app usage without handling real hardware. Today begins understanding AWS fundamentals.

AWS Global Infrastructure

AWS runs on strong worldwide systems. That’s why apps work without issues. Wherever customers are located, speed stays high. From day one, delays stay low while uptime remains solid.

Regions and Availability Zones

Regions are geographic areas such as US East (N. Virginia) or Asia Pacific (Mumbai).
Each Region includes several Availability Zones (AZs), which are isolated data centers. Each data center has independent power, networking, and cooling.

We could lower the risk by spreading things across different regions and zones.

Edge Locations, Local Zones, and Wavelength

AWS offers local spots to speed up apps for people - using nearby sites helps performance while cutting delays across regions.

Edge Locations: Cache content near users.
Local Zones: Bring some AWS services closer to big cities.
Wavelength Zones: Connect to 5G networks for very low-latency apps.

AWS Outposts

If you want AWS tools locally, Outposts brings the network into your facility - offering combined cloud access. Rather than keeping systems separate, it links internal operations with external resources seamlessly - using consistent management layers across both environments.

Shared Responsibility Model

Security on the cloud doesn't happen by itself. With the Shared Responsibility Model, AWS shows what parts each party must manage.

AWS handles "Security of the Cloud": Protects the physical data centers, servers, networking, and foundational services.
You handle "Security in the Cloud": Responsible for applications, data, identity, access controls, encryption, and network configurations.

It's a joint effort: AWS supplies the safe foundation, while you develop atop it with care.

AWS Well-Architected Framework

AWS offers a method known as the Well-Architected Framework. This approach supports creating stable, efficient systems. The model rests on six core areas. As stated in their public documentation, these elements include:

Operational Excellence – Monitor and improve systems continuously.
Security – Protect data, accounts, and workloads.
Reliability – Recover quickly from failures.
Performance Efficiency – Use resources smartly and scale efficiently.
Cost Optimization – Avoid waste and maximize value.
Sustainability – Reduce environmental impact.

Sticking to these principles enables the creation of safe, high-performing software that works consistently - using them streamlines your process while improving outcomes through better structure instead of guesswork.

Conclusion

Here, we looked at AWS global infrastructure, its shared responsibility approach - also exploring the well-architected guidelines from AWS.

Introduction to Cloud Computing and AWS

M. Oly Mahmud — Sat, 04 Oct 2025 06:17:58 +0000

If you've ever thought about why Netflix plays smoothly, while new apps pop up fast from small teams, or how companies grow to serve tons of people without running giant server rooms, the reason is cloud computing.

What is Cloud Computing?

Keep things basic - cloud computing means leasing tech stuff rather than owning it. Rather than managing hardware in-house, you access processing space, file room, and info systems online whenever needed.

Take electricity, for example. Instead of running a personal generator, you connect to the network - then pay based on usage. Cloud computing follows this idea. Want a virtual machine? Space to keep documents? A database that operates smoothly in the background? It’s all available through the cloud.

Key Benefits of Cloud Computing

Scale up or down fast when your visitor count shifts - no hassle. Use more power if needed, less when it’s quiet. Adjust anytime without breaking a sweat.
Save money by paying just for what you actually need - no huge costs at the start.
Worldwide access: servers everywhere, which means faster service for people nearby.
Running systems: folks take care of real-world parts - power, chillers, broken gear.

Service Models in the Cloud

Cloud computing shows up in three big types:

IaaS (Infrastructure as a Service): IaaS means you lease computing resources - say, virtual servers or disk space - through cloud platforms such as AWS EC2; think of it like renting tech gear online instead of buying it outright.
PaaS (Platform as a Service): It’s a setup you can use right away to create and launch apps - take Google App Engine, for example.
SaaS (Software as a Service): SaaS means software online - you sign in, start using it. Think Gmail or Dropbox - no install needed, just open your browser.

Deployment Models: Public, Private, and Hybrid Clouds

Public Cloud: This’s the go-to version of cloud tech. Services run on servers owned by big companies - these get split between lots of different people. Access? Open to anyone online, no restrictions. Think AWS, or Azure, maybe Google Cloud - they’re all in this group.
Private Cloud: A private cloud? Just older tech. One business uses it alone - keeps it at their office or pays someone to run it. Used to rule before big online servers showed up. Gives tighter grip on safety and setup. Like a firm managing its gear inside, using tools like VMware or OpenStack.
Hybrid Cloud: A mix of public plus private cloud setups makes a hybrid system. This setup lets data shift from one side to the other smoothly. It gives more room to adapt based on needs. Like when sensitive info stays in-house, yet high-traffic apps use external servers.

Amazon Web Services (AWS)

Amazon Web Services - also known as AWS - ranks as the top cloud platform globally. It kicked off in 2006 after Amazon chose to lease its huge tech setup. Right now, businesses big and small run on it, including major names such as Netflix alongside Airbnb.

Core AWS Services

Here’s what AWS actually does for you:

💻 Compute (Running Apps): Run websites or apps? Try EC2 - it’s like renting a virtual machine. Or go serverless with Lambda - just drop your code, it runs on its own. Both handle heavy lifting so you don’t have to.
🗂️ Storage (Saving Stuff): Hold onto your files, pics, and info using tools such as S3 - solid for saving stuff - or EBS, which works like a virtual hard disk. While S3 handles buckets of data, EBS gives you block-level space that sticks around.
📊 Databases: Pick RDS when you’re working with structured data - say, MySQL. Or go for DynamoDB if speed matters more and you like room to adapt.
Networking: set up safe connections using VPC, boost loading times through CloudFront.
🌐 Networking: Set up safe connections using VPC, boost loading times through CloudFront
🔐 Security & Access: Keep things safe by picking who gets in using IAM, while encryption guards your info.

Conclusion

We’ve picked up what cloud computing’s about, along with AWS. It helps us grow without spending too much while connecting to people everywhere. Lots of groups use this tech because it gives them serious power.

Day-8: Install Ansible | 100 Days of DevOps

M. Oly Mahmud — Fri, 03 Oct 2025 14:42:03 +0000

In this guide, we’ll walk through the different ways to install Ansible and get it running on your system. By the end, you’ll be able to execute Ansible commands globally from your terminal.

What is Ansible?

Ansible is an open-source automation engine that helps manage systems, deploy applications, and orchestrate workflows. Unlike many other configuration management tools, Ansible doesn’t require installing agents on managed nodes. It only needs SSH access and Python on the target machine, which keeps things lightweight and secure.

Installation Options

There are several ways to install Ansible:

Package Manager – Install via apt (Debian/Ubuntu), dnf or yum (RHEL/CentOS/Fedora).
Pip (Python package manager) – Install via pip3, which gives you more control over the version.
From Source – Clone the official Ansible GitHub repository.

In this article, we’ll focus on the pip3 installation method since it allows us to install a specific version and ensures portability across environments.

Step 1: Install Python and Pip

Ansible requires Python 3. Most modern Linux distributions come with Python pre-installed. If not, install Python and pip3:

sudo apt update -y
sudo apt install -y python3 python3-pip

You can verify the installation with:

python3 --version
pip3 --version

Step 2: Install Ansible via pip3

To install the latest version of Ansible globally, run:

sudo pip3 install ansible

If you want to install a specific version (for example, Ansible 4.9.0), use:

sudo pip3 install ansible==4.9.0 --prefix=/usr/local

The --prefix=/usr/local flag ensures that the binary goes into /usr/local/bin, which is accessible by all users on the system.

Step 3: Verify Installation

After installation, check whether Ansible is installed correctly:

ansible --version

You should see output similar to:

ansible [core 2.11.x]
  config file = None
  ansible python module location = /usr/local/lib/python3.9/dist-packages/ansible
  executable location = /usr/local/bin/ansible
  python version = 3.x.x

Step 4: Add Ansible to PATH (if needed)

If the ansible command isn’t found, add /usr/local/bin to your PATH. Create a file under /etc/profile.d/:

echo 'export PATH=$PATH:/usr/local/bin' | sudo tee /etc/profile.d/ansible.sh
sudo chmod +x /etc/profile.d/ansible.sh

Reload the environment:

source /etc/profile

Now Ansible will be available to all users.

Step 5: Test Ansible with a Ping Command

To make sure Ansible can talk to your servers, create an inventory file:

[servers]
192.168.1.10
192.168.1.11

Then run:

ansible -i inventory servers -m ping

If everything is set up correctly, you’ll see a “pong” response from each server.

Conclusion

So, we've successfully installed Ansible.

Day-7: Linux SSH Authentication | 100 Days of DevOps

M. Oly Mahmud — Sat, 27 Sep 2025 18:00:00 +0000

When we work with remote servers, the most common way to connect is through SSH (Secure Shell). If you’ve ever managed Linux servers or deployed applications, chances are you’ve used it.
In this article, we’ll walk through what SSH is, how to use it for login, and finally how to set up password-less login across multiple servers.

What is SSH?

SSH (Secure Shell) is a protocol that let us securely connect to another machine over an insecure network. It’s widely used by developers, system admins, and DevOps engineers to:

Log in to remote servers
Run commands
Transfer files
Manage systems securely

Unlike older methods like Telnet, SSH encrypts all communication. This means our credentials and data are safe from eavesdropping.

How to Log In Using SSH

The basic syntax of an SSH login is:

ssh username@hostname

username → the user account on the remote server
hostname → the server’s IP address or domain name

Example

If we have a server at 172.16.238.10 with a user tony:

ssh tony@172.16.238.10

You’ll be prompted to enter the password for that user. Once authenticated, you’ll get a shell on the remote machine.

The Problem with Passwords

Typing a password every single time quickly becomes annoying, especially when we need to log into multiple servers or run automation scripts. Passwords also pose security risks if they are weak or reused.

This is where SSH keys come in.

Password-less SSH Login

SSH keys allow us to authenticate without typing a password. The idea is simple:

Generate a pair of keys on our local machine (private + public).
Copy the public key to the remote server.
When we connect, the server verifies our private key against the stored public key.

If they match, we can login without any password.

Step 1: Generate SSH Keys

On the client machine (in our case, the jump host with user thor):

ssh-keygen -t rsa -b 4096

Press Enter to accept the defaults.
Leave the passphrase empty (important for automation).

This creates two files:

~/.ssh/id_rsa → your private key (keep it safe!)
~/.ssh/id_rsa.pub → your public key (share this with servers)

Step 2: Copy the Public Key to the Server

To enable password-less login, copy the public key to the server:

ssh-copy-id -i ~/.ssh/id_rsa.pub username@hostname

Example

For a server at 172.16.238.10 with user tony:

ssh-copy-id -i ~/.ssh/id_rsa.pub tony@172.16.238.10

You’ll be asked for the password one last time. After that, you’ll be able to log in without it.

Step 3: Log In Without a Password

Now test it:

ssh tony@172.16.238.10

This time we can connect directly, without any password prompt.

Real-World Example: Multiple App Servers

Here’s a real setup where we had to configure password-less login for a jump host user (thor) to multiple application servers.

Server Name	IP	Hostname	User	Password	Purpose
stapp01	172.16.238.10	stapp01.stratos.xfusioncorp.com	tony	Ir0nM@n	Nautilus App 1
stapp02	172.16.238.11	stapp02.stratos.xfusioncorp.com	steve	Am3ric@	Nautilus App 2
stapp03	172.16.238.12	stapp03.stratos.xfusioncorp.com	banner	BigGr33n	Nautilus App 3

We ran:

ssh-copy-id -i ~/.ssh/id_rsa.pub tony@172.16.238.10
ssh-copy-id -i ~/.ssh/id_rsa.pub steve@172.16.238.11
ssh-copy-id -i ~/.ssh/id_rsa.pub banner@172.16.238.12

Now, the thor user can log in to all app servers without typing passwords.

Password-less `sudo`

Sometimes, our scripts need sudo privileges. By default, sudo asks for a password. We can configure users for password-less sudo.

On each app server, edit the sudoers file:

sudo visudo

Add:

username ALL=(ALL) NOPASSWD:ALL

Replace username with tony, steve, or banner.

Conclusion

Automate scripts
Manage multiple servers with ease
Strengthen security with keys over passwords

Day-6: Cron Job | 100 Days of DevOps

M. Oly Mahmud — Sat, 27 Sep 2025 14:27:39 +0000

If you’ve ever wanted your Linux server to run tasks automatically, like cleaning logs, backing up databases, or sending reports, then cron jobs are your best friend. Cron is a time-based job scheduler built into Unix-like operating systems, and it’s one of the most powerful automation tools for system admins and developers.

In this article, we’ll walk through what cron jobs are, how the syntax works, real-world examples, and how we can set them up in our system.

What is a Cron Job?

A cron job is a command or script that is scheduled to run at a specific time or interval. The cron service (crond) runs in the background and checks a special configuration file. This configuration file is called a crontab (short for "cron table") to know what to execute.
Each user on a system can have their own crontab file, and there’s also a system-wide crontab located at /etc/crontab.

Cron Syntax Explained

Cron syntax might be confusing. But it’s actually quite simple. Every cron job is defined with five time fields followed by the command to run. Here’s a breakdown:

*    *    *    *    *   command_to_execute
-    -    -    -    -
|    |    |    |    |
|    |    |    |    +---- Day of week (0 - 6) (Sunday=0 or 7)
|    |    |    +--------- Month (1 - 12)
|    |    +-------------- Day of month (1 - 31)
|    +------------------- Hour (0 - 23)
+------------------------ Minute (0 - 59)

Special Characters

* → every value
, → list of values (e.g. 1,15)
- → range (e.g. 1-5)
/ → step (e.g. */5 means every 5 units)

Cron Job Examples

Let’s go through some practical examples:

*/5 * * * * echo "Hello" >> /tmp/hello.log
Run every 5 minutes.
0 0 * * * /usr/bin/backup.sh
Run a backup script every day at midnight.
30 14 * * 1
Run at 2:30 PM every Monday.
0 */6 * * * /usr/bin/update.sh
Run every 6 hours.
15 9-17 * * 1-5 /usr/bin/send_report.sh
Run at 9:15, 10:15, …, 5:15 during working hours, Monday through Friday.

Setting Up a Cron Job

Install cron (if not already installed) On CentOS/RHEL:

   sudo yum install -y cronie
   sudo systemctl enable crond
   sudo systemctl start crond

On Ubuntu/Debian:

   sudo apt-get update
   sudo apt-get install -y cron
   sudo systemctl enable cron
   sudo systemctl start cron

Edit the crontab To add a job for the user:

   crontab -e

Verify cron jobs

   crontab -l

Check if it’s working For example, add:

   */2 * * * * echo "Cron is working!" >> /tmp/test_cron.log

Then wait a few minutes and run:

   cat /tmp/test_cron.log

Common Use Cases

Automating backups
Rotating or cleaning log files
Sending periodic emails or reports
Updating packages or databases
Monitoring disk usage

Final Thoughts

Cron jobs are simple yet powerful. With a few lines in crontab, we can automate tasks to run on time, every time. Whether managing servers or automating workflows, knowing cron is essential.