DEV Community: Amit Chaturvedi

Terraform Atlantis: GitOps-Driven Infrastructure Management

Amit Chaturvedi — Mon, 28 Jul 2025 12:54:30 +0000

Introduction
Infrastructure as Code (IaC) has revolutionized how we manage cloud infrastructure. Terraform, being one of the most popular IaC tools, allows declarative, repeatable, and version-controlled infrastructure provisioning. However, as teams grow, managing Terraform execution securely and collaboratively becomes challenging.

Atlantis solves this by bringing Terraform into your GitOps workflow. In this post, we’ll explore what Atlantis is, how it works, why it’s useful, and how to set it up.

What is Atlantis?
Atlantis is an open-source tool that automates Terraform workflows via pull requests. It listens to Git events (PRs, pushes, etc.) and triggers Terraform commands such as plan and apply automatically in response to PR comments.

Core Features:

Git-based Terraform automation
PR-based infrastructure change visibility
Secure plan and apply in CI/CD pipelines
Team collaboration with role-based approvals_

How Atlantis Works

PR Creation: A developer creates a pull request with Terraform changes.
Atlantis Webhook Triggered: Atlantis detects the PR via a Git webhook.
Terraform Plan: Atlantis runs terraform plan and comments the output on the PR.
Approval: A reviewer comments atlantis apply once satisfied with the plan.
Terraform Apply: Atlantis applies the changes using terraform apply.

Prerequisite

Storage (I am Using Longhorn)
MINIO (Object Storage)
Kubernetes
Atlantis (Open-source tool used to automate Terraform workflows)
Istio/Ingress (For Exposing Atlantis)
Gitlab
AWS Free Tier

** Generate Random Token**

head -c 32 /dev/urandom | base64

Create Secret for Minio

apiVersion: v1
kind: Secret
metadata:
  name: minio-credentials
type: Opaque
stringData:
  access_key: <access_key>
  secret_key: <access_secret>

# kubectl apply -f minio.yml

Create values.yml

environmentSecrets:
  # MinIO Credentials for remote backend
  - name: MINIO_ACCESS_KEY_ID
    secretKeyRef:
        name: minio-credentials
        key: access_key
  - name: MINIO_SECRET_ACCESS_KEY
    secretKeyRef:
        name: minio-credentials
        key: secret_key

gitlab:
  user: "champ25"
  token: "<gitlab-token>"
  secret: "<random-secret>"
  hostname: "gitlab.com"
aws:
   credentials: |
     [default]
     aws_access_key_id=<AWS ACCESS KEY>
     aws_secret_access_key=<AWS SECRET KEY>
   directory: "/home/atlantis/.aws"
repoConfig: |-                                     
    - id: gitlab.com/infrastructure149/*
      apply_requirements: [approved, mergeable]
      import_requirements: [approved, mergeable]
      workflow: default
      allowed_overrides: [workflow, apply_requirements]
      allow_custom_workflows: true
      workflows:
         default:
            plan:
             steps:
              - run: |
                  terraform init -reconfigure\
                    -input=false \
                    -backend-config="bucket=terraform-statefile" \
                    -backend-config="key=envs/dev/terraform.tfstate" \
                    -backend-config="region=us-east-1" \
                    -backend-config="access_key=${MINIO_ACCESS_KEY_ID}" \
                    -backend-config="secret_key=${MINIO_SECRET_ACCESS_KEY}" \
                    -backend-config="skip_credentials_validation=true" \
                    -backend-config="skip_metadata_api_check=true" \
                    -backend-config="force_path_style=true" \
                    -backend-config="skip_requesting_account_id=true" \
                    -backend-config="force_path_style=true" \
                    -backend-config="endpoint=https://minioapi.kubeopscloud.uk"
                  terraform plan -input=false

            apply:
             steps:
               - run: |
                   terraform apply -input=false --auto-approve

Install Atlantis

helm repo add runatlantis https://runatlantis.github.io/helm-charts
helm install atlantis runatlantis/atlantis \
  --namespace atlantis -f values.yaml \
  --create-namespace

Expose via Istio to access from Gitlab

root@master:~# kubectl exec -ti atlantis-0 -n atlantis -- printenv | grep -i webhook
ATLANTIS_GITLAB_WEBHOOK_SECRET=0adfa526cfdgdgsgsdhsdgtewsgsfgsdhshgsgsd

Copy the Webhook Secret to Use in Gitlab

Login To Gitlab
Create A Project : VPC Creation
Copy The Terraform Code to VPC Creation Project

Click On Setting --> Click Webhook

Note : Copy the Webhook Token

Create A Branch and Create MR
_As soon as we create ME, Atlatis Webhook will get triggered
_

Click On Show Output and we will see the plan

If Plan Looks Good, type atlantis apply -d . in commit message

Wait For Some Time and you Will See Output

Click On Show Output

We have Sucessfully Integrated Atlantis to create workflow with Terraform using Gitlab

Verify state file in Minio

Successfully state file updated in Minio Storage
Conclusion
Atlantis brings safety, visibility, and collaboration to Terraform workflows by integrating with Git. With pull request automation, it enables true GitOps-style infrastructure management — ensuring all changes are reviewed, tracked, and auditable.

Automate your Infrastructure on AWS using Terraform Controller and FluxCD

Amit Chaturvedi — Sun, 11 May 2025 11:07:32 +0000

Introduction

In the age of cloud-native operations, infrastructure automation is no longer optional—it's essential. While tools like Terraform have long been the standard for Infrastructure as Code (IaC), integrating them into a GitOps workflow brings unprecedented control, traceability, and scalability. In this blog, we'll explore how to automate your AWS infrastructure using Terraform Controller (from the Crossplane ecosystem) and FluxCD, leveraging Git as the single source of truth.

Why Terraform Controller + FluxCD?

Terraform Controller: A Kubernetes controller that allows you to manage Terraform executions through Custom Resource Definitions (CRDs).
FluxCD: A GitOps toolkit that automates Kubernetes deployments by syncing Git repositories with clusters.
GitOps Benefits: Version control, audit trails, CI/CD integration, and reduced configuration drift.

Prerequisites
Before you begin, ensure you have the following:

A Kubernetes cluster (EKS,AKS,GKS,On-Prem or local like KinD)
AWS credentials with necessary IAM permissions
kubectl, flux, and terraform controller installed
A Git repository for storing Terraform manifests

Step-by-Step Guide

Install Kind Cluster

#cat config.yaml 
kind: Cluster
apiVersion: kind.x-k8s.io/v1alpha4
nodes:
- role: control-plane
- role: worker
- role: worker

#kind create cluster --config=config.yaml

Install flux cli

#brew install fluxcd/tap/flux

BootStrap fluxcd to install flux-system with gitrepo infra-demo

#flux bootstrap gitlab   --token-auth   --owner=infra-demo2   --repository=flux-system   --branch=main   --path=clusters/dev

A namespace name flux-system will be created with required components

#kubectl get ns
#kubectl get all -n flux-system

Lets Install Terraform Controller

#helm repo add tofu-controller https://flux-iac.github.io/tofu-controller

#helm upgrade -i tofu-controller tofu-controller/tf-controller \
    --namespace flux-system

Lets Verify Controller in flux-system

#kubectl get pods -n flux-system | grep tf

Create infrastructure project inside infra-demo repo and map Source list and Kustamization to infra-demo repository to managed by Flux-cd

#cat infra-demo.yaml
apiVersion: source.toolkit.fluxcd.io/v1beta1
kind: GitRepository
metadata:
  name: vpc-creation
  namespace: flux-system
spec:
  interval: 30s
  url: https://gitlab.com/infra-demo2/infrastructure.git
  ref:
    branch: main
  secretRef:
    name: flux-system
---
apiVersion: kustomize.toolkit.fluxcd.io/v1beta2
kind: Kustomization
metadata:
  name: vpc-creation
  namespace: flux-system
spec:
  prune: true
  interval: 2m
  path: ./      
  sourceRef:
    kind: GitRepository
    name: vpc-creation
  timeout: 3m
  healthChecks:
    - apiVersion: infra.contrib.fluxcd.io/v1alpha1
      kind: Terraform
      name: vpc-creation
      namespace: flux-system

Lets Create terraform Code in Infrastructure Project to deploy VPC in AWS Account

#cat main.tf
resource "aws_vpc" "main" {
  cidr_block           = var.vpc_cidr
  enable_dns_support   = true
  enable_dns_hostnames = true
  tags = {
    Name = "${var.project}-vpc"
  }
}

resource "aws_subnet" "public" {
  count             = length(var.public_subnets)
  vpc_id            = aws_vpc.main.id
  cidr_block        = var.public_subnets[count.index]
  availability_zone = element(var.availability_zones, count.index)
  map_public_ip_on_launch = true
  tags = {
    Name = "${var.project}-public-subnet-${count.index + 1}"
  }
}

resource "aws_internet_gateway" "igw" {
  vpc_id = aws_vpc.main.id
  tags = {
    Name = "${var.project}-igw"
  }
}

resource "aws_route_table" "public" {
  vpc_id = aws_vpc.main.id
  tags = {
    Name = "${var.project}-public-rt"
  }
}

resource "aws_route" "internet_access" {
  route_table_id         = aws_route_table.public.id
  destination_cidr_block = "0.0.0.0/0"
  gateway_id             = aws_internet_gateway.igw.id
}

resource "aws_route_table_association" "public_assoc" {
  count          = length(var.public_subnets)
  subnet_id      = aws_subnet.public[count.index].id
  route_table_id = aws_route_table.public.id
}

#cat outputs.tf
output "vpc_id" {
  value = aws_vpc.main.id
}

output "public_subnet_ids" {
  value = aws_subnet.public[*].id
}

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

variable "project" {
  default = "demo"
}

variable "vpc_cidr" {
  default = "10.0.0.0/16"
}

variable "public_subnets" {
  default = ["10.0.1.0/24", "10.0.2.0/24"]
}

variable "availability_zones" {
  default = ["us-east-1a", "us-east-1b"]
}

Note: Not Recommended

#cat provider.tf
provider "aws" {
  region     = var.aws_region
  access_key = "XXXXXXXXXX"
  secret_key = "YYYYYYYYYYYYYY"
}

Now Create Terraform Controller to Deploy Terraform Code

#cat terraform.yaml
apiVersion: infra.contrib.fluxcd.io/v1alpha1
kind: Terraform
metadata:
  name: vpc-creation
  namespace: flux-system
spec:
  interval: 1m
  approvePlan: auto
  path: ./                     
  sourceRef:
    kind: GitRepository
    name: vpc-creation
    namespace: flux-system

Now the Repo will look Like

Now Lets Deploy infrademo.yaml to Map Repo to get managed by flux-system

#flux get sources all | grep vpc-creation

#flux get kustomization | grep vpc-creation

# kubectl apply -f infrademo.yaml

#flux get sources all | grep vpc-creation

#flux get sources all | grep vpc-creation

Once we Deploy it Terraform Controller is going to Create a runner with name of vpc-creation-tf-runner which is going to deploy the resources in AWS

Lets verify the log of the runner

kubectl logs vpc-creation-tf-runner -n flus-system -f

Congratulations: We have deployed our resource successfully

Lets Verify from the AWS Portal

Automate your Deployments on Kubernetes using FluxCD

Amit Chaturvedi — Thu, 08 May 2025 19:10:31 +0000

In the ever-evolving world of Kubernetes, automation and consistency are key. Enter FluxCD, a powerful GitOps tool designed to simplify and supercharge your deployment pipelines. When paired with custom Kubernetes controllers, Flux can orchestrate even the most complex deployment flows. Let’s dive into how you can use FluxCD alongside Kubernetes controllers to build a robust, automated, and Git-driven infrastructure

What Is FluxCD?

FluxCD is a CNCF-graduated open-source GitOps tool that automatically synchronizes the desired state of your Kubernetes cluster with configuration stored in Git repositories. It continuously monitors the Git repo and reconciles the live state of Kubernetes resources with what’s defined in Git.

Why Combine FluxCD with Kubernetes Controllers?

Kubernetes controllers are control loops that watch the state of your cluster and attempt to move the current state toward the desired state.

Key Components of FluxCD

Source Controller: Monitors Git repositories or Helm repositories.
Kustomize Controller: Applies manifests using Kustomize.
Helm Controller: Handles Helm releases.
Image Automation Controller: Watches image registries and updates manifests.
Notification Controller: Sends alerts or takes action based on events.

Prerequisite

Kubernetes Cluster Up and Running
Gitlab Repository
PAT Token
Deploy Token

Install the Flux CLI

curl -s https://fluxcd.io/install.sh | sudo bash
. <(flux completion bash)

Flux bootstrap for GitLab

The flux bootstrap gitlab command deploys the Flux controllers on a Kubernetes cluster and configures the controllers to sync the cluster state from a Gitlab repository. Besides installing the controllers, the bootstrap command pushes the Flux manifests to the Gitlab repository and configures Flux to update itself from Git.

After running the bootstrap command, any operation on the cluster (including Flux upgrades) can be done via Git push, without the need to connect to the Kubernetes cluster.

Create Deploy Token

Group Name -> Setting -> Repository -> Default Token -> Add Token

Create flux-system namespace

Bootstrap Command to Create flux-cd controller

flux bootstrap gitlab --token-auth --owner=<group-name> --repository=flux-systemtest --branch=main --path=clusters/dev

Verify the component in flux-system namespace

Verify the repository flux-systemtest must be created

Note

gotk-components.yaml file is a pre-generated manifest used by FluxCD to install its core components into your Kubernetes cluster.
gotk-sync.yaml is another key Flux file — it's the manifest that tells Flux where and how to sync your cluster state from Git.
kustomization.yaml is used to declare how to apply a specific folder of Kubernetes manifests from your Git repository. This file is read by the Flux kustomize-controller, and it tells Flux:
- Which directory in your repo to apply
- How often to check for changes
- Whether to prune deleted resources
- Whether to validate the manifests

Lets Deploy Application in Kubernetes using Flux-cd

Create a folder under flux-systemtest/clusters/dev/demo-1

Create Kubernetes related file under demo-1 dir and commit the code

deployment.yaml
service.yaml
namespace.yaml
dockerced.yaml

Note : As soon we commit the code it should create the resources

Access from the browser

Lets update the image version 2 in deployment file and see the new deployment and access from the browser

New Code Deployed once commit the code

Congratulations: Using FluxCD we have successfully automated the Kubernetes deployments.

Note: Next we will see how to automate infrastructure deployment using terraform and flux cd