Custom Terraform Providers - Part 3 - Technicalities
Part 3 - Technicalities
In the previous part, I explained why you would make a custom Terraform provider and how it looks like. If you’re looking for more details, the Terraform tutorials are very informative, or just reach out! In this section, I wanted to go over a few additional technical challenges for which I could not find the answer merely through StackOverflow. That’s right! So ChatGPT was not very helpful either as you can imagine.
Custom Terraform Providers & Artifactory
Generally, we want to pull Terraform providers from their respective registries at runtime. This forces the best practices as laid out by Hashicorp when distributing your provider. Also, it’s less overhead if you can just work with your custom self-made providers along your standard Azure/AWS/whatnot providers.
With Artifactory already being the central Artifact store, as far as we know at least, you would expect to be able to pull your provider from there as well. Since you generally pull your images, packages and modules from there as well.
However, this might not always be possible with Artifactory. I’m not sure if that’s in general, or just the particular Artifactory implementation I’m now working with. In essence, Terraform follows a Remote Service Discovery Protocol, where it queries a remote registry for more information about the registry itself. The registry is expected to give a predefined response, that in turn helps to locate the particular providers that are hosted by that particular registry. If this fails, then Terraform in essence is unable to use the Registry and you’ll need to work around by explicitly downloading the provider into a filesystem mirror and direct the init to the local filesystem mirror for the particular registry.
Also, there’s somebody who created a tutorial about creating your own registry! Pretty nifty!
But through a local filesystem mirror
Until it’s possible to make use of Artifactory, we’re working around some issues by using what Hashicorp calls a “filesystem mirror”.
Essentially, you perform the following steps:
Step 1: Download the Zip
Login to Artifactory, move over to the sidap-terraform repository, and find the provider according to your requirements regarding OS, System Architecture and Provider Version.
Step 2: Store that Zip in your plugin cache
For your cache, see also here. Make sure to follow the naming conventions for the unpacked layout as described here.
Step 3: Update your ~/.terraformrc accordingly
You’ll need to fill in your provider installation and make sure to at least cover this:
provider_installation {
filesystem_mirror {
path = "/home/(your user)/.terraform.d/plugins"
include = ["<your-org>/<artifactory-repository>/*/*"]
}
direct {
exclude = ["<your-org>/<artifactory-repository>/*/*"]
}
}
Step 4: Define your provider in Terraform
Then, you’re ready to make use of the provider within your Terraform code.
terraform {
required_providers {
dbucnn = {
source = "<your-org>/<artifactory-repository>dbucnn"
version = "1.0.4"
}
}
}
And that’s it! Now you should be ready to go!