I’d been avoiding one issue all this time as I rebuilt my Kubernetes cluster: how to deploy a temporary branch of my services using the umbrella ApplicationSet. The declarative configuration made it impossible to deploy a different branch from the Argo CD UI (which would be awkward in any case, requiring the main branch to be deployed first). I wanted to specify the revision in Terraform, but there’s limited scope for dynamic elements in Kustomize. I got it working by using replacements again, but the Terraform Kustomize provider used an old version of the API which didn’t support replacements. I considered my options:

  1. Use Helm? I dislike working with Helm at this point, and I wasn’t sure whether I could merge the generated Argo CD manifests in one file with customizations (i.e. configuration) at runtime.
  2. Use Jsonnet? I’d have loved to, except that I’d have had to convert the YAML Argo CD manifests into JSON and commit those to the repository because parseYaml wasn’t available in the erstwhile release of go-jsonnet. Alternatively, I’d have needed a custom Argo CD image from a fork. It would have been a lot of effort for something quite brittle.

Fortunately, I realized I didn’t need to create the ApplicationSet through Kustomize at all! I could install Argo CD, generate the ApplicationSet using a template, then apply the custom manifest separately with the Kubernetes provider:

HCLresource "kubernetes_manifest" "shivjm_apps" {
  manifest = yamldecode(templatefile("./applications.yaml.tmpl", { revision = var.services_deployment_revision }))

  depends_on = [kustomization_resource.argocd0]
}

So simple in comparison. The only snag: the Kubernetes provider can’t apply a CRD and a resource using it together. alxndr13 suggested the kubectl provider in that discussion, which works with two rounds of terraform apply. It’s good enough as a workaround.

Next in series: (#17 in The Death and Rebirth of a Cluster)