Tag: Terraform

How to Create an ALB Listener with Multiple Path Conditions Using Terraform
When designing modern cloud-native applications, it’s common to host multiple services under a single domain. Application Load Balancers (ALBs) in AWS provide an efficient way to route traffic to different backend services based on URL path conditions. This article will guide you through creating an ALB listener with multiple path-based routing conditions using Terraform, assuming you already have SSL configured.

Prerequisites
- AWS Account: Ensure you have access to an AWS account with the necessary permissions to create and manage ALB, EC2 instances, and other AWS resources.
- Terraform Installed: Terraform should be installed and configured on your machine.
- SSL Certificate: You should already have an SSL certificate set up and associated with your ALB, as this guide focuses on creating path-based routing rules.
Step 1: Set Up Path-Based Target Groups

Before configuring the ALB listener rules, you need to create target groups for the different services that will handle requests based on the URL paths.
```
resource "aws_lb_target_group" "service1_target_group" {
  name     = "service1-tg"
  port     = 80
  protocol = "HTTP"
  vpc_id   = aws_vpc.main_vpc.id
}

resource "aws_lb_target_group" "service2_target_group" {
  name     = "service2-tg"
  port     = 80
  protocol = "HTTP"
  vpc_id   = aws_vpc.main_vpc.id
}
```
In this example, we’ve created two target groups: one for service1 and another for service2. These groups will handle the traffic based on specific URL paths.

Step 2: Create the HTTPS Listener

Since we’re focusing on path-based routing, we’ll configure an HTTPS listener that listens on port 443 and uses the SSL certificate you’ve already set up.
```
resource "aws_lb_listener" "https_listener" {
  load_balancer_arn = aws_lb.my_alb.arn
  port              = "443"
  protocol          = "HTTPS"
  ssl_policy        = "ELBSecurityPolicy-2016-08"
  certificate_arn   = aws_acm_certificate.cert.arn

  default_action {
    type = "fixed-response"
    fixed_response {
      content_type = "text/plain"
      message_body = "404: Not Found"
      status_code  = "404"
    }
  }
}
```
Step 3: Define Path-Based Routing Rules

Now that the HTTPS listener is set up, you can define listener rules that route traffic to different target groups based on URL paths.
```
resource "aws_lb_listener_rule" "path_condition_rule_service1" {
  listener_arn = aws_lb_listener.https_listener.arn
  priority     = 1

  action {
    type             = "forward"
    target_group_arn = aws_lb_target_group.service1_target_group.arn
  }

  condition {
    path_pattern {
      values = ["/service1/*"]
    }
  }
}

resource "aws_lb_listener_rule" "path_condition_rule_service2" {
  listener_arn = aws_lb_listener.https_listener.arn
  priority     = 2

  action {
    type             = "forward"
    target_group_arn = aws_lb_target_group.service2_target_group.arn
  }

  condition {
    path_pattern {
      values = ["/service2/*"]
    }
  }
}
```
In this configuration:
- The first rule routes traffic with paths matching /service1/* to service1_target_group.
- The second rule routes traffic with paths matching /service2/* to service2_target_group.
The priority field ensures that Terraform processes these rules in the correct order, with lower numbers being processed first.

Step 4: Apply Your Terraform Configuration

After defining your Terraform configuration, apply the changes to deploy the ALB with path-based routing.
1. Initialize Terraform:
```
   terraform init
```
1. Review the Plan:
```
   terraform plan
```
1. Apply the Configuration:
```
   terraform apply
```
Conclusion

By leveraging path-based routing, you can efficiently manage traffic to different services under a single domain, improving the organization and scalability of your application architecture.

This approach is especially useful in microservices architectures, where different services can be accessed via specific URL paths, all secured under a single SSL certificate. Path-based routing is a powerful tool for ensuring that your ALB efficiently directs traffic to the correct backend services, enhancing both performance and security.
August 30, 2024
Creating an Application Load Balancer (ALB) Listener with Multiple Host Header Conditions Using Terraform
Application Load Balancers (ALBs) play a crucial role in distributing traffic across multiple backend services. They provide the flexibility to route requests based on a variety of conditions, such as path-based or host-based routing. In this article, we’ll walk through how to create an ALB listener with multiple host_header conditions using Terraform.

Prerequisites

Before you begin, ensure that you have the following:
- AWS Account: You’ll need an AWS account with the appropriate permissions to create and manage ALB, EC2, and other related resources.
- Terraform Installed: Make sure you have Terraform installed on your local machine. You can download it from the official website.
- Basic Knowledge of Terraform: Familiarity with Terraform basics, such as providers, resources, and variables, is assumed.
Step 1: Set Up Your Terraform Configuration

Start by creating a new directory for your Terraform configuration files. Inside this directory, create a file named main.tf. This file will contain the Terraform code to create the ALB, listener, and associated conditions.
```
provider "aws" {
  region = "us-west-2" # Replace with your preferred region
}

resource "aws_vpc" "main_vpc" {
  cidr_block = "10.0.0.0/16"
}

resource "aws_subnet" "main_subnet" {
  vpc_id            = aws_vpc.main_vpc.id
  cidr_block        = "10.0.1.0/24"
  availability_zone = "us-west-2a" # Replace with your preferred AZ
}

resource "aws_security_group" "alb_sg" {
  name   = "alb_sg"
  vpc_id = aws_vpc.main_vpc.id

  ingress {
    from_port   = 80
    to_port     = 80
    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"]
  }
}

resource "aws_lb" "my_alb" {
  name               = "my-alb"
  internal           = false
  load_balancer_type = "application"
  security_groups    = [aws_security_group.alb_sg.id]
  subnets            = [aws_subnet.main_subnet.id]

  enable_deletion_protection = false
}

resource "aws_lb_target_group" "target_group_1" {
  name     = "target-group-1"
  port     = 80
  protocol = "HTTP"
  vpc_id   = aws_vpc.main_vpc.id
}

resource "aws_lb_target_group" "target_group_2" {
  name     = "target-group-2"
  port     = 80
  protocol = "HTTP"
  vpc_id   = aws_vpc.main_vpc.id
}

resource "aws_lb_listener" "alb_listener" {
  load_balancer_arn = aws_lb.my_alb.arn
  port              = "80"
  protocol          = "HTTP"

  default_action {
    type = "fixed-response"
    fixed_response {
      content_type = "text/plain"
      message_body = "404: No matching host header"
      status_code  = "404"
    }
  }
}

resource "aws_lb_listener_rule" "host_header_rule_1" {
  listener_arn = aws_lb_listener.alb_listener.arn
  priority     = 1

  action {
    type             = "forward"
    target_group_arn = aws_lb_target_group.target_group_1.arn
  }

  condition {
    host_header {
      values = ["example1.com"]
    }
  }
}

resource "aws_lb_listener_rule" "host_header_rule_2" {
  listener_arn = aws_lb_listener.alb_listener.arn
  priority     = 2

  action {
    type             = "forward"
    target_group_arn = aws_lb_target_group.target_group_2.arn
  }

  condition {
    host_header {
      values = ["example2.com"]
    }
  }
}
```
Step 2: Define the ALB and Listener

In the main.tf file, we start by defining the ALB and its associated listener. The listener listens for incoming HTTP requests on port 80 and directs the traffic based on the conditions we set.
```
resource "aws_lb_listener" "alb_listener" {
  load_balancer_arn = aws_lb.my_alb.arn
  port              = "80"
  protocol          = "HTTP"

  default_action {
    type = "fixed-response"
    fixed_response {
      content_type = "text/plain"
      message_body = "404: No matching host header"
      status_code  = "404"
    }
  }
}
```
Step 3: Add Host Header Conditions

Next, we create listener rules that define the host header conditions. These rules will forward traffic to specific target groups based on the Host header in the HTTP request.
```
resource "aws_lb_listener_rule" "host_header_rule_1" {
  listener_arn = aws_lb_listener.alb_listener.arn
  priority     = 1

  action {
    type             = "forward"
    target_group_arn = aws_lb_target_group.target_group_1.arn
  }

  condition {
    host_header {
      values = ["example1.com"]
    }
  }
}

resource "aws_lb_listener_rule" "host_header_rule_2" {
  listener_arn = aws_lb_listener.alb_listener.arn
  priority     = 2

  action {
    type             = "forward"
    target_group_arn = aws_lb_target_group.target_group_2.arn
  }

  condition {
    host_header {
      values = ["example2.com"]
    }
  }
}
```
In this example, requests with a Host header of example1.com are routed to target_group_1, while requests with a Host header of example2.com are routed to target_group_2.

Step 4: Deploy the Infrastructure

Once you have defined your Terraform configuration, you can deploy the infrastructure by running the following commands:
1. Initialize Terraform: This command initializes the working directory containing the Terraform configuration files.
```
   terraform init
```
1. Review the Execution Plan: This command creates an execution plan, which lets you see what Terraform will do when you run terraform apply.
```
   terraform plan
```
1. Apply the Configuration: This command applies the changes required to reach the desired state of the configuration.
```
   terraform apply
```
After running terraform apply, Terraform will create the ALB, listener, and listener rules with the specified host header conditions.

Adding SSL to your Application Load Balancer (ALB) in AWS using Terraform involves creating an HTTPS listener, configuring an SSL certificate, and setting up the necessary security group rules. This guide will walk you through the process of adding SSL to the ALB configuration that we created earlier.

Step 1: Obtain an SSL Certificate

Before you can set up SSL on your ALB, you need to have an SSL certificate. You can obtain an SSL certificate using AWS Certificate Manager (ACM). This guide assumes you already have a certificate in ACM, but if not, you can request one via the AWS Management Console or using Terraform.

Here’s an example of how to request a certificate in Terraform:
```
resource "aws_acm_certificate" "cert" {
  domain_name       = "example.com"
  validation_method = "DNS"

  subject_alternative_names = [
    "www.example.com",
  ]

  tags = {
    Name = "example-cert"
  }
}
```
After requesting the certificate, you need to validate it. Once validated, it will be ready for use.

Step 2: Modify the ALB Security Group

To allow HTTPS traffic, you need to update the security group associated with your ALB to allow incoming traffic on port 443.
```
resource "aws_security_group_rule" "allow_https" {
  type              = "ingress"
  from_port         = 443
  to_port           = 443
  protocol          = "tcp"
  cidr_blocks       = ["0.0.0.0/0"]
  security_group_id = aws_security_group.alb_sg.id
}
```
Step 3: Add the HTTPS Listener

Now, you can add an HTTPS listener to your ALB. This listener will handle incoming HTTPS requests on port 443 and will forward them to the appropriate target groups based on the same conditions we set up earlier.
```
resource "aws_lb_listener" "https_listener" {
  load_balancer_arn = aws_lb.my_alb.arn
  port              = "443"
  protocol          = "HTTPS"
  ssl_policy        = "ELBSecurityPolicy-2016-08"
  certificate_arn   = aws_acm_certificate.cert.arn

  default_action {
    type = "fixed-response"
    fixed_response {
      content_type = "text/plain"
      message_body = "404: No matching host header"
      status_code  = "404"
    }
  }
}
```
Step 4: Add Host Header Rules for HTTPS

Just as we did with the HTTP listener, we need to create rules for the HTTPS listener to route traffic based on the Host header.
```
resource "aws_lb_listener_rule" "https_host_header_rule_1" {
  listener_arn = aws_lb_listener.https_listener.arn
  priority     = 1

  action {
    type             = "forward"
    target_group_arn = aws_lb_target_group.target_group_1.arn
  }

  condition {
    host_header {
      values = ["example1.com"]
    }
  }
}

resource "aws_lb_listener_rule" "https_host_header_rule_2" {
  listener_arn = aws_lb_listener.https_listener.arn
  priority     = 2

  action {
    type             = "forward"
    target_group_arn = aws_lb_target_group.target_group_2.arn
  }

  condition {
    host_header {
      values = ["example2.com"]
    }
  }
}
```
Step 5: Update Terraform and Apply Changes

After adding the HTTPS listener and security group rules, you need to update your Terraform configuration and apply the changes.
1. Initialize Terraform: If you haven’t done so already.
```
   terraform init
```
1. Review the Execution Plan: This command creates an execution plan to review the changes.
```
   terraform plan
```
1. Apply the Configuration: Apply the configuration to create the HTTPS listener and associated resources.
```
   terraform apply
```
Conclusion

We walked through creating an ALB listener with multiple host header conditions using Terraform. This setup allows you to route traffic to different target groups based on the Host header of incoming requests, providing a flexible way to manage multiple applications or services behind a single ALB.

By following these steps, you have successfully added SSL to your AWS ALB using Terraform. The HTTPS listener is now configured to handle secure traffic on port 443, routing it to the appropriate target groups based on the Host header.

This setup not only ensures that your application traffic is encrypted but also maintains the flexibility of routing based on different host headers. This is crucial for securing web applications and complying with modern web security standards.
August 30, 2024
Installing and Testing Sealed Secrets on a k8s Cluster Using Terraform
Introduction

In a Kubernetes environment, secrets are often used to store sensitive information like passwords, API keys, and certificates. However, these secrets are stored in plain text within the cluster, making them vulnerable to attacks. To secure this sensitive information, Sealed Secrets provides a way to encrypt secrets before they are stored in the cluster, ensuring they remain safe even if the cluster is compromised.

In this article, we’ll walk through creating a Terraform module that installs Sealed Secrets into an existing kubernetes cluster. We’ll also cover how to test the installation to ensure everything is functioning as expected.

Prerequisites

Before diving in, ensure you have the following:
- An existing k8s cluster.
- Terraform installed on your local machine.
- kubectl configured to interact with your k8s cluster.
- helm installed for managing Kubernetes packages.
Creating the Terraform Module

First, we need to create a Terraform module that will install Sealed Secrets using Helm. This module will be reusable, allowing you to deploy Sealed Secrets into any kubernetes cluster.

Directory Structure

Create a directory for your Terraform module with the following structure:
```
sealed-secrets/
│
├── main.tf
├── variables.tf
├── outputs.tf
├── README.md
```
main.tf

The main.tf file is where the core logic of the module resides. It includes a Helm release resource to install Sealed Secrets and a Kubernetes namespace resource to ensure the namespace exists before deployment.
```
resource "helm_release" "sealed_secrets" {
  name       = "sealed-secrets"
  repository = "https://bitnami-labs.github.io/sealed-secrets"
  chart      = "sealed-secrets"
  version    = var.sealed_secrets_version
  namespace  = var.sealed_secrets_namespace

  values = [
    templatefile("${path.module}/values.yaml.tpl", {
      install_crds = var.install_crds
    })
  ]

  depends_on = [kubernetes_namespace.sealed_secrets]
}

resource "kubernetes_namespace" "sealed_secrets" {
  metadata {
    name = var.sealed_secrets_namespace
  }
}

output "sealed_secrets_status" {
  value = helm_release.sealed_secrets.status
}
```
variables.tf

The variables.tf file defines all the variables that the module will use. This includes variables for Kubernetes cluster details and Helm chart configuration.
```
variable "sealed_secrets_version" {
  description = "The Sealed Secrets Helm chart version"
  type        = string
  default     = "2.7.2"  # Update to the latest version as needed
}

variable "sealed_secrets_namespace" {
  description = "The namespace where Sealed Secrets will be installed"
  type        = string
  default     = "sealed-secrets"
}

variable "install_crds" {
  description = "Whether to install the Sealed Secrets Custom Resource Definitions (CRDs)"
  type        = bool
  default     = true
}
```
outputs.tf

The outputs.tf file provides the status of the Helm release, which can be useful for debugging or for integration with other Terraform configurations.
```
output "sealed_secrets_status" {
  description = "The status of the Sealed Secrets Helm release"
  value       = helm_release.sealed_secrets.status
}
```
values.yaml.tpl

The values.yaml.tpl file is a template for customizing the Helm chart values. It allows you to dynamically set Helm values using the input variables defined in variables.tf.
```
installCRDs: ${install_crds}
```
Deploying Sealed Secrets with Terraform

Now that the module is created, you can use it in your Terraform configuration to install Sealed Secrets into your kubernetes cluster.
1. Initialize Terraform: In your main Terraform configuration directory, run:
```
   terraform init
```
1. Apply the Configuration: Apply the configuration to deploy Sealed Secrets:
```
   terraform apply
```
Terraform will prompt you to confirm the changes. Type yes to proceed.

After the deployment, Terraform will output the status of the Sealed Secrets Helm release, indicating whether it was successfully deployed.

Testing the Installation

To verify that Sealed Secrets is installed and functioning correctly, follow these steps:

1. Check the Sealed Secrets Controller Pod

Ensure that the Sealed Secrets controller pod is running in the sealed-secrets namespace.
```
kubectl get pods -n sealed-secrets
```
You should see a pod named something like sealed-secrets-controller-xxxx in the Running state.

2. Check the Custom Resource Definitions (CRDs)

If you enabled the installation of CRDs, check that they are correctly installed:
```
kubectl get crds | grep sealedsecrets
```
This command should return:
```
sealedsecrets.bitnami.com
```
3. Test Sealing and Unsealing a Secret

To ensure that Sealed Secrets is functioning as expected, create and seal a test secret, then unseal it.
1. Create a test Secret:
```
   kubectl create secret generic mysecret --from-literal=secretkey=mysecretvalue -n sealed-secrets
```
1. Encrypt the Secret using Sealed Secrets: Use the kubeseal CLI tool to encrypt the secret.
```
   kubectl get secret mysecret -n sealed-secrets -o yaml \
     | kubeseal \
     --controller-name=sealed-secrets-controller \
     --controller-namespace=sealed-secrets \
     --format=yaml > mysealedsecret.yaml
```
1. Delete the original Secret:
```
   kubectl delete secret mysecret -n sealed-secrets
```
1. Apply the Sealed Secret:
```
   kubectl apply -f mysealedsecret.yaml -n sealed-secrets
```
1. Verify that the Secret was unsealed:
```
   kubectl get secret mysecret -n sealed-secrets -o yaml
```
This command should display the unsealed secret, confirming that Sealed Secrets is working correctly.

Conclusion

In this article, we walked through the process of creating a Terraform module to install Sealed Secrets into a kubernetes cluster. We also covered how to test the installation to ensure that Sealed Secrets is properly configured and operational.

By using this Terraform module, you can easily and securely manage your Kubernetes secrets, ensuring that sensitive information is protected within your cluster.
August 28, 2024
From Launch to Management: How to Handle AWS SNS Using Terraform
Deploying and Managing AWS SNS with Terraform

Amazon Simple Notification Service (SNS) is a fully managed messaging service that facilitates communication between distributed systems by sending messages to subscribers via various protocols such as HTTP/S, email, SMS, and AWS Lambda. By using Terraform, you can automate the creation, configuration, and management of SNS topics and subscriptions, integrating them seamlessly into your infrastructure-as-code (IaC) workflows.

This article will guide you through launching and managing AWS SNS with Terraform, and will also show you how to create a Terraform module for easier reuse and scalability.

Prerequisites

Before you start, ensure that you have:
- An AWS Account with the necessary permissions to create and manage SNS topics and subscriptions.
- Terraform Installed on your local machine.
- AWS CLI Configured with your credentials.
Step 1: Set Up Your Terraform Project

Begin by creating a directory for your Terraform project:
```
mkdir sns-terraform
cd sns-terraform
touch main.tf
```
In the main.tf file, define the AWS provider:
```
provider "aws" {
  region = "us-east-1"  # Specify the AWS region
}
```
Step 2: Create and Manage an SNS Topic

Creating an SNS Topic

Define an SNS topic resource:
```
resource "aws_sns_topic" "example_topic" {
  name = "example-sns-topic"
  tags = {
    Environment = "Production"
    Team        = "DevOps"
  }
}
```
This creates an SNS topic named example-sns-topic, tagged for easier management.

Configuring Topic Attributes

You can manage additional attributes for your SNS topic, such as a display name or delivery policy:
```
resource "aws_sns_topic" "example_topic" {
  name         = "example-sns-topic"
  display_name = "Example SNS Topic"

  delivery_policy = jsonencode({
    defaultHealthyRetryPolicy = {
      minDelayTarget   = 20,
      maxDelayTarget   = 20,
      numRetries       = 3,
      backoffFunction  = "exponential"
    }
  })
}
```
Step 3: Add and Manage SNS Subscriptions

Subscriptions define the endpoints that receive messages from the SNS topic.

Email Subscription
```
resource "aws_sns_topic_subscription" "email_subscription" {
  topic_arn = aws_sns_topic.example_topic.arn
  protocol  = "email"
  endpoint  = "your-email@example.com"
}
```
SMS Subscription
```
resource "aws_sns_topic_subscription" "sms_subscription" {
  topic_arn = aws_sns_topic.example_topic.arn
  protocol  = "sms"
  endpoint  = "+1234567890"  # Replace with your phone number
}
```
Lambda Subscription
```
resource "aws_lambda_function" "example_lambda" {
  function_name = "exampleLambda"
  handler       = "index.handler"
  runtime       = "nodejs18.x"
  role          = aws_iam_role.lambda_exec_role.arn
  filename      = "lambda_function.zip"
}

resource "aws_sns_topic_subscription" "lambda_subscription" {
  topic_arn = aws_sns_topic.example_topic.arn
  protocol  = "lambda"
  endpoint  = aws_lambda_function.example_lambda.arn
}

resource "aws_lambda_permission" "allow_sns" {
  statement_id  = "AllowExecutionFromSNS"
  action        = "lambda:InvokeFunction"
  function_name = aws_lambda_function.example_lambda.function_name
  principal     = "sns.amazonaws.com"
  source_arn    = aws_sns_topic.example_topic.arn
}
```
Step 4: Manage SNS Access Control with IAM Policies

Control access to your SNS topic with IAM policies:
```
resource "aws_iam_role" "sns_publish_role" {
  name = "sns-publish-role"

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

resource "aws_iam_role_policy" "sns_publish_policy" {
  name   = "sns-publish-policy"
  role   = aws_iam_role.sns_publish_role.id

  policy = jsonencode({
    Version = "2012-10-17",
    Statement = [{
      Action   = "sns:Publish",
      Effect   = "Allow",
      Resource = aws_sns_topic.example_topic.arn
    }]
  })
}
```
Step 5: Apply the Terraform Configuration

With your SNS resources defined, apply the Terraform configuration:
1. Initialize the project:
```
   terraform init
```
1. Preview the changes:
```
   terraform plan
```
1. Apply the configuration:
```
   terraform apply
```
Confirm the prompt to create the resources.

Step 6: Create a Terraform Module for SNS

To make your SNS setup reusable, you can create a Terraform module. Modules encapsulate reusable Terraform configurations, making them easier to manage and scale.
1. Create a Module Directory:
```
   mkdir -p modules/sns
```
1. Define the Module: Inside the modules/sns directory, create main.tf, variables.tf, and outputs.tf files.
main.tf:
```
resource "aws_sns_topic" "sns_topic" {
  name = var.topic_name
  tags = var.tags
}

resource "aws_sns_topic_subscription" "sns_subscriptions" {
  count    = length(var.subscriptions)
  topic_arn = aws_sns_topic.sns_topic.arn
  protocol  = var.subscriptions[count.index].protocol
  endpoint  = var.subscriptions[count.index].endpoint
}
```
variables.tf:
```
variable "topic_name" {
  type        = string
  description = "Name of the SNS topic"
}

variable "subscriptions" {
  type = list(object({
    protocol = string
    endpoint = string
  }))
  description = "List of subscriptions"
}

variable "tags" {
  type        = map(string)
  description = "Tags for the SNS topic"
  default     = {}
}
```
outputs.tf:
```
output "sns_topic_arn" {
  value = aws_sns_topic.sns_topic.arn
}
```
1. Use the Module in Your Main Configuration: In your main main.tf file, call the module:
```
   module "sns" {
     source        = "./modules/sns"
     topic_name    = "example-sns-topic"
     subscriptions = [
       {
         protocol = "email"
         endpoint = "your-email@example.com"
       },
       {
         protocol = "sms"
         endpoint = "+1234567890"
       }
     ]
     tags = {
       Environment = "Production"
       Team        = "DevOps"
     }
   }
```
Step 7: Update and Destroy Resources

To update resources, modify the module inputs or other configurations and reapply:
```
terraform apply
```
To delete resources managed by the module, run:
```
terraform destroy
```
Amazon SNS Mobile Push Notifications, which is part of Amazon Simple Notification Service (SNS), allows you to send push notifications to mobile devices across multiple platforms, including Android, iOS, and others.

AWS SNS Mobile Push Notifications

With Amazon SNS Mobile Push Notifications, you can create platform applications for various push notification services like Apple Push Notification Service (APNs) for iOS, Firebase Cloud Messaging (FCM) for Android, and others. These platform applications can be managed using the aws_sns_platform_application resource in Terraform, as described in your original configuration.

Key Components
- Platform Applications: These represent the push notification service you are using (e.g., APNs for iOS, FCM for Android).
- Endpoints: These represent individual mobile devices registered with the platform application.
- Messages: The notifications that you send to these endpoints.
Example Configuration for AWS SNS Mobile Push Notifications

Below is an example of setting up an SNS platform application for Android (using FCM) with Terraform:
```
resource "aws_sns_platform_application" "android_application" {
  name                             = "MyAndroidApp${var.environment}"
  platform                         = "GCM" # Use GCM for FCM
  platform_credential              = var.fcm_api_key # Your FCM API Key
  event_delivery_failure_topic_arn = aws_sns_topic.delivery_failure.arn
  event_endpoint_created_topic_arn = aws_sns_topic.endpoint_created.arn
  event_endpoint_deleted_topic_arn = aws_sns_topic.endpoint_deleted.arn
  event_endpoint_updated_topic_arn = aws_sns_topic.endpoint_updated.arn
}

resource "aws_sns_topic" "delivery_failure" {
  name = "sns-delivery-failure"
}

resource "aws_sns_topic" "endpoint_created" {
  name = "sns-endpoint-created"
}

resource "aws_sns_topic" "endpoint_deleted" {
  name = "sns-endpoint-deleted"
}

resource "aws_sns_topic" "endpoint_updated" {
  name = "sns-endpoint-updated"
}
```
Comparison with GCM/FCM
- Google Cloud Messaging (GCM) / Firebase Cloud Messaging (FCM): This is Google’s platform for sending push notifications to Android devices. It requires a specific API key (token) for authentication.
- Amazon SNS Mobile Push: SNS abstracts the differences between platforms (GCM/FCM, APNs, etc.) and provides a unified way to manage push notifications across multiple platforms using a single interface.
Benefits of AWS SNS Mobile Push Notifications
1. Cross-Platform Support: Manage notifications across multiple mobile platforms (iOS, Android, Kindle, etc.) from a single service.
2. Integration with AWS Services: Easily integrate with other AWS services like Lambda, CloudWatch, and IAM.
3. Scalability: Automatically scales to support any number of notifications and endpoints.
4. Event Logging: Monitor delivery statuses and other events using SNS topics and CloudWatch.
Conclusion

By combining Terraform’s power with AWS SNS, you can efficiently launch, manage, and automate your messaging infrastructure. The Terraform module further simplifies and standardizes the deployment, making it reusable and scalable across different environments. With this setup, you can easily integrate SNS into your infrastructure-as-code strategy, ensuring consistency and reliability in your cloud operations.

AWS SNS Mobile Push Notifications serves as the AWS counterpart to GCM/FCM, providing a powerful, scalable solution for managing push notifications to mobile devices. With Terraform, you can automate the setup and management of SNS platform applications, making it easier to handle push notifications within your AWS infrastructure.
August 26, 2024
How to Launch Zipkin and Sentry in a Local Kind Cluster Using Terraform and Helm
In modern software development, monitoring and observability are crucial for maintaining the health and performance of applications. Zipkin and Sentry are two powerful tools that can be used to track errors and distributed traces in your applications. In this article, we’ll guide you through the process of deploying Zipkin and Sentry on a local Kubernetes cluster managed by Kind, using Terraform and Helm. This setup provides a robust monitoring stack that you can run locally for development and testing.

Overview

This guide describes a Terraform project designed to deploy a monitoring stack with Sentry for error tracking and Zipkin for distributed tracing on a Kubernetes cluster managed by Kind. The project automates the setup of all necessary Kubernetes resources, including namespaces and Helm releases for both Sentry and Zipkin.

Tech Stack
- Kind: A tool for running local Kubernetes clusters using Docker containers as nodes.
- Terraform: Infrastructure as Code (IaC) tool used to manage the deployment.
- Helm: A package manager for Kubernetes that simplifies the deployment of applications.
Prerequisites

Before you start, make sure you have the following installed and configured:
- Kubernetes cluster: We’ll use Kind for this local setup.
- Terraform: Installed on your local machine.
- Helm: Installed for managing Kubernetes packages.
- kubectl: Configured to communicate with your Kubernetes cluster.
Project Structure

Here are the key files in the project:
- provider.tf: Sets up the Terraform provider configuration for Kubernetes.
- sentry.tf: Defines the Terraform resources for deploying Sentry using Helm.
- zipkin.tf: Defines the Kubernetes resources necessary for deploying Zipkin.
- zipkin_ingress.tf: Sets up the Kubernetes Ingress resource for Zipkin to allow external access.
Example: zipkin.tf
```
resource "kubernetes_namespace" "zipkin" {
  metadata {
    name = "zipkin"
  }
}

resource "kubernetes_deployment" "zipkin" {
  metadata {
    name      = "zipkin"
    namespace = kubernetes_namespace.zipkin.metadata[0].name
  }

  spec {
    replicas = 1

    selector {
      match_labels = {
        app = "zipkin"
      }
    }

    template {
      metadata {
        labels = {
          app = "zipkin"
        }
      }

      spec {
        container {
          name  = "zipkin"
          image = "openzipkin/zipkin"

          port {
            container_port = 9411
          }
        }
      }
    }
  }
}

resource "kubernetes_service" "zipkin" {
  metadata {
    name      = "zipkin"
    namespace = kubernetes_namespace.zipkin.metadata[0].name
  }

  spec {
    selector = {
      app = "zipkin"
    }

    port {
      port        = 9411
      target_port = 9411
    }

    type = "NodePort"
  }
}
```
Example: sentry.tf
```
resource "kubernetes_namespace" "sentry" {
  metadata {
    name = var.sentry_app_name
  }
}

resource "helm_release" "sentry" {
  name       = var.sentry_app_name
  namespace  = var.sentry_app_name
  repository = "https://sentry-kubernetes.github.io/charts"
  chart      = "sentry"
  version    = "22.2.1"
  timeout    = 900

  set {
    name  = "ingress.enabled"
    value = var.sentry_ingress_enabled
  }

  set {
    name  = "ingress.hostname"
    value = var.sentry_ingress_hostname
  }

  set {
    name  = "postgresql.postgresqlPassword"
    value = var.sentry_postgresql_postgresqlPassword
  }

  set {
    name  = "kafka.podSecurityContext.enabled"
    value = "true"
  }

  set {
    name  = "kafka.podSecurityContext.seccompProfile.type"
    value = "Unconfined"
  }

  set {
    name  = "kafka.resources.requests.memory"
    value = var.kafka_resources_requests_memory
  }

  set {
    name  = "kafka.resources.limits.memory"
    value = var.kafka_resources_limits_memory
  }

  set {
    name  = "user.email"
    value = var.sentry_user_email
  }

  set {
    name  = "user.password"
    value = var.sentry_user_password
  }

  set {
    name  = "user.createAdmin"
    value = var.sentry_user_create_admin
  }

  depends_on = [kubernetes_namespace.sentry]
}
```
Configuration

Before deploying, you need to adjust the configurations in terraform.tfvars to match your environment. This includes settings related to Sentry and Zipkin. Additionally, ensure that the following entries are added to your /etc/hosts file to map the local domains to your localhost:
```
127.0.0.1       sentry.local
127.0.0.1       zipkin.local
```
Step 1: Create a Kind Cluster

Clone the repository containing your Terraform and Helm configurations, and create a Kind cluster using the following command:
```
kind create cluster --config prerequisites/kind-config.yaml
```
Step 2: Set Up the Ingress NGINX Controller

Next, set up an Ingress NGINX controller, which will manage external access to the services within your cluster. Apply the Ingress controller manifest:
```
kubectl apply -f https://raw.githubusercontent.com/kubernetes/ingress-nginx/main/deploy/static/provider/kind/deploy.yaml
```
Wait for the Ingress controller to be ready to process requests:
```
kubectl wait --namespace ingress-nginx \
  --for=condition=ready pod \
  --selector=app.kubernetes.io/component=controller \
  --timeout=90s
```
Step 3: Initialize Terraform

Navigate to the project directory where your Terraform files are located and initialize Terraform:
```
terraform init
```
Step 4: Apply the Terraform Configuration

To deploy Sentry and Zipkin, apply the Terraform configuration:
```
terraform apply
```
This command will provision all necessary resources, including namespaces, Helm releases for Sentry, and Kubernetes resources for Zipkin.

Step 5: Verify the Deployment

After the deployment is complete, you can verify the status of your resources by running:
```
kubectl get all -A
```
This command lists all resources across all namespaces, allowing you to check if everything is running as expected.

Step 6: Access Sentry and Zipkin

Once the deployment is complete, you can access the Sentry and Zipkin dashboards through the following URLs:
- Sentry: http://sentry.local/auth/login/sentry/
- Zipkin: http://zipkin.local/zipkin/
These URLs should open the respective web interfaces for Sentry and Zipkin, where you can start monitoring errors and trace requests across your applications.

Additional Tools

For a more comprehensive view of your Kubernetes resources, consider using the Kubernetes dashboard, which provides a user-friendly interface for managing and monitoring your cluster.

Cleanup

If you want to remove the deployed infrastructure, run the following command:
```
terraform destroy
```
This command will delete all resources created by Terraform. To remove the Kind cluster entirely, use:
```
kind delete cluster
```
This will clean up the cluster, leaving your environment as it was before the setup.

Conclusion

By following this guide, you’ve successfully deployed a powerful monitoring stack with Zipkin and Sentry on a local Kind cluster using Terraform and Helm. This setup is ideal for local development and testing, allowing you to monitor errors and trace requests across your applications with ease. With the flexibility of Terraform and Helm, you can easily adapt this configuration to suit other environments or expand it with additional monitoring tools.
August 7, 2024

The Terraform Toolkit: Spinning Up an EKS Cluster

Creating an Amazon EKS (Elastic Kubernetes Service) cluster using Terraform involves a series of carefully orchestrated steps. Each step can be encapsulated within its own Terraform module for better modularity and reusability. Here’s a breakdown of how to structure your Terraform project to deploy an EKS cluster on AWS.

1. VPC Module

Create a Virtual Private Cloud (VPC): This is where your EKS cluster will reside.
Set Up Subnets: Establish both public and private subnets within the VPC to segregate your resources effectively.

2. EKS Module

Deploy the EKS Cluster: Link the components created in the VPC module to your EKS cluster.
Define Security Rules: Set up security groups and rules for both the EKS master nodes and worker nodes.
Configure IAM Roles: Create IAM roles and policies needed for the EKS master and worker nodes.

Project Directory Structure

Let’s begin by creating a root project directory named terraform-eks-project. Below is the suggested directory structure for the entire Terraform project:

terraform-eks-project/
│
├── modules/                    # Root directory for all modules
│   ├── vpc/                    # VPC module: VPC, Subnets (public & private)
│   │   ├── main.tf
│   │   ├── variables.tf
│   │   └── outputs.tf
│   │
│   └── eks/                    # EKS module: cluster, worker nodes, IAM roles, security groups
│       ├── main.tf
│       ├── variables.tf
│       ├── outputs.tf
│       └── worker_userdata.tpl
│
├── backend.tf                  # Backend configuration (e.g., S3 for remote state)
├── main.tf                     # Main file to call and stitch modules together
├── variables.tf                # Input variables for the main configuration
├── outputs.tf                  # Output values from the main configuration
├── provider.tf                 # Provider block for the main configuration
├── terraform.tfvars            # Variable definitions file
└── README.md                   # Documentation and instructions

Root Configuration Files Overview

backend.tf: Specifies how Terraform state is managed and where it’s stored (e.g., in an S3 bucket).
main.tf: The central configuration file that integrates the various modules and manages the AWS resources.
variables.tf: Declares the variables used throughout the project.
outputs.tf: Manages the outputs from the Terraform scripts, such as IDs and ARNs.
terraform.tfvars: Contains user-defined values for the variables.
README.md: Provides documentation and usage instructions for the project.

Backend Configuration (backend.tf)

The backend.tf file is responsible for defining how Terraform state is loaded and how operations are executed. For instance, using an S3 bucket as the backend allows for secure and durable state storage.

terraform {
  backend "s3" {
    bucket  = "my-terraform-state-bucket"      # Replace with your S3 bucket name
    key     = "path/to/my/key"                 # Path to the state file within the bucket
    region  = "us-west-1"                      # AWS region of your S3 bucket
    encrypt = true                             # Enable server-side encryption of the state file

    # Optional: DynamoDB for state locking and consistency
    dynamodb_table = "my-terraform-lock-table" # Replace with your DynamoDB table name

    # Optional: If S3 bucket and DynamoDB table are in different AWS accounts or need specific credentials
    # profile = "myprofile"                    # AWS CLI profile name
  }
}

Main Configuration (main.tf)

The main.tf file includes module declarations for the VPC and EKS components.

VPC Module

The VPC module creates the foundational network infrastructure components.

module "vpc" {
  source                = "./modules/vpc"            # Location of the VPC module
  env                   = terraform.workspace        # Current workspace (e.g., dev, prod)
  app                   = var.app                    # Application name or type
  vpc_cidr              = lookup(var.vpc_cidr_env, terraform.workspace)  # CIDR block specific to workspace
  public_subnet_number  = 2                          # Number of public subnets
  private_subnet_number = 2                          # Number of private subnets
  db_subnet_number      = 2                          # Number of database subnets
  region                = var.aws_region             # AWS region

  # NAT Gateways settings
  vpc_enable_nat_gateway = var.vpc_enable_nat_gateway  # Enable/disable NAT Gateway
  enable_dns_hostnames = true                         # Enable DNS hostnames in the VPC
  enable_dns_support   = true                         # Enable DNS resolution in the VPC
}

EKS Module

The EKS module sets up a managed Kubernetes cluster on AWS.

module "eks" {
  source                               = "./modules/eks"
  env                                  = terraform.workspace
  app                                  = var.app
  vpc_id                               = module.vpc.vpc_id
  cluster_name                         = var.cluster_name
  cluster_service_ipv4_cidr            = lookup(var.cluster_service_ipv4_cidr, terraform.workspace)
  public_subnets                       = module.vpc.public_subnet_ids
  cluster_version                      = var.cluster_version
  cluster_endpoint_private_access      = var.cluster_endpoint_private_access
  cluster_endpoint_public_access       = var.cluster_endpoint_public_access
  cluster_endpoint_public_access_cidrs = var.cluster_endpoint_public_access_cidrs
  sg_name                              = var.sg_external_eks_name
}

Outputs Configuration (outputs.tf)

The outputs.tf file defines the values that Terraform will output after applying the configuration. These outputs can be used for further automation or simply for inspection.

output "vpc_id" {
  value = module.vpc.vpc_id
}

output "cluster_id" {
  value = module.eks.cluster_id
}

output "cluster_arn" {
  value = module.eks.cluster_arn
}

output "cluster_certificate_authority_data" {
  value = module.eks.cluster_certificate_authority_data
}

output "cluster_endpoint" {
  value = module.eks.cluster_endpoint
}

output "cluster_version" {
  value = module.eks.cluster_version
}

Variable Definitions (terraform.tfvars)

The terraform.tfvars file is where you define the values for variables that Terraform will use.

aws_region = "us-east-1"

# VPC Core
vpc_cidr_env = {
  "dev" = "10.101.0.0/16"
  #"test" = "10.102.0.0/16"
  #"prod" = "10.103.0.0/16"
}
cluster_service_ipv4_cidr = {
  "dev" = "10.150.0.0/16"
  #"test" = "10.201.0.0/16"
  #"prod" = "10.1.0.0/16"
}

enable_dns_hostnames   = true
enable_dns_support     = true
vpc_enable_nat_gateway = false

# EKS Configuration
cluster_name                         = "test_cluster"
cluster_version                      = "1.27"
cluster_endpoint_private_access      = true
cluster_endpoint_public_access       = true
cluster_endpoint_public_access_cidrs = ["0.0.0.0/0"]
sg_external_eks_name                 = "external_kubernetes_sg"

Variable Declarations (variables.tf)

The variables.tf file is where you declare all the variables used in your Terraform configuration. This allows for flexible and reusable configurations.

variable "aws_region" {
  description = "Region in which AWS Resources to be created"
  type        = string
  default     = "us-east-1"
}

variable "zone" {
  description = "The zone where VPC is"
  type        = list(string)
  default     = ["us-east-1a", "us-east-1b"]
}

variable "azs" {
  type        = list(string)
  description = "List of availability zones suffixes."
  default     = ["a", "b", "c"]
}

variable "app" {
  description = "The APP name"
  default     = "ekstestproject"
}

variable "env" {
  description = "The Environment variable"
  type        = string
  default     = "dev"
}
variable "vpc_cidr_env" {}
variable "cluster_service_ipv4_cidr" {}

variable "enable_dns_hostnames" {}
variable "enable_dns_support" {}

# VPC Enable NAT Gateway (True or False)
variable "vpc_enable_nat_gateway" {
  description = "Enable NAT Gateways for Private Subnets Outbound Communication"
  type        = bool
  default     = true
}

# VPC Single NAT Gateway (True or False)
variable "vpc_single_nat_gateway" {
  description = "Enable only single NAT Gateway in one Availability Zone to save costs during our demos"
  type        = bool
  default     = true
}

# EKS Variables
variable "cluster_name" {
  description = "The EKS cluster name"
  default     = "k8s"
}
variable "cluster_version" {
  description = "The Kubernetes minor version to use for the

 EKS cluster (for example 1.26)"
  type        = string
  default     = null
}

variable "cluster_endpoint_private_access" {
  description = "Indicates whether the Amazon EKS private API server endpoint is enabled."
  type        = bool
  default     = false
}

variable "cluster_endpoint_public_access" {
  description = "Indicates whether the Amazon EKS public API server endpoint is enabled."
  type        = bool
  default     = true
}

variable "cluster_endpoint_public_access_cidrs" {
  description = "List of CIDR blocks which can access the Amazon EKS public API server endpoint."
  type        = list(string)
  default     = ["0.0.0.0/0"]
}

variable "sg_external_eks_name" {
  description = "The SG name."
}

Conclusion

This guide outlines the key components of setting up an Amazon EKS cluster using Terraform. By organizing your Terraform code into reusable modules, you can efficiently manage and scale your infrastructure across different environments. The modular approach not only simplifies management but also promotes consistency and reusability in your Terraform configurations.

July 26, 2024

Terraformer and TerraCognita: Tools for Infrastructure as Code Transformation
As organizations increasingly adopt Infrastructure as Code (IaC) to manage their cloud environments, tools like Terraformer and TerraCognita have become essential for simplifying the migration of existing infrastructure to Terraform. These tools automate the process of generating Terraform configurations from existing cloud resources, enabling teams to manage their infrastructure more efficiently and consistently.

What is Terraformer?

Terraformer is an open-source tool that automatically generates Terraform configurations and state files from existing cloud resources. It supports multiple cloud providers, including AWS, Google Cloud, Azure, and others, making it a versatile solution for IaC practitioners who need to migrate or document their infrastructure.

Key Features of Terraformer
1. Multi-Cloud Support: Terraformer supports a wide range of cloud providers, enabling you to generate Terraform configurations for AWS, Google Cloud, Azure, Kubernetes, and more.
2. State File Generation: In addition to generating Terraform configuration files (.tf), Terraformer can create a Terraform state file (.tfstate). This allows you to import existing resources into Terraform without needing to manually import each resource one by one.
3. Selective Resource Generation: Terraformer allows you to selectively generate Terraform code for specific resources or groups of resources. This feature is particularly useful when you only want to manage part of your infrastructure with Terraform.
4. Automated Dependency Management: Terraformer automatically manages dependencies between resources, ensuring that the generated Terraform code reflects the correct resource relationships.
Using Terraformer

To use Terraformer, you typically follow these steps:
1. Install Terraformer: Terraformer can be installed via a package manager like Homebrew (for macOS) or downloaded from the Terraformer GitHub releases page.
```
   brew install terraformer
```
1. Generate Terraform Code: Use Terraformer to generate Terraform configuration files for your existing infrastructure. For example, to generate Terraform code for AWS resources:
```
   terraformer import aws --resources=vpc,subnet --regions=us-east-1
```
1. Review and Customize: After generating the Terraform code, review the .tf files to ensure they meet your standards. You may need to customize the code or variables to align with your IaC practices.
2. Apply and Manage: Once you’re satisfied with the generated code, you can apply it using Terraform to start managing your infrastructure as code.
What is TerraCognita?

TerraCognita is another open-source tool designed to help migrate existing cloud infrastructure into Terraform code. Like Terraformer, TerraCognita supports multiple cloud providers and simplifies the process of onboarding existing resources into Terraform management.

Key Features of TerraCognita
1. Multi-Provider Support: TerraCognita supports various cloud providers, including AWS, Google Cloud, and Azure. This makes it a flexible tool for organizations with multi-cloud environments.
2. Interactive Migration: TerraCognita offers an interactive CLI that guides you through the process of selecting which resources to import into Terraform, making it easier to manage complex environments.
3. Automatic Code Generation: TerraCognita automatically generates Terraform code for the selected resources, handling the complexities of resource dependencies and configuration.
4. Customization and Filters: TerraCognita allows you to filter resources based on tags, regions, or specific types. This feature helps you focus on relevant parts of your infrastructure and avoid unnecessary clutter in your Terraform codebase.
Using TerraCognita

Here’s how you can use TerraCognita:
1. Install TerraCognita: You can download TerraCognita from its GitHub repository and install it on your machine.
```
   go install github.com/cycloidio/terracognita/cmd/tc@latest
```
1. Run TerraCognita: Start TerraCognita with the appropriate flags to begin importing resources. For instance, to import AWS resources:
```
   terracognita aws --access-key-id <your-access-key-id> --secret-access-key <your-secret-access-key> --region us-east-1 --tfstate terraform.tfstate
```
1. Interactively Select Resources: Use the interactive prompts to select which resources you want to import into Terraform. TerraCognita will generate the corresponding Terraform configuration files.
2. Review and Refine: Review the generated Terraform files and refine them as needed to fit your infrastructure management practices.
3. Apply the Configuration: Use Terraform to apply the configuration and start managing your infrastructure with Terraform.
Comparison: Terraformer vs. TerraCognita

While both Terraformer and TerraCognita serve similar purposes, there are some differences that might make one more suitable for your needs:
- User Interface: Terraformer is more command-line focused, while TerraCognita provides an interactive experience, which can be easier for users unfamiliar with the command line.
- Resource Selection: TerraCognita’s interactive mode makes it easier to selectively import resources, while Terraformer relies more on command-line flags for selection.
- Community and Ecosystem: Terraformer has a larger community and more extensive support for cloud providers, making it a more robust choice for enterprises with diverse cloud environments.
Conclusion

Both Terraformer and TerraCognita are powerful tools for generating Terraform code from existing cloud infrastructure. They help teams adopt Infrastructure as Code practices without the need to manually rewrite existing configurations, thus saving time and reducing the risk of errors. Depending on your workflow and preference, either tool can significantly streamline the process of managing cloud infrastructure with Terraform.
May 31, 2024
The Evolution of Terraform Project Structures: From Simple Beginnings to Enterprise-Scale Infrastructure
As you embark on your journey with Terraform, you’ll quickly realize that what starts as a modest project can evolve into something much larger and more complex. Whether you’re just tinkering with Terraform for a small side project or managing a sprawling enterprise infrastructure, understanding how to structure your Terraform code effectively is crucial for maintaining sanity as your project grows. Let’s explore how a Terraform project typically progresses from a simple setup to a robust, enterprise-level deployment, adding layers of sophistication at each stage.

1. Starting Small: The Foundation of a Simple Terraform Project

In the early stages, Terraform projects are often straightforward. Imagine you’re working on a small, personal project, or perhaps a simple infrastructure setup for a startup. At this point, your project might consist of just a few resources managed within a single file, main.tf. All your configurations—from providers to resources—are defined in this one file.

For example, you might start by creating a simple Virtual Private Cloud (VPC) on AWS:
```
provider "aws" {
  region = "us-east-1"
}

resource "aws_vpc" "main" {
  cidr_block = "10.0.0.0/16"
  tags = {
    Name = "main-vpc"
  }
}
```
This setup is sufficient for a small-scale project. It’s easy to manage and understand when the scope is limited. However, as your project grows, this simplicity can quickly become a liability. Hardcoding values, for instance, can lead to repetition and make your code less flexible and reusable.

2. The First Refactor: Modularizing Your Terraform Code

As your familiarity with Terraform increases, you’ll likely start to feel the need to organize your code better. This is where refactoring comes into play. The first step might involve splitting your configuration into multiple files, each dedicated to a specific aspect of your infrastructure, such as providers, variables, and resources.

For example, you might separate the provider configuration into its own file, provider.tf, and use a variables.tf file to store variable definitions:
```
# provider.tf
provider "aws" {
  region = var.region
}

# variables.tf
variable "region" {
  default = "us-east-1"
}

variable "cidr_block" {
  default = "10.0.0.0/16"
}
```
By doing this, you not only make your code more readable but also more adaptable. Now, if you need to change the AWS region or VPC CIDR block, you can do so in one place, and the changes will propagate throughout your project.

3. Introducing Multiple Environments: Development, Staging, Production

As your project grows, you might start to work with multiple environments—development, staging, and production. Running everything from a single setup is no longer practical or safe. A mistake in development could easily impact production if both environments share the same configuration.

To manage this, you can create separate folders for each environment:
```
/terraform-project
    /environments
        /development
            main.tf
            variables.tf
        /production
            main.tf
            variables.tf
```
This structure allows you to maintain isolation between environments. Each environment has its own state, variables, and resource definitions, reducing the risk of accidental changes affecting production systems.

4. Managing Global Resources: Centralizing Shared Infrastructure

As your infrastructure grows, you’ll likely encounter resources that need to be shared across environments, such as IAM roles, S3 buckets, or DNS configurations. Instead of duplicating these resources in every environment, it’s more efficient to manage them in a central location.

Here’s an example structure:
```
/terraform-project
    /environments
        /development
        /production
    /global
        iam.tf
        s3.tf
```
By centralizing these global resources, you ensure consistency across environments and simplify management. This approach also helps prevent configuration drift, where environments slowly diverge from one another over time.

5. Breaking Down Components: Organizing by Infrastructure Components

As your project continues to grow, your main.tf files in each environment can become cluttered with many resources. This is where organizing your infrastructure into logical components comes in handy. By breaking down your infrastructure into smaller, manageable parts—like VPCs, subnets, and security groups—you can make your code more modular and easier to maintain.

For example:
```
/terraform-project
    /environments
        /development
            /vpc
                main.tf
            /subnet
                main.tf
        /production
            /vpc
                main.tf
            /subnet
                main.tf
```
This structure allows you to work on specific infrastructure components without being overwhelmed by the entirety of the configuration. It also enables more granular control over your Terraform state files, reducing the likelihood of conflicts during concurrent updates.

6. Embracing Modules: Reusability Across Environments

Once you’ve modularized your infrastructure into components, you might notice that you’re repeating the same configurations across multiple environments. Terraform modules allow you to encapsulate these configurations into reusable units. This not only reduces code duplication but also ensures that all environments adhere to the same best practices.

Here’s how you might structure your project with modules:
```
/terraform-project
    /modules
        /vpc
            main.tf
            variables.tf
            outputs.tf
    /environments
        /development
            main.tf
        /production
            main.tf
```
In each environment, you can call the VPC module like this:
```
module "vpc" {
  source = "../../modules/vpc"
  region = var.region
  cidr_block = var.cidr_block
}
```
7. Versioning Modules: Managing Change with Control

As your project evolves, you may need to make changes to your modules. However, you don’t want these changes to automatically propagate to all environments. To manage this, you can version your modules, ensuring that each environment uses a specific version and that updates are applied only when you’re ready.

For example:
```
/modules
    /vpc
        /v1
        /v2
```
Environments can reference a specific version of the module:
```
module "vpc" {
  source  = "git::https://github.com/your-org/terraform-vpc.git?ref=v1.0.0"
  region  = var.region
  cidr_block = var.cidr_block
}
```
8. Scaling to Enterprise Level: Separate Repositories and Automation

As your project scales, especially in an enterprise setting, you might find it beneficial to maintain separate Git repositories for each module. This approach increases modularity and allows teams to work independently on different components of the infrastructure. You can also leverage Git tags for versioning and rollback capabilities.

Furthermore, automating your Terraform workflows using CI/CD pipelines is essential at this scale. Automating tasks such as Terraform plan and apply actions ensures consistency, reduces human error, and accelerates deployment processes.

A basic CI/CD pipeline might look like this:
```
name: Terraform
on:
  push:
    paths:
      - 'environments/development/**'
jobs:
  terraform:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout code
        uses: actions/checkout@v2
      - name: Setup Terraform
        uses: hashicorp/setup-terraform@v1
      - name: Terraform Init
        run: terraform init
        working-directory: environments/development
      - name: Terraform Plan
        run: terraform plan
        working-directory: environments/development
      - name: Terraform Apply
        run: terraform apply -auto-approve
        working-directory: environments/development
```
Conclusion: From Simplicity to Sophistication

Terraform is a powerful tool that grows with your needs. Whether you’re managing a small project or an enterprise-scale infrastructure, the key to success is structuring your Terraform code in a way that is both maintainable and scalable. By following these best practices, you can ensure that your infrastructure evolves gracefully, no matter how complex it becomes.

Remember, as your Terraform project evolves, it’s crucial to periodically refactor and reorganize to keep things manageable. With the right structure and automation in place, you can confidently scale your infrastructure and maintain it efficiently. Happy Terraforming!
March 21, 2024
How to Move Terraform State Between AWS Accounts
Managing Terraform state effectively is crucial for maintaining the integrity of your infrastructure. As your organization grows, you may need to move Terraform state files between different AWS accounts for security, compliance, or organizational restructuring reasons. This article provides steps how to safely migrate your Terraform state from one AWS account to another.

Why Move Terraform State Between Accounts?

Moving Terraform state files between AWS accounts might be necessary for several reasons:
1. Security: Separating state files from the infrastructure they manage can enhance security by limiting access to sensitive information.
2. Compliance: Regulatory requirements might mandate that state files be stored in specific accounts or regions.
3. Organizational Changes: As your organization evolves, you may need to reorganize cloud resources and associated state files into different accounts.
Pre-Migration Considerations

Before you begin the migration process, ensure the following:
- Backup Your State File: Always back up your Terraform state file before making any changes. This can be done by copying the file to a secure location.
- Plan for Downtime: If your infrastructure is highly sensitive, plan for potential downtime during the migration process.
- Access Permissions: Ensure that you have the necessary permissions in both the source and target AWS accounts to access and modify the Terraform state.
Step-by-Step Guide to Moving Terraform State

1. Set Up the S3 Bucket in the Target Account

First, create an S3 bucket and a DynamoDB table in the target AWS account where you’ll store the Terraform state and manage state locking.
```
provider "aws" {
  alias  = "target"
  region = "us-west-2"
  # Configure credentials for the target account
}

resource "aws_s3_bucket" "terraform_state" {
  provider = aws.target
  bucket   = "my-new-terraform-state-bucket"

  versioning {
    enabled = true
  }

  server_side_encryption_configuration {
    rule {
      apply_server_side_encryption_by_default {
        sse_algorithm = "AES256"
      }
    }
  }
}

resource "aws_dynamodb_table" "terraform_locks" {
  provider  = aws.target
  name      = "terraform-state-locks"
  hash_key  = "LockID"
  billing_mode = "PAY_PER_REQUEST"

  attribute {
    name = "LockID"
    type = "S"
  }
}
```
2. Update the Backend Configuration

In your existing Terraform configuration, update the backend block to point to the new S3 bucket and DynamoDB table in the target account.
```
terraform {
  backend "s3" {
    bucket         = "my-new-terraform-state-bucket"
    key            = "path/to/my/terraform.tfstate"
    region         = "us-west-2"
    encrypt        = true
    dynamodb_table = "terraform-state-locks"
  }
}
```
3. Migrate the State File

To move the Terraform state file to the new S3 bucket, use the terraform init command with the -migrate-state flag. This will prompt Terraform to migrate the state from the current backend to the new one.
```
terraform init -migrate-state
```
4. Verify the Migration

After the migration is complete, verify that the state has been correctly moved by running terraform plan. This ensures that Terraform can read the state from the new backend and that there are no discrepancies.
```
terraform plan
```
If everything is configured correctly, Terraform should not show any differences in the resources managed by the state file.

5. Clean Up the Old State

Once you have verified that the migration was successful, clean up the old state by deleting the state file from the previous S3 bucket in the original account. This is an optional but recommended step to prevent confusion and ensure that no one accidentally uses the old state.
```
aws s3 rm s3://my-old-terraform-state-bucket/path/to/my/terraform.tfstate
```
Post-Migration Considerations
- Update CI/CD Pipelines: If you use continuous integration/continuous deployment (CI/CD) pipelines, update them to reference the new state location.
- Permissions: Review and update permissions in the new AWS account to ensure only authorized users have access to the Terraform state files.
- Monitoring and Logging: Set up monitoring and logging in the target account to track access and changes to the Terraform state.
Troubleshooting Common Issues
- Access Denied Errors: Ensure that the IAM roles or users in the target account have the necessary permissions to access the S3 bucket and DynamoDB table.
- State File Corruption: If the state file appears to be corrupted after migration, restore from your backup and retry the migration process.
- State Locking Issues: If you encounter issues with state locking, verify that the DynamoDB table is correctly configured and that the lock ID matches between the old and new configurations.
Conclusion

Moving Terraform state between AWS accounts is a straightforward process that can significantly improve your cloud infrastructure’s security and compliance posture. By following the steps outlined in this guide, you can ensure a smooth and safe transition of your Terraform state files. Always remember to back up your state files before making any changes, verify the migration process, and update all related configurations accordingly.
January 9, 2024
Managing Terraform State Across AWS Accounts: A Guide to Cross-Account Configuration
When working with Terraform in multi-account AWS environments, it’s often necessary to store the Terraform state in one AWS account (let’s call it Account A) while provisioning infrastructure in another account (Account B). This setup enhances security, centralizes state management, and facilitates better separation of duties. Here’s how you can achieve this using cross-account roles in AWS.

Why Separate State and Infrastructure?

Storing Terraform state files in a different AWS account than where the infrastructure is provisioned offers several benefits:
1. Centralized State Management: By centralizing Terraform state in one account, you can manage and monitor state files more effectively.
2. Enhanced Security: By segregating roles and permissions, you limit the exposure of sensitive state data.
3. Separation of Duties: This setup supports organizations that follow strict security practices by separating administrative duties across accounts.
Step-by-Step Setup

1. Create an S3 Bucket in Account A

In Account A, create an S3 bucket to store the Terraform state files and a DynamoDB table to handle state locking. This ensures consistency and prevents concurrent operations from corrupting the state.
```
provider "aws" {
  alias  = "account_a"
  region = "us-west-2"
}

resource "aws_s3_bucket" "terraform_state" {
  provider = aws.account_a
  bucket   = "my-terraform-state-bucket"

  versioning {
    enabled = true
  }

  server_side_encryption_configuration {
    rule {
      apply_server_side_encryption_by_default {
        sse_algorithm = "AES256"
      }
    }
  }
}

resource "aws_dynamodb_table" "terraform_locks" {
  provider  = aws.account_a
  name      = "terraform-state-locks"
  hash_key  = "LockID"
  billing_mode = "PAY_PER_REQUEST"

  attribute {
    name = "LockID"
    type = "S"
  }
}
```
2. Configure the Backend to Use the S3 Bucket

In your Terraform configuration, specify the backend as the S3 bucket in Account A. Use the role_arn to assume a role in Account B when applying infrastructure changes.
```
terraform {
  backend "s3" {
    bucket         = "my-terraform-state-bucket"
    key            = "path/to/my/terraform.tfstate"
    region         = "us-west-2"
    encrypt        = true
    dynamodb_table = "terraform-state-locks"
    role_arn       = "arn:aws:iam::ACCOUNT_B_ID:role/AccountB-TerraformRole"
  }
}
```
3. Create a Cross-Account Role in Account B

In Account B, create an IAM role that allows Account A to assume it. This role should have the necessary permissions to provision resources.
```
resource "aws_iam_role" "terraform" {
  name = "AccountB-TerraformRole"

  assume_role_policy = jsonencode({
    Version = "2012-10-17",
    Statement = [
      {
        Effect = "Allow",
        Principal = {
          "AWS" = "arn:aws:iam::ACCOUNT_A_ID:user/your-username"
        },
        Action = "sts:AssumeRole"
      }
    ]
  })
}

resource "aws_iam_policy" "terraform_policy" {
  name        = "terraform-full-access"
  description = "Full access for Terraform"
  policy = jsonencode({
    Version = "2012-10-17",
    Statement = [
      {
        Action = [
          "ec2:*",
          "s3:*",
          "iam:*",
          "dynamodb:*",
          "rds:*"
        ],
        Effect   = "Allow",
        Resource = "*"
      }
    ]
  })
}

resource "aws_iam_role_policy_attachment" "attach" {
  role       = aws_iam_role.terraform.name
  policy_arn = aws_iam_policy.terraform_policy.arn
}
```
4. Use the Assume Role in Terraform

In Account A, configure Terraform to assume the role in Account B when applying infrastructure.
```
provider "aws" {
  alias  = "account_b"
  region = "us-west-2"
  assume_role {
    role_arn = "arn:aws:iam::ACCOUNT_B_ID:role/AccountB-TerraformRole"
  }
}
```
Conclusion

By configuring cross-account roles and using Terraform’s backend configuration, you can securely manage infrastructure across multiple AWS accounts while keeping the state files centralized. This setup not only improves security but also aligns with best practices for managing infrastructure as code at scale.
December 8, 2023

Tag: Terraform

Prerequisites

Step 1: Set Up Path-Based Target Groups

Step 2: Create the HTTPS Listener

Step 3: Define Path-Based Routing Rules

Step 4: Apply Your Terraform Configuration

Conclusion

Prerequisites

Step 1: Set Up Your Terraform Configuration

Step 2: Define the ALB and Listener

Step 3: Add Host Header Conditions

Step 4: Deploy the Infrastructure

Step 1: Obtain an SSL Certificate

Step 2: Modify the ALB Security Group

Step 3: Add the HTTPS Listener

Step 4: Add Host Header Rules for HTTPS

Step 5: Update Terraform and Apply Changes

Conclusion

Introduction

Prerequisites

Creating the Terraform Module

Directory Structure

main.tf

variables.tf

outputs.tf

values.yaml.tpl

Deploying Sealed Secrets with Terraform

Testing the Installation

1. Check the Sealed Secrets Controller Pod

2. Check the Custom Resource Definitions (CRDs)

3. Test Sealing and Unsealing a Secret

Conclusion

Deploying and Managing AWS SNS with Terraform

Prerequisites

Step 1: Set Up Your Terraform Project

Step 2: Create and Manage an SNS Topic

Creating an SNS Topic

Configuring Topic Attributes

Step 3: Add and Manage SNS Subscriptions

Email Subscription

SMS Subscription

Lambda Subscription

Step 4: Manage SNS Access Control with IAM Policies

Step 5: Apply the Terraform Configuration

Step 6: Create a Terraform Module for SNS

Step 7: Update and Destroy Resources

AWS SNS Mobile Push Notifications

Key Components

Example Configuration for AWS SNS Mobile Push Notifications

Comparison with GCM/FCM

Benefits of AWS SNS Mobile Push Notifications

Conclusion

Overview

Tech Stack

Prerequisites

Project Structure

Example: zipkin.tf

Example: sentry.tf

Configuration

Step 1: Create a Kind Cluster

Step 2: Set Up the Ingress NGINX Controller

Step 3: Initialize Terraform

Step 4: Apply the Terraform Configuration

Step 5: Verify the Deployment

Step 6: Access Sentry and Zipkin

Additional Tools

Cleanup

Conclusion

1. VPC Module

2. EKS Module

Project Directory Structure

Root Configuration Files Overview

Backend Configuration (backend.tf)

Main Configuration (main.tf)

VPC Module

EKS Module

Outputs Configuration (outputs.tf)

Variable Definitions (terraform.tfvars)

Variable Declarations (variables.tf)

Conclusion

Example: `zipkin.tf`

Example: `sentry.tf`