Managing Multi environiment infrastructure keeping your code DRY and Organised

dinesh reddy — Wed, 06 Nov 2024 06:01:37 +0000

Terraform for managing #MultiEnvironment infrastructure while keeping your code #DRY and organized.

Scenario:

You’re tasked with deploying infrastructure for three environments: dev, test, and prod. The resources (e.g., EC2 instances, S3 buckets , RDS ) are the same, but configuration values like instance type, AMI, or bucket names differ by environment.

Challenge:

How can you efficiently reuse the same Terraform configuration across multiple environments (dev, test, prod) without duplicating code?

Solution:

A solution is to use Terraform modules combined with environment-specific variable files to maintain DRY and modular infrastructure-as-code. Here’s how:

Define Terraform Modules: The module will contain the core resource definitions (e.g., EC2 instances, S3 buckets and RDS) and use variables for configurable values.

Create Environment-Specific .tfvars Files: Each environment (dev, test, prod) has its own .tfvars file to specify unique values, such as instance type, number of instances, etc.

Call the Module in the Root Configuration: The root configuration references the module and passes in variables from the .tfvars files.

Apply Configuration: Run the following to specify the environment file:

bash

terraform apply -var-file="dev.tfvars"

This approach allows you to reuse the module for all environments while keeping configurations separate and clean.

Example Script:

Here’s a quick example:

Module Definition (modules/ec2/main.tf)

variable "instance_type" {}

variable "ami" {}

resource "aws_instance" "example" {

ami = var.ami

instance_type = var.instance_type

}

Root Configuration (main.tf)

module "ec2" {

source = "./modules/ec2"

instance_type = var.instance_type

ami = var.ami

}

Environment-Specific Variables (e.g., dev.tfvars)

instance_type = "t2.micro"

ami = "ami-123456"

Run terraform apply -var-file="dev.tfvars" to apply the configuration for the dev environment.

DevCommunity #InfraManagement #IAC #SysAdmin #devops #hiring

Performance Issues on Linux instances

dinesh reddy — Wed, 06 Nov 2024 05:18:01 +0000

Today’s tip is on diagnosing #Performance issues on #Linux systems.

Scenario:
Imagine managing an e-commerce application on a Linux server during a major festive sale (like Diwali). As traffic surges, customers start reporting slow load times and occasional timeouts. You need to act fast to diagnose and restore smooth operation.

Challenge:
The huge volume of logs and metrics makes pinpointing issues time-consuming.
Basic tools like top and netstat provide limited, real-time snapshots.
High traffic and fluctuating demand lead to sudden spikes, complicating root cause analysis.
Solution:
To get a deeper understanding of the issue, I used a combination of nload, htop, and atop for system-level performance analysis. Here’s how each tool can be a game-changer:

nload: This tool provides a real-time view of network traffic per network interface, showing incoming and outgoing data rates. It helps identify unusual spikes in network usage that may be affecting performance.

htop: Offering an interactive view of system resource usage (CPU, memory, etc.), htop enables quick identification of any process consuming unusually high resources.

atop: For historical performance analysis, atop records system ****metrics over time. This allows you to correlate network spikes with CPU, memory, or I/O bottlenecks, providing a comprehensive view of system health across different time frames.

By combining these tools, I could quickly identify bottlenecks and take proactive steps to optimize performance under high demand.