Terraform, Terragrunt for IaC and FluxCD for GitOps

This repository contains the Infrastructure as Code (IaC) using Terraform and Terragrunt, and implements GitOps practices using FluxCD for a simple counter application.

IaC - Terraform and Terragrunt

We use Terraform with Terragrunt to manage our AWS infrastructure. The main components include:

• EKS Cluster
• Modules (https://gitlab.com/devozs/infrastructure-modules)
  • VPC and Networking
  • IAM Roles and Policies
  • ECR Repository

Directory Structure

infrastructure/
├── dev/
│   ├── eks/
│   ├── vpc/
│   └── ecr/
├── modules/ (in a seperate repo)
│   ├── eks/
│   ├── vpc/
│   └── ecr/
└── terragrunt.hcl

References and Credits

In the development of this project, several external resources were invaluable:

Terraform and Terragrunt

For learning and implementing Terraform with Terragrunt, the following tutorial was extensively used:

• Title: "Terraform & Terragrunt for AWS Beginner Project Tutorial"
• Author: Anton Putra
• URL: https://www.youtube.com/watch?v=yduHaOj3XMg

This tutorial provided crucial insights into setting up and managing AWS infrastructure using Terraform and Terragrunt, which greatly influenced the structure and approach of this project.

Key Features

• Modular design for reusability
• Environment separation (dev, staging, prod)
• Remote state management using S3 backend
• IAM roles for EKS and ECR access

Usage

To apply changes:

cd infrastructure/dev
terragrunt run-all plan
terragrunt run-all apply

GitOps - FluxCD

We use FluxCD for continuous deployment and GitOps practices.

Components

• Flux Bootstrap
• Image Update Automation
• Kustomize for Kubernetes manifests

Key Features

• Automatic deployment of new container images
• Git repository as the single source of truth
• Kubernetes manifest management

Configuration

Flux is configured to watch the ECR repository for new images and automatically update the Kubernetes deployments.

CI/CD Pipeline

We use GitLab CI for continuous integration and deployment.

Pipeline Stages

1. Validate
2. Init
3. Plan
4. Apply
5. Destroy
6. Post-apply (Flux bootstrap)

Key Features

• Automatic Terraform plan and apply on changes to infrastructure code
• Manual approval step for apply stage
• Flux bootstrap after successful infrastructure updates

Configuration

The CI/CD pipeline is defined in .gitlab-ci.yml at the root of this repository.

Application Details

The counter application (in a separate repository) is a simple Python Flask app that:

• Counts POST and GET requests
• Displays the current count
• Shows the application version (to demonstrate live update)

The application is containerized and pushed to ECR, from where Flux picks up new versions for deployment.

Accessing the Application

After deployment, the application is accessible via the Contour ingress controller. The URL for accessing the application is:

http://a6c503949052c42ad8bcd686137bc100-40713477.eu-west-1.elb.amazonaws.com/counter

This URL is composed of the DNS name of the AWS Elastic Load Balancer created by the Contour ingress controller, followed by the '/counter' path.

Note: This URL may change if the Load Balancer is recreated. Always refer to the most recent ELB DNS name in your AWS console or infrastructure outputs.

Versioning

The application version is injected at build time and displayed on the web interface. This helps in identifying which version of the application is currently deployed.

Security Considerations

• EKS cluster uses IAM roles for service accounts (IRSA)
• Least privilege principle applied to IAM roles
• Network policies and security groups restrict access

Monitoring and Logging

Our application and infrastructure can be monitored through various methods:

Application Monitoring

• UI Counter Tracking: Monitor the increase in counters directly through the application's user interface. This provides a real-time view of application usage.

Image Updates

• Flux Image Policy: Use the following command to check the latest image update detected by Flux:

  flux get image policy
  

  This command shows which image versions Flux is aware of and which one it considers the latest.

Pod Information

• Kubernetes Pod Details: To get information about the currently running pod, including the image version in use, use the following kubectl command:

  kubectl describe pod -n counter-service <pod-name>
  

  Replace <pod-name> with the actual name of your pod. For example:

  kubectl describe pod -n counter-service counter-service-f5f75fc69-5wd2k
  

  This command provides detailed information about the pod, including which image version is currently deployed.

Future Enhancements and Notes

As we continue to develop and improve this project, we've identified several areas for future enhancements and some important notes:

Infrastructure and GitOps

• FluxCD as a Module: Implement FluxCD as an additional Terraform module instead of installing it within the CI pipeline. This would provide better management and versioning of the GitOps tooling.
• CI Pipeline Structure: Further refine the CI stages to create a more logical separation between the Terraform steps and Flux operations. This could improve pipeline clarity and maintainability.

CI/CD Improvements

• Merge Request Approvals: Implement additional merge request approvals and other GitLab approval processes to enhance code quality and security.