Hey, thanks for reaching out. Terraform cloud is something I very much want to support. However, I don't think it is currently possible. There are three potential blockers to investigate (that I know of):

1. Kubestack uses the terraform-provider-kustomize to integrate the cluster services into the Terraform plan/apply lifecycle. The provider is not available in the Terrafom registry yet. The recently announced support for community providers should solve this, but unfortunately I haven't been lucky enough to get access to the beta. So I wasn't able to work on this yet.

2. The GKE module currently relies on a external data source that runs a gcloud CLI command to determine the current IAM account and ensure it has cluster-admin ClusterRole. This may or may not work in Terraform cloud (untested).

3. Terraform cloud, last time I checked, did not allow tags to trigger a run. Kubestack's GitOps flow relies on tags to promote a change from the ops environment to the critical apps environment.

I'll leave this issue open to track the requirements, so that support for Terraform cloud can be tested, as soon as the community provider feature is available.

from terraform-kubestack.

Thank you for the prompt response

1. If I am honest kustomize is lesser of my concerns. I was able to compile it and TF Cloud picked it up from terraform.d/plugins/linux_amd64/ folder no problem. Where I am stuck is switching between ops and apps workspaces as TF Cloud always return "default" is something like terraform.workspace is used in the code. How can I work around it?
2. We are on AWS so GKE is not relevant but point is valid for wider audience I guess;
3. Is it not possible to use Run Triggers? Not the same as tag trigger deployment though.

It is basically hardcoded here - https://github.com/kbst/terraform-kubestack/blob/master/aws/cluster/configuration.tf:

locals {

apps config and merged ops config

workspaces = {
apps = var.configuration["apps"]
ops = merge(var.configuration["apps"], var.configuration["ops"])
}

TF Cloud returns default so it errors:

Error: Invalid index

on .terraform/modules/eks_zero/aws/cluster/configuration.tf line 9, in locals:
9: cfg = local.workspaces[terraform.workspace]
|----------------
| local.workspaces is object with 2 attributes
| terraform.workspace is "default"

The given key does not identify an element in this collection value.

from terraform-kubestack.

I think it's a bit confusing how Terraform cloud workspaces and terraform cli workspaces have the same name but aren't quite the same thing.

But, a way I was able to make it work in a different context (application deployment) is to have workspaces in Terraform cloud with a prefix and then configuring the remote backend accordingly.

Here's the corresponding HCL. This example was for a hackathon and I only used Terraform cloud to store the state. But if you have the provider in the repository it should also work when you have workspaces that run remotely.

Here's the documentation regarding this prefix behavior, were you use a prefix when creating the cloud workspace, but terraform.workspace will be the value without the prefix. So for Kubestack you would probably need to call the workspaces in Terraform cloud myprefix-ops and myprefix-apps, then configure the remote backend with myprefix as the prefix.

I hope this helps. Let me know how it goes.

from terraform-kubestack.