The purpose of the "terrachain" format is to enable the execution of a sequence of terraform modules, feeding the output of one into the input for another. In particular this enables workflows where one module creates a Kubernetes cluster, and a later module deploys into that Kubernetes cluster.
Example of a configuration that terrachain can apply:
apiVersion: combinator.ml/v1alpha1 modules: # The modules get terraform-applied in order, with the outputs from each # being passed into the inputs to the next. It is up to the module authors to # ensure the inputs & outputs match up in such a way that they are mutually # compatible. - name: aks repo: https://github.com/combinator-ml/terraform-azure-kubernetes args: autoscaling: on - name: kfp repo: https://github.com/combinator-ml/terraform-k8s-kfp
Or a simpler example, just installing mlflow onto an existing Kubernetes cluster (assumes kubeconfig file in default location or
KUBECONFIG or similar env var is set):
apiVersion: combinator.ml/v1alpha1 modules: - name: mlflow repo: https://github.com/combinator-ml/terraform-k8s-mlflow
same init -f
As a special case, if a provider outputs a variable called
kubeconfig_contents, that file will be written to a temporary file and then the path to the temporary file passed to later modules in both
KUBE_CONFIG_PATH environment variables for convenience.
KUBE_CONFIG_PATH variable is set, and no previous module outputs a
kubeconfig_contents, terrachain will set it to
~/.kube/config to workaround this issue.
There are some sample terrachain configs at https://github.com/combinator-ml/stacks.