0.12.24
provider "azurerm" {
version = "=2.2.0"
skip_provider_registration = true
features {}
}
provider "helm" {
}
resource "azurerm_kubernetes_cluster" "aks" {
...
}
resource "helm_release" "prometheus-operator" {
...
}
I would like to be able to deploy the Helm release on the AKS cluster, i.e. something like
resource "helm_release" "prometheus-operator" {
kube_config = azurerm_kubernetes_cluster.aks.kube_config_raw
}
I need to provide Kubernetes credentials in the provider, or find a workaround involving a custom script or local file resource
This is interesting. On one hand, there is this Hashicorp blog post suggesting you can create a cluster and then configure kubernetes provider based on the created resource. Translating that to the helm provider:
provider "helm" {
kubernetes {
host = "${azurerm_kubernetes_cluster.main.kube_config.0.host}"
username = "${azurerm_kubernetes_cluster.main.kube_config.0.username}"
password = "${azurerm_kubernetes_cluster.main.kube_config.0.password}"
client_certificate = "${base64decode(azurerm_kubernetes_cluster.main.kube_config.0.client_certificate)}"
client_key = "${base64decode(azurerm_kubernetes_cluster.main.kube_config.0.client_key)}"
cluster_ca_certificate = "${base64decode(azurerm_kubernetes_cluster.main.kube_config.0.cluster_ca_certificate)}"
}
}
But then, the documentation is quite adamant in that you should not do it:
IMPORTANT WARNING _When using interpolation to pass credentials to the Kubernetes provider from other resources, these resources SHOULD NOT be created in the same apply operation where Kubernetes provider resources are also used. This will lead to intermittent and unpredictable errors which are hard to debug and diagnose. The root issue lies with the order in which Terraform itself evaluates the provider blocks vs. actual resources._
and so the recommended way, if I understood the docs correctly, is to create the AKS and then install kubernetes resources & helm charts on it in two separate TF configurations, passing the AKS config between them with output / data .
So is the the former blog post showing the wrong way to do it or do I misinterpret sth here?
@michalmela the documentation is our current recommendation of how to achieve this.
I'm going to lock this issue because it has been closed for _30 days_ ⏳. This helps our maintainers find and focus on the active issues.
If you feel this issue should be reopened, we encourage creating a new issue linking back to this one for added context. If you feel I made an error 🤖 🙉 , please reach out to my human friends 👉 [email protected]. Thanks!
Most helpful comment
This is interesting. On one hand, there is this Hashicorp blog post suggesting you can create a cluster and then configure kubernetes provider based on the created resource. Translating that to the
helmprovider:But then, the documentation is quite adamant in that you should not do it:
and so the recommended way, if I understood the docs correctly, is to create the AKS and then install kubernetes resources & helm charts on it in two separate TF configurations, passing the AKS config between them with
output/data.So is the the former blog post showing the wrong way to do it or do I misinterpret sth here?