It is relatively easy to adapt a Terraform Provider, X, for use with Pulumi. The Cloudflare provider offers a good starting point for creating a new bridged provider.
You will create two Go binaries -- one purely for design-time usage to act as X's code-generator and the other for
runtime usage to serve as its dynamic resource plugin -- and link with the Terraform Provider repo and this one.
There is then typically a resources.go file that maps all of the Terraform Provider metadata available at runtime
to types and concepts that the bridge will use to generate well-typed programmatic abstractions.
The Cloudflare provider provides a standard blueprint to follow for this. There are three major elements:
The Makefile compiles these programs, and notably, uses
the resulting pulumi-tfgen-cloudflare binary to generate code for many different languages. The resulting generated code is
stored in the sdk directory.
The main interaction point between the bridged provider authors and the bridge itself if via tfbridge.ProviderInfo.
Each upstream Terraform resource needs to be given a Pulumi appropriate name, called a token. We call this process token mapping. A simple mapping looks like this:
"aws_s3_bucket": {
Tok: tfbridge.MakeResource(awsPackage, s3Mod, "Bucket"),
},Mapping a couple of resources is fine, but it quickly becomes tiresome to provide a manual mapping for each resource and datasource in a large provider, especially since new updates to the provider introduce new resources and remove old resources. The solution is automatic token mappings.
For example:
prov.MustComputeTokens(tokens.SingleModule("docker_", "index",
tokens.MakeStandard(dockerPkg)))See automatic token mapping for more information.
To add new resources/datasources or replace existing resources/datasources to the bridge Terraform provider, see MuxWith.
For instructions on bridging a Terraform provider built using the Terraform Plugin Framework, please see pf/README.md.