Should we implement Terraform code through AWS CDK?

[pimvernooij]

Currently we implement infrastructure-as-code through Terraform HCL, using Jinja2 templates to make them dynamic.

Does it make sense to change this to an 'only Python code' implementation, through the use of AWS CDK?

That supports terraform providers since a while:

• https://www.hashicorp.com/blog/cdk-for-terraform-enabling-python-and-typescript-support
• https://aws.amazon.com/blogs/developer/introducing-the-cloud-development-kit-for-terraform-preview/

Perhaps we can discuss pro's and con's?

[tleguijt]

Good idea! I think it makes for cleaner code and makes the actual intended configuration more readable. Can't think of any downsides

[davidweterings]

I'd say the downside could be the following warning on their repo (not that that has stopped us before :P); This experimental repository contains software which is still being developed and in the alpha testing stage. It is not ready for production use. Looking at their bugtracker I'm not sure how fast they pick up/fix issues; https://github.com/hashicorp/terraform-cdk/issues

However, it seems like an excellent way to replace the Jinja templates. For local modules you don't seem to get typing information :-(

[pimvernooij]

@davidweterings it's still alpha indeed, however aws seems to be pushing CDK quite hard and also collaborating with HashiCorp around terraform-cdk. But let's be careful indeed, before we depend on something that's not maintained anymore.

Could you elaborate about the typing information on local modules?

Perhaps we should consider supporting both CDK-generated TF JSON, as well as well as HCL-generated JSON? So users always have a fallback.

I've tried it with our commercetools terraform provider. Seems pretty straightforward!

cdktf.json:

{
  "language": "python",
  "app": "python3 ./main.py",
  "terraformProviders": [
    "aws@~> 2.0",
    "labd/commercetools"
  ],
  "codeMakerOutput": "imports"
}

main.py:

#!/usr/bin/env python
from constructs import Construct
from cdktf import App, TerraformStack
from imports.commercetools import CommercetoolsProvider, ProjectSettings
from imports.aws import AwsProvider


class MyStack(TerraformStack):
    def __init__(self, scope: Construct, ns: str):
        super().__init__(scope, ns)

        AwsProvider(self, 'aws', region='eu-west-1')

        CommercetoolsProvider(self, 
            "commercetools",
            api_url="https://api.europe-west1.gcp.commercetools.com",
            client_id="xxxx",
            client_secret="xxxxx",
            project_key="test-environment-pim",
            scopes="manage_extensions:test-environment-pim manage_project_settings:test-environment-pim manage_subscriptions:test-environment-pim manage_api_clients:test-environment-pim manage_project:test-environment-pim manage_stores:test-environment-pim",
            token_url="https://auth.europe-west1.gcp.commercetools.com",
        )

        ProjectSettings(self,
            "settings",
            countries=["NL", "IE"],
            currencies=["EUR"],
            languages=["nl", "en"],
            messages= {
                "enabled": "true",
            },
            name="Pims test environment",
        )


app = App()
MyStack(app, "cdk-commercetools")

app.synth()

[pimvernooij]

One thing that crossed my mind is wether we would still be able to support terraform modules as components (with HCL code in them) when going down this route.

[tleguijt]

I suppose when loading in a module (described in https://github.com/hashicorp/terraform-cdk/blob/master/docs/working-with-cdk-for-terraform/using-providers-and-modules.md#using-modules) it can be an old-fashioned Terraform configuration. Need to do a small PoC around that

[pimvernooij]

Ah that seems absolutely usable!

[mvantellingen]

For reference, see #83