Helm Chart Automation
DevOps IaC Part 2 — Day 11
Package and release ingress controllers, cert-manager, and services via the HashiCorp Helm provider
While custom applications are frequently defined with the kubernetes provider, third-party platform infrastructure (Ingress Controllers, Redis caches, Prometheus monitoring, Cert-Manager) is packaged as Helm charts. Managing Helm releases through Terraform via the HashiCorp Helm Provider combines the breadth of the Kubernetes packaging ecosystem with the state locking, dependency tracking, and parameterization of Terraform IaC.
An interactive 20 min video walkthrough for Day 11 is currently in production. Follow the step-by-step interactive playbook below!
The official reference codebase for Day 11 is hosted in the repository. Clone the repository and navigate to day-11-helm-automation to run the working solution.
git clone https://github.com/777abhi/devops-terraform-roadmap.git
cd devops-terraform-roadmap/day-11-helm-automationArchitecture: Helm Provider vs Standalone Helm CLI
Understand how Terraform tracks Helm release metadata and provides atomic rollbacks.
Examine how the Helm provider interacts directly with the Kubernetes API to manage release secrets.
Helm Provider Operational Flow: 1. Provider config reads cluster kubeconfig / token. 2. Terraform computes diff between declared 'set' / 'values' and existing release state. 3. If delta detected: - Queries Helm repository for chart version. - Generates templated manifests. - Executes atomic upgrade against cluster API. - If health check fails within timeout -> triggers automated rollback.
Declaring helm_release in HCL
Configure provider and declare an Ingress-Nginx or Bitnami Redis release with custom values.
Declare provider requirements and cluster authentication.
# versions.tf
terraform {
required_version = ">= 1.5.0"
required_providers {
helm = {
source = "hashicorp/helm"
version = "~> 2.13.0"
}
}
}
provider "helm" {
kubernetes {
config_path = "~/.kube/config"
config_context = "kind-devops-lab-cluster"
}
}Provision Ingress Nginx Controller with atomic guarantees and values overrides.
# main.tf
resource "helm_release" "ingress_nginx" {
name = "ingress-nginx"
repository = "https://kubernetes.github.io/ingress-nginx"
chart = "ingress-nginx"
version = "4.10.0"
namespace = "ingress-system"
create_namespace = true
# Guarantees rollback if deployment does not become ready
atomic = true
timeout = 300
set {
name = "controller.service.type"
value = "NodePort"
}
set {
name = "controller.service.nodePorts.http"
value = "30080"
}
set {
name = "controller.replicaCount"
value = "2"
}
}
output "release_status" {
value = helm_release.ingress_nginx.status
description = "Status of the deployed Helm release"
}Execution & Release History Verification
Deploy the Helm release via Terraform and audit installed objects using kubectl.
Run terraform apply to download the chart and orchestrate the release.
cd /Users/abhinavsharma/Downloads/devops-terraform-roadmap/day-11-helm-automation
terraform init
terraform apply -auto-approveConfirm that pods and services were created in the ingress-system namespace.
kubectl get pods -n ingress-system
kubectl get svc -n ingress-systemProduction Governance & CRD Lifecycle
Navigate Helm version pinning, values file structure, and Custom Resource Definitions.
1. Mandatory Chart Version Pinning: Always pin the exact version attribute in helm_release. Never omit the version or use latest, as upstream breaking changes could destabilize production on the next pipeline trigger.
2. CRD Upgrades: Helm does not automatically upgrade Custom Resource Definitions (CRDs) across chart version bumps by design. For charts with complex CRDs (like Cert-Manager or Prometheus Operator), manage CRDs with standalone kubernetes_manifest resources or dedicated pre-install hooks.
- Understood the role of Helm charts in provisioning third-party platform infrastructure.
- Configured the official HashiCorp Helm provider against the local Kind cluster.
- Declared helm_release with explicit chart version pinning and parameter overrides.
- Enforced atomic deployment guarantees (atomic = true) and timeout thresholds.
- Verified deployed pods and services in dedicated namespaces via kubectl.