Provision Terraform Resources

Set variables for resources

danger

BREAKING CHANGE: This is a breaking change of the v1alpha1 API.

Users who are upgrading from TF-controller <= 0.7.0 require updating varsFrom, from a single object:

  varsFrom:
    kind: ConfigMap
    name: cluster-config

to be an array of object, like this:

  varsFrom:
  - kind: ConfigMap
    name: cluster-config

---

vars and varsFrom

You can pass variables to Terraform using the vars and varsFrom fields.

Inline variables can be set using vars. The varsFrom field accepts a list of ConfigMaps / Secrets. You may use the varsKeys property of varsFrom to select specific keys from the input or omit this field to select all keys from the input source.

Note that in the case of the same variable key being passed multiple times, the controller will use the lattermost instance of the key passed to varsFrom.

apiVersion: infra.contrib.fluxcd.io/v1alpha1
kind: Terraform
metadata:
  name: helloworld
  namespace: flux-system
spec:
  approvePlan: auto
  interval: 1m
  path: ./
  sourceRef:
    kind: GitRepository
    name: helloworld
    namespace: flux-system
  vars:
  - name: region
    value: us-east-1
  - name: env
    value: dev
  - name: instanceType
    value: t3-small
  varsFrom:
  - kind: ConfigMap
    name: cluster-config
    varsKeys:
    - nodeCount
    - instanceType
  - kind: Secret
    name: cluster-creds

Variable value as HCL

The vars field supports HCL string, number, bool, object and list types. For example, the following variable can be populated using the accompanying Terraform spec:

variable "cluster_spec" {
  type = object({
      region     = string
      env        = string
      node_count = number
      public     = bool
  })
}

apiVersion: infra.contrib.fluxcd.io/v1alpha1
kind: Terraform
metadata:
  name: helloworld
  namespace: flux-system
spec:
  approvePlan: auto
  interval: 1m
  path: ./
  sourceRef:
    kind: GitRepository
    name: helloworld
    namespace: flux-system
  vars:
  - name: cluster_spec
    value:
      region: us-east-1
      env: dev
      node_count: 10
      public: false

Auto approve resources

To provision resources with TF-controller, you need to create a Terraform object and a Flux source object, such as a GitRepository or OCIRepository object.

Create a Terraform object

The Terraform object is a Kubernetes custom resource definition (CRD) object. It is the core object of TF-controller.

It defines the Terraform module, the backend configuration, and the GitOps automation mode.

The Terraform module is a Terraform configuration that can be used to provision resources. It can be placed inside a Git repository, or packaged as an OCI image in an OCI registry.

The backend configuration is the configuration for the Terraform backend to be used to store the Terraform state. It is optional. If not specified, the Kubernetes backend will be used by default.

GitOps automation mode

the GitOps automation mode is the GitOps automation mode to be used to run the Terraform module. It is optional. If not specified, the "plan-and-manually-apply" mode will be used by default. In this example, we use the "auto-apply" mode.

The following is an example of a Terraform object:

apiVersion: infra.contrib.fluxcd.io/v1alpha1
kind: Terraform
metadata:
  name: helloworld
spec:
  path: ./helloworld
  interval: 10m
  approvePlan: auto
  sourceRef:
    kind: GitRepository
    name: helloworld

Manually apply resources

Assume that you have a GitRepository object named helloworld pointing to a Git repository, and you want to plan and apply the Terraform resources under ./ of that Git repo.

For the plan & manual approval workflow, please start by either setting .spec.approvePlan to be the blank value, or omitting the field.

apiVersion: infra.contrib.fluxcd.io/v1alpha1
kind: Terraform
metadata:
  name: helloworld
  namespace: flux-system
spec:
  approvePlan: "" # or you can omit this field
  interval: 1m
  path: ./
  sourceRef:
    kind: GitRepository
    name: helloworld
    namespace: flux-system

Then after a reconciliation loop, the controller will generate a plan, and tell you how to use field .spec.approvePlan to approve the plan. You can run the following command to obtain that message.

kubectl -n flux-system get tf/helloworld

After making change and push, it will apply the plan to create real resources.

apiVersion: infra.contrib.fluxcd.io/v1alpha1
kind: Terraform
metadata:
  name: hello-world
  namespace: flux-system
spec:
  approvePlan: plan-main-b8e362c206 # first 8 digits of a commit hash is enough
  interval: 1m
  path: ./
  sourceRef:
    kind: GitRepository
    name: helloworld
    namespace: flux-system

Destroying resources

The resources provisioned by a Terraform object are not destroyed by default, and the tfstate of that Terraform object still remains in the cluster.

It means that you are safe to delete the Terraform object in the cluster and re-create it. If you re-create a new Terraform object with the same name, namespace and workspace, it will continue to use the tfstate inside the cluster as the starting point to reconcile.

However, you may want to destroy provisioned resources when delete the Terraform object in many scenarios. To enable destroy resources on object deletion, set .spec.destroyResourcesOnDeletion to true.

~> WARNING: This feature will destroy your resources on the cloud if the Terraform object gets deleted. Please use it with cautions.

apiVersion: infra.contrib.fluxcd.io/v1alpha1
kind: Terraform
metadata:
  name: helloworld
  namespace: flux-system
spec:
  approvePlan: auto
  destroyResourcesOnDeletion: true
  interval: 1m
  path: ./
  sourceRef:
    kind: GitRepository
    name: helloworld
    namespace: flux-system