DEV Community: ibrahim

Deploying a 3-Tier Architecture on AWS Using Terraform Modules

ibrahim — Thu, 19 Jun 2025 14:59:47 +0000

When it comes to Infrastructure as Code (IaC), one of the first tools that comes to mind is Terraform. Developed by HashiCorp, Terraform is widely adopted because of its simplicity, ease of installation, and support for multiple cloud providers.

In this blog post, I'll walk you through how to use Terraform modules to deploy a 3-tier architecture on AWS. By the end, you’ll understand how modular Terraform projects are structured and how to build reusable infrastructure components.

What is a Terraform Module?

A Terraform module is a collection of .tf files grouped together to perform a specific task or provision a particular resource. You can think of a module as a reusable template for deploying cloud infrastructure.

Terraform code is written in HCL (HashiCorp Configuration Language), which is human-readable and much easier to understand than languages like C or Java.

The primary purpose of using modules is to avoid code repetition and to promote reusability and maintainability in your infrastructure.

There are:

Official AWS modules in the Terraform Registry
Community-contributed modules
And of course, custom modules you can write yourself

The 3-Tier Architecture We’re Deploying

In this project, we’ll deploy the following infrastructure on AWS:

A VPC with public and private subnets
An Internet Gateway for the public subnet
A NAT Gateway for the private subnet
EC2 Instances in each tier (Frontend, Backend, and Database)
Security Groups and Network ACLs to control traffic rules

Here’s a simple breakdown of the three tiers:

Tier	Purpose
Presentation Layer	Frontend (e.g., React app)
Business Logic Layer	Backend (e.g., Node.js or Django)
Database Layer	RDS or MySQL/PostgreSQL

📁 Project Folder Structure

Assuming Terraform is already installed on your machine (if not, check out Terraform installation guide), here’s how you should organize your project:

project-root/
│
├── main.tf
├── variables.tf
├── outputs.tf
├── provider.tf
│
└── modules/
    ├── vpc/
    ├── compute/
    └── network/

📝 Note: To keep the blog concise, I won’t paste all the code here. You can find the full source code in my GitHub repository.

🧠 What Each Terraform File Does

File	Purpose
main.tf	Entry point – defines the resources and calls the modules
variables.tf	Contains input variables (like AMI IDs, instance types, subnet IDs)
outputs.tf	Displays outputs after successful deployment (e.g., public IPs, VPC IDs)
provider.tf	Declares the cloud provider (e.g., AWS region, access keys)

The module directories (like vpc, compute, and network) each contain .tf files that define the logic to deploy VPCs, EC2s, and other networking components.

📦 Understanding `terraform.tfstate` and `terraform.tfstate.backup`

Terraform keeps track of the infrastructure it manages using a file called terraform.tfstate. This file is critical because it:

Stores the current state of your deployed infrastructure
Allows Terraform to know what exists, what to create, update, or destroy

Now here’s where terraform.tfstate.backup comes in:

terraform.tfstate.backup is an automatic backup of your last good known state.

Whenever you run a command like terraform apply, Terraform creates a new terraform.tfstate and moves the previous version to terraform.tfstate.backup. This ensures that:

If something goes wrong, you can manually restore the backup
You don’t lose the entire state file due to corruption or interruption

💡 Best Practice: Never share your state file publicly. It often contains sensitive information like resource IDs, passwords, and more. Use remote backends (like S3 with encryption) for production environments.

Final Thoughts

Using Terraform modules makes your infrastructure more modular, scalable, and easy to maintain. Whether you're managing a simple EC2 instance or a full-blown 3-tier app on AWS, breaking your setup into logical modules helps avoid repetition and enhances reusability.

Let me know what you’d like to see next — maybe monitoring this infrastructure with Prometheus and Grafana? Or setting up CI/CD pipelines with GitHub Actions?

🔗 Full Source Code

GitHub Repository – 3-Tier Architecture with Terraform

If you found this post helpful, feel free to like, share, or leave a comment. You can connect with me on LinkedIn for more DevOps and cloud tips!

Deploying a 3-Tier Architecture on AWS Using Terraform Modules

ibrahim — Thu, 19 Jun 2025 14:54:20 +0000

What is a Terraform Module?

Terraform code is written in HCL (HashiCorp Configuration Language), which is human-readable and much easier to understand than languages like C or Java.

The primary purpose of using modules is to avoid code repetition and to promote reusability and maintainability in your infrastructure.

There are:

Official AWS modules in the Terraform Registry
Community-contributed modules
And of course, custom modules you can write yourself

The 3-Tier Architecture We’re Deploying

In this project, we’ll deploy the following infrastructure on AWS:

A VPC with public and private subnets
An Internet Gateway for the public subnet
A NAT Gateway for the private subnet
EC2 Instances in each tier (Frontend, Backend, and Database)
Security Groups and Network ACLs to control traffic rules

Here’s a simple breakdown of the three tiers:

Tier	Purpose
Presentation Layer	Frontend (e.g., React app)
Business Logic Layer	Backend (e.g., Node.js or Django)
Database Layer	RDS or MySQL/PostgreSQL

📁 Project Folder Structure

Assuming Terraform is already installed on your machine (if not, check out Terraform installation guide), here’s how you should organize your project:

project-root/
│
├── main.tf
├── variables.tf
├── outputs.tf
├── provider.tf
│
└── modules/
    ├── vpc/
    ├── compute/
    └── network/

📝 Note: To keep the blog concise, I won’t paste all the code here. You can find the full source code in my GitHub repository.

🧠 What Each Terraform File Does

File	Purpose
main.tf	Entry point – defines the resources and calls the modules
variables.tf	Contains input variables (like AMI IDs, instance types, subnet IDs)
outputs.tf	Displays outputs after successful deployment (e.g., public IPs, VPC IDs)
provider.tf	Declares the cloud provider (e.g., AWS region, access keys)

The module directories (like vpc, compute, and network) each contain .tf files that define the logic to deploy VPCs, EC2s, and other networking components.

📦 Understanding `terraform.tfstate` and `terraform.tfstate.backup`

Terraform keeps track of the infrastructure it manages using a file called terraform.tfstate. This file is critical because it:

Stores the current state of your deployed infrastructure
Allows Terraform to know what exists, what to create, update, or destroy

Now here’s where terraform.tfstate.backup comes in:

terraform.tfstate.backup is an automatic backup of your last good known state.

Whenever you run a command like terraform apply, Terraform creates a new terraform.tfstate and moves the previous version to terraform.tfstate.backup. This ensures that:

If something goes wrong, you can manually restore the backup
You don’t lose the entire state file due to corruption or interruption

💡 Best Practice: Never share your state file publicly. It often contains sensitive information like resource IDs, passwords, and more. Use remote backends (like S3 with encryption) for production environments.

Final Thoughts

Let me know what you’d like to see next — maybe monitoring this infrastructure with Prometheus and Grafana? Or setting up CI/CD pipelines with GitHub Actions?

🔗 Full Source Code

GitHub Repository – 3-Tier Architecture with Terraform

If you found this post helpful, feel free to like, share, or leave a comment. You can connect with me on LinkedIn for more DevOps and cloud tips!

Key DevOps roles and responsibilities

ibrahim — Sat, 31 Aug 2024 13:47:13 +0000


![ ](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/samdq79lzlhd3q4x8qn3.png)

DevOps vs Traditional Software Development: A Comprehensive Comparison

ibrahim — Sat, 31 Aug 2024 13:10:17 +0000

In software development, two primary approaches stand out: the traditional Waterfall model and the more modern DevOps methodology. Each has its unique characteristics, advantages, and challenges. This blog post explores the fundamental differences between these approaches to help you understand which might best suit your needs.

Traditional Software Development Process

The traditional software development process, often called the Waterfall model, is a linear and sequential approach. It follows a structured path through distinct phases: requirements, design, coding/implementation, testing, and deployment. Each stage must be completed before moving on to the next, with the output of one phase serving as the input for the next.

** Pros:**

Clear Specifications: Provides a well-defined specification at each stage, which helps in understanding requirements and goals clearly.
Comprehensive Documentation: Offers extensive documentation, which can be valuable for future reference and compliance.

Cons:

Rigidity: The rigid structure makes it difficult to accommodate changes once a phase is completed.
Time-Consuming: Progressing through each phase sequentially can be slow, delaying the final delivery.
Error Correction Challenges: Identifying and fixing mistakes early in the process is difficult, often leading to costly fixes later on.

** DevOps Approach**

DevOps is a modern approach that fosters a collaborative culture between development and operations teams. It emphasizes automation, continuous integration, and continuous deployment/delivery to accelerate the software development lifecycle and improve product quality.

** Pros:**

Speed: Enables rapid development and deployment, significantly reducing time-to-market.
Quality: Continuous integration and testing ensure high-quality software.
Flexibility: Easily adapts to changes, allowing for iterative improvements.
Ease of Maintenance: Streamlined processes make debugging and maintenance more efficient.

Cons:

Adoption Challenges: Implementing DevOps requires cultural shifts and can be difficult to adopt initially.
Documentation Complexity: Continuous changes can make maintaining comprehensive documentation challenging.

Conclusion

Choosing between traditional software development and DevOps depends on your specific needs. If you require a structured, well-documented process with clear specifications, the traditional approach might be suitable. However, if speed, flexibility, and collaboration are your priorities, embracing DevOps could be the better choice. Each method has its place, and understanding the differences will help you make an informed decision.

Automating User and Group Management with a Bash Script

ibrahim — Tue, 02 Jul 2024 11:07:21 +0000

Automating User and Group Management with a Bash Script

inspired by HNG .

As a SysOps engineer, one of your routine tasks involves managing users and groups on a server. This can be time-consuming and prone to errors, especially when dealing with many users. Automation is the key to efficiency and reliability. This article will walk you through a Bash script that automates creating users and groups, setting up home directories with appropriate permissions, generating random passwords, and logging all actions.

This project was inspired by HNG internship 11, DevOps trcak of stage one.
visit HNG WEBSITE to learn more about the program

Overview

Creates users and their groups.
Adds users to additional specified groups.
Sets up home directories with correct permissions and ownership.
Generates random passwords for users.
Logs all actions to /var/log/user_management.log. Stores generated passwords securely in /var/secure/user_passwords.txt

A bash script create_users.sh will be created:

The script, create_users.sh, reads a text file containing usernames and their associated groups. Each line in the file is formatted as user;groups, where groups are delimited by commas. The script performs the following tasks:

Example Input File

light;sudo,dev,www-data
idimma;sudo
mayowa;dev,www-data

The script
Below is the complete script

#!/bin/bash

# Define log and password files
LOG_FILE="/var/log/user_management.log"
PASSWORD_FILE="/var/secure/user_passwords.txt"

# Create log and password files if they don't exist
touch $LOG_FILE
mkdir -p /var/secure
touch $PASSWORD_FILE

# Function to log messages
log_message() {
    echo "$(date +'%Y-%m-%d %H:%M:%S') - $1" | tee -a $LOG_FILE
}

# Function to generate random password
generate_password() {
    tr -dc A-Za-z0-9 </dev/urandom | head -c 12 ; echo ''
}

# Check if the input file is provided
if [ $# -ne 1 ]; then
    echo "Usage: $0 <input_file>"
    exit 1
fi

# Read the input file
INPUT_FILE=$1

# Check if the input file exists
if [ ! -f $INPUT_FILE ]; then
    echo "Input file not found!"
    exit 1
fi

while IFS=';' read -r username groups; do
    # Remove leading and trailing whitespaces
    username=$(echo $username | xargs)
    groups=$(echo $groups | xargs)

    if id "$username" &>/dev/null; then
        log_message "User $username already exists. Skipping..."
        continue
    fi

    # Create a personal group for the user
    groupadd $username
    if [ $? -ne 0 ]; then
        log_message "Failed to create group $username."
        continue
    fi
    log_message "Group $username created successfully."

    # Create user and add to personal group
    useradd -m -g $username -s /bin/bash $username
    if [ $? -ne 0 ]; then
        log_message "Failed to create user $username."
        continue
    fi
    log_message "User $username created successfully."

    # Create additional groups if they don't exist and add user to groups
    IFS=',' read -ra group_array <<< "$groups"
    for group in "${group_array[@]}"; do
        group=$(echo $group | xargs)
        if [ -z "$group" ]; then
            continue
        fi
        if ! getent group $group >/dev/null; then
            groupadd $group
            if [ $? -ne 0 ]; then
                log_message "Failed to create group $group."
                continue
            fi
            log_message "Group $group created successfully."
        fi
        usermod -aG $group $username
        log_message "User $username added to group $group."
    done

    # Set up home directory permissions
    chmod 700 /home/$username
    chown $username:$username /home/$username
    log_message "Permissions set for home directory of $username."

    # Generate random password and store it
    password=$(generate_password)
    echo "$username:$password" | chpasswd
    echo "$username:$password" >> $PASSWORD_FILE
    log_message "Password set for user $username."

done < "$INPUT_FILE"

log_message "User and group creation process completed."

exit 0

Detailed Explanation

Let's break down the script line by line to understand how it works.

1. Shebang and Definitions

#!/bin/bash
LOG_FILE="/var/log/user_management.log"
PASSWORD_FILE="/var/secure/user_passwords.txt"

The shebang (#!/bin/bash) indicates that the script should be executed using the Bash shell.
LOG_FILE and PASSWORD_FILE specify the paths for the log and password files.
2. Creating Log and Password Files

touch $LOG_FILE
mkdir -p /var/secure
touch $PASSWORD_FILE

touch $LOG_FILE creates the log file if it doesn't exist.
mkdir -p /var/secure creates the directory /var/secure if it doesn't exist.
touch $PASSWORD_FILE creates the password file if it doesn't exist.

3. Logging Function

log_message() {
    echo "$(date +'%Y-%m-%d %H:%M:%S') - $1" | tee -a $LOG_FILE
}

'log_message' is a function that logs messages with a timestamp to both the log file and the terminal.

4. Password Generation Function

generate_password() {
    tr -dc A-Za-z0-9 </dev/urandom | head -c 12 ; echo ''
}

This function generates a random 12-character alphanumeric password.
5. Input File Check

if [ $# -ne 1 ]; then
    echo "Usage: $0 <input_file>"
    exit 1
fi
INPUT_FILE=$1
if [ ! -f $INPUT_FILE ]; then
    echo "Input file not found!"
    exit 1
fi

The script checks if exactly one argument (the input file) is provided and if the file exists.
6. Reading the Input File

while IFS=';' read -r username groups; do
    username=$(echo $username | xargs)
    groups=$(echo $groups | xargs)

his loop reads the input file line by line, splitting each line into username and groups using ; as the delimiter.
xargs removes leading and trailing whitespaces.

7. Checking for Existing Users

    if id "$username" &>/dev/null; then
        log_message "User $username already exists. Skipping..."
        continue
    fi

This checks if the user already exists and logs a message if they do, then skips to the next iteration
8. Creating Personal Group and User

    groupadd $username
    if [ $? -ne 0 ]; then
        log_message "Failed to create group $username."
        continue
    fi
    log_message "Group $username created successfully."
    useradd -m -g $username -s /bin/bash $username
    if [ $? -ne 0 ]; then
        log_message "Failed to create user $username."
        continue
    fi
    log_message "User $username created successfully."

groupadd $username creates a personal group for the user.
useradd -m -g $username -s /bin/bash $username creates the user with the specified home directory and shell.
9. Adding User to Additional Groups

    IFS=',' read -ra group_array <<< "$groups"
    for group in "${group_array[@]}"; do
        group=$(echo $group | xargs)
        if [ -z "$group" ]; then
            continue
        fi
        if ! getent group $group >/dev/null; then
            groupadd $group
            if [ $? -ne 0 ]; then
                log_message "Failed to create group $group."
                continue
            fi
            log_message "Group $group created successfully."
        fi
        usermod -aG $group $username
        log_message "User $username added to group $group."
    done

This splits the groups string into an array and iterates over each group, creating the group if it doesn't exist and adding the user to it.
10. Setting Up Home Directory Permissions

    chmod 700 /home/$username
    chown $username:$username /home/$username
    log_message "Permissions set for home directory of $username."

chmod 700 /home/$username sets the permissions so that only the user can access their home directory.
chown $username:$username /home/$username sets the ownership of the home directory.
11. Generating and Storing Passwords

    password=$(generate_password)
    echo "$username:$password" | chpasswd
    echo "$username:$password" >> $PASSWORD_FILE
    log_message "Password set for user $username."

This generates a random password for the user, sets it, and securely stores it
12. Completing the Process

done < "$INPUT_FILE"
log_message "User and group creation process completed."
exit

DEV Community: ibrahim

Deploying a 3-Tier Architecture on AWS Using Terraform Modules

What is a Terraform Module?

The 3-Tier Architecture We’re Deploying

📁 Project Folder Structure

🧠 What Each Terraform File Does

📦 Understanding terraform.tfstate and terraform.tfstate.backup

Final Thoughts

🔗 Full Source Code

Deploying a 3-Tier Architecture on AWS Using Terraform Modules

What is a Terraform Module?

The 3-Tier Architecture We’re Deploying

📁 Project Folder Structure

🧠 What Each Terraform File Does

📦 Understanding terraform.tfstate and terraform.tfstate.backup

Final Thoughts

🔗 Full Source Code

Key DevOps roles and responsibilities

DevOps vs Traditional Software Development: A Comprehensive Comparison

Automating User and Group Management with a Bash Script

Automating User and Group Management with a Bash Script

Overview

A bash script create_users.sh will be created:

📦 Understanding `terraform.tfstate` and `terraform.tfstate.backup`

📦 Understanding `terraform.tfstate` and `terraform.tfstate.backup`