Frequently Asked Questions (FAQs)

How does it work?

The solution leverages Terraform and Helm to create a Kubernetes Custom Resource Definition (CRD) object, watched and understood by the Appvia Terraform Controller. This then triggers a workflow that applies a referenced Terraform module. We have aligned these CRD objects to cloud resources that Kubernetes workloads often depend on, and published them to artifacthub.io. You can either choose one of them or create your own package.

What are the benefits to this approach?

1. Clear separation of concerns for infrastructure operators and application developers
2. Developer self-service of consumable cloud resource packages with minimal user input
3. Leverages Helm as a package manager and its rich ecosystem
4. Leverages Terraform as the de facto tool for infrastructure provisioning

What if my cloud resource depends on another?

It is common for a cloud resource to depend on other cloud resources as input arguments when being provisioned. These arguments or cloud resource attributes can be retrieved by querying the cloud API or Terraform state.

Here are some possible ways to address this if you are creating your own package:

1. Create a Terraform module that creates and/or references the dependent cloud resources.
2. Create a Terraform module based on organisational boundaries that accept user inputs and/or sensible default values as arguments.
3. Create a Helm Chart that uses the Helm Lookup function to query the Kubernetes API for Terraform outputs generated by dependent Helm Charts stored in a Kubernetes secret.

Each appvia-community package represents a single cloud resource with some appropriate default parameters. This follows the second option above, and allows consumers to add minimal input.

How is the state managed?

Terraform includes a built-in selection of backends that define where Terraform's state snapshots are stored. The Terraform Controller defaults to using the Kubernetes backend for storing and managing state.

Some key points around the usage of the Kubernetes backend:

• It supports state locking, which means that Terraform will lock the state for all operations that write state.
• It is limited by Kubernetes' maximum secret size of 1MB, which must be considered when creating larger Terraform modules.
• The Terraform Controller stores sensitive data as plaintext within Kubernetes secrets.

How does this compare to other similar tools?

Key areas	Terranetes	Kubeform	Crossplane
Architecture	The Terraform Controller component has a single controller and single CRD referencing a Terraform module	One controller per cloud provider and one CRD per cloud resource	One controller per cloud provider and one CRD per cloud resource
State management	Kubernetes etcd store	Kubernetes etcd store	Kubernetes etcd store
Ease of use	Simplified consumption of cloud resources with minimal user input	Steep learning curve to understand cloud infrastructure and multiple CRDs	Steep learning curve of cloud infrastructure, multiple CRDs and concepts