terraform-provider-minikube

terraform-provider-minikube copied to clipboard

terragrunt is an open source tool created by GruntWorks.io, and it's used as a wrapper to terraform where it provides features that terraform cannot provide. The goal of the documentation is to show another way to use the minikube, kubernetes, and helm providers together because it doesn't replace terraform usage; it extends terraform usage.

This is something that I would like to document for the open source community as I'm not really sure if anyone knows this is possible because I figured it out on my own using terraform-provider-minikube.

There are a lot of advantages:

• terragrunt has dedicated support for opentofu, which fits with @scott-the-programmer and GruntWorks.io's goals to bridge the industry licensing issue that's causing the migration (see #120)
• The terraform project is downloaded using git, which encourages caching and reproducible init / plan / apply sequences through GitOps
• You can use a common configuration for all terraform-provider-minikube usage, which keeps your HCL 100% dry while providing 100% control over common settings between different drivers (docker, kvm2, qemu2, ...). This has a lot to do with how the project's structure is designed, which I would like to cover.
• You can template the values within providers block, meaning that kubernetes_version from terraform-provider-minikube can be templated:

locals {
  kubernetes_version = "v1.28.3"
}

generate "provider" {
  path      = "provider.tf"
  if_exists = "overwrite"
  contents  = <<EOF
provider "minikube" {
  kubernetes_version = "${local.kubernetes_version}"
}
EOF
}

• You can template the values with the remote_state block in a similar way:

remote_state {
  backend = "local"
  generate = {
    path      = "backend.tf"
    if_exists = "overwrite"
  }
  config = {
    path = "${get_parent_terragrunt_dir()}/${path_relative_to_include()}/terraform.tfstate"
  }
}

@scott-the-programmer Would you assign this one to me? How do you think this information should manifest? Should it be docs only? Should it be a repository? I already have a cookiecutter template that I'm about to tag and release in the coming weeks which will provide all necessary structure and design for using terraform-provider-minikube with terragrunt.

I think it would be best to document the minimum necessary design to use terragrunt, terraform-provider-minikube, terraform-provider-helm, and terraform-provider-kubernetes together while linking to the cookiecutter template on GitHub. The cookiecutter template I've created allows for initializing a "production-ready" structure and more advanced practices that would make the example too complex for terraform-provider-minikube newcomers.

Maybe making two sections in the docs:

• terraform usage
• terragrunt usage

And both show kubernetes and helm usage.

Yep, sounds good to me!

I haven't forgotten about this; I'm going to get to this sometime this week.

Worked on this tonight; I'll add final edits tomorrow. The example works as expected, so only edits to docs should be needed to complete this. I changed the scope of the ticket to be simpler because I think it'll be more helpful.