Terraform Helm Provider

Once an issue is reported on GitHub, it follows this lifecycle:

1. Verification & Categorization: A collaborator verifies the issue and applies labels such as bug, enhancement, documentation, or question.
2. Triage: The issue is assessed for criticality and work effort (size estimate). Once triaged, it is labeled as acknowledged.
3. Backlog: The issue is queued for development. Fixes are linked to the issue number in the relevant commit messages.
4. Resolution: The issue is closed once addressed, or closed if it is tracked elsewhere or deemed non-actionable.

The helm_template data source allows you to render Helm chart templates locally without installing them into a cluster. It mimics the functionality of the helm template command. This is useful for inspecting manifests, validating templates, or exporting rendered YAML files to local storage using other Terraform resources (like local_file).

To use it, you must provide a name (release name) and the chart (name or path). You can also specify a repository, version, and various set blocks to pass values into the templates.

data "helm_template" "example" {
  name       = "my-release"
  chart      = "my-chart"
  repository = "https://charts.example.com"
  version    = "1.2.3"
}

Entries should be user-facing and formatted using specific code block tags to categorize the change. Use the following syntax: ```release-note:<type> followed by the component and description.

Available types include:

• improvement
• feature
• bug

You can include multiple entries in a single file by separating them with distinct code blocks.

server: Add new option for configs

plugin/nomad: New feature integration

plugin/docker: Fix broken code

The Helm provider allows you to install and manage Helm Charts in your Kubernetes cluster using Terraform.

To use the provider, configure the helm provider block with your Kubernetes configuration (such as config_path) and use the helm_release resource to define the chart, repository, and values to set.

provider "helm" {
  kubernetes = {
    config_path = "~/.kube/config"
  }
}

resource "helm_release" "nginx_ingress" {
  name       = "nginx-ingress-controller"

  repository = "oci://registry-1.docker.io/bitnamicharts"
  chart      = "nginx-ingress-controller"

  set = [
    {
    name  = "service.type"
    value = "ClusterIP"
    }
  ]
}

After the Kubernetes cluster is running, you must install Helm. The repository provides a shell script install-helm-via-docker.sh that uses Docker to simplify the installation process.

When running the script, ensure you specify the correct path to your kubeconfig file using the KUBE_DIR environment variable. The following example assumes the kubeconfig is stored in ./gke/kubedir.

KUBE_DIR=./gke/kubedir HELM_VERSION=2.13.0 HELM_HOME=./helm-home HYPERKUBE_VERSION=v1.11.8 ./install-helm-via-docker.sh

When upgrading to v2.0.0, the way Kubernetes access is configured in the provider block has changed to encourage explicit configuration and prevent accidental application to the wrong cluster.

Key changes:

• The load_config_file attribute is removed.
• The KUBECONFIG environment variable is no longer supported; use KUBE_CONFIG_PATH instead.
• The config_path attribute no longer defaults to ~/.kube/config and must be set explicitly.

Note: If running Terraform inside a Kubernetes cluster, no provider configuration is necessary as the provider will automatically detect the service account token.

The Helm Provider uses go-changelog to automate changelog generation. To install the necessary command-line tools, use the following go install commands:

go install github.com/hashicorp/go-changelog/cmd/changelog-build
go install github.com/hashicorp/go-changelog/cmd/changelog-entry

The set_string block in the helm_release resource has been removed. It has been replaced by the standard set block, which now includes a type attribute. This allows you to explicitly define the type of a value, which is useful for ambiguous strings (e.g., strings that look like numbers, true, or false).

resource "helm_release" "redis" {
  name       = "redis"
  repository = "https://charts.bitnami.com/bitnami"
  chart      = "redis"

  set {
    name  = "test.value"
    value = "123456"
    type  = "string"
  }
}

The helm_repository data source has been removed because it performed stateful filesystem operations (similar to helm repo add) which is inconsistent with the purpose of data sources.

To achieve the same result, configure repository information directly within the helm_release resource using the repository attribute. Alternatively, you can continue to use repositories that were added via the helm repo add CLI command before running Terraform.

resource "helm_release" "redis" {
  name       = "redis"
  repository = "https://charts.bitnami.com/bitnami"
  chart      = "redis"
}