While using my new Macbook with the M1 chip, I often encounter issues in client projects when working with Terraform projects. Either some terraform providers have not adapted to the new darwin_arm64, yet, or the version of the used provider is pinned to an older version. In both cases, there is no pre-compiled binary for darwin_arm64, and you have to compile it yourself. There is a nice write-up on how to compile in a Terraform Issue. As I constantly switch between using my own-compiled and pre-build binaries, I wanted to have an elegant solution that manages all the details.
The new arm64 architecture with the M1 chips has severe implications for the Terraform community. First, we had to wait for Go 1.16 to be released, to finally support the MacOS arm64 architecture. Only then it was possible to release a terraform version for M1 chips and compile terraform providers for the new architecture darwin_arm64.
However, two major problems persist:
- The general availability of darwin_arm64 Terraform providers. There are often cases where the maintainers did not release a darwin_arm64 version yet. Only roughly a fourth of all providers have a darwin_arm64 version released (see here for details)
- In many projects, a specific provider version is pinned. Upgrading is not an option, e.g., either due to breaking changes in the new version, or the pinned version has no darwin_arm64 compiled binary.
In both cases, it is necessary to compile the provider yourself for your Apple Silicon. There are a few excellent tutorials on that, for example, this one. I also followed that path for some time but noticed several issues after a while:
- I often have to change between different Terraform projects. Some projects are up-to-date and don’t need self-compiled providers. Some projects need them. I was getting tired of copying folders around. The existence of a specific folder helps Terraform recognize that it must use the locally compiled provider, instead of searching in the Terraform registry.
- Different Terraform provider codebases have slightly different ways of compiling, and the compiled binary ends up at various locations.
- I did not want to run the same ten commands all the time.
To tackle these issues, I started working on a CLI tool: https://github.com/kreuzwerker/m1-terraform-provider-helper
The tool tackles the three problems above by providing an easy-to-use interface. It has commands to activate or deactivate the usage of locally compiled providers. And it provides an easy way to install (and compile!) a specific Terraform provider version. Over time, it will also get support to automatically detect how the different providers are compiled to install everything smoothly.
How to Use
You can install the tool via brew:
brew install kreuzwerker/taps/m1-terraform-provider-helper
A CLI to manage the installation of terraform providers for the Mac M1 chip Usage: m1-terraform-provider-helper [command] Available Commands: activate Activate the usage of m1 provider helper deactivate Deactivate the usage of M1 provider helper help Help about any command install Downloads (and compiles) a terraform provider for the M1 chip status Shows the status of the m1 provider installations Flags: -h, --help help for m1-terraform-provider-helper
Example: You want to install the terraform-provider-vault in version 2.10.0 because you are using it in a project and let’s assume it has no pre-build binary for Mac M1:
m1-terraform-provider-helper activate # (In case you have not activated the helper) m1-terraform-provider-helper install hashicorp/vault -v 2.10.0 # Install and compile
I hope this tool is of use to anyone with Apple Silicon working with Terraform. If so, please share it and feel free to suggest improvements.