weekly.tf #36 - helm and k8s v2 providers

The Kubernetes and Helm providers have both had a major upgrade. As you would expect from a semver major version bump, there are a lot of breaking changes.

First, authentication is no longer allowed via the KUBECONFIG environment variable. Apparently I am not the only one who has accidentally modified the wrong cluster due to KUBECONFIG misconfiguration. The environment variable and load_config_file provider parameter are replaced by KUBE_CONFIG_PATH and KUBE_CONFIG_PATHS.

Second, support for Terraform 0.11 and Helm v2 have been dropped.

Third, the releases include a bunch of small changes to better align the provider API with that of the upstream projects. For example automount_service_account_token is now default to true.

For more details, and upgrading guidance check oug the changelogs for Helm and Kubernetes as well as v2 upgrade guides (Helm, Kubernetes).

Vim vs Emacs, tabs vs spaces, mono-repos vs multi-repos.

The debate will never end because in each of these cases both sides are right. At least, they are right for some set of the problem space.

Personally I err on the side of monorepos, both for infrastructure code and non. This article does a good job of pointing out the challenges with using a monorepo structure for Terraform. Those problems are real, but with the right toolchain are manageable. I built a whole project at my current day job to manage terraform monorepos (warning - not well documented project).

It is worth noting that we don't take this to extremes - we have a monorepo for each separable part of our technical organization. And then a bunch of shared modules (also in a monorepo).

A new player in the infra-as-code delivery space? Anyone have experience with this product?

I am not sure I fully understand this project (please reply if you see anything wrong here), but...

It appears that etok enables you to use kubernetes to manage terraform workspaces, making use of kubernetes RBAC, the kubernetes backend for state management, secrets management, etc.

I guess this makes sense if your team is already all-in on kubernetes and want to leverage that investment. If there is another value proposition, I am missing it, but would love to hear about it.

From scalr- data on the 20 most popular providers. Interesting notes–

  • Null is #2 - lots of hacks

  • If GCP didn't have two providers, they would be ahead of Azure.

  • All the providers are "official", meaning they are either developed by Hashicorp or as part of their partner program. I guess that is not too surprising, but I was hoping one at least one indie provider would make it.