Terraform
Deployment Patterns
You can configure your Continuous Integration/Continuous Deployment (CI/CD) environment to automatically deploy your CDKTF applications. This page explains different types of deployment patterns to help you choose the methods that are most appropriate for your use case.
Deployment Methods
You can provision your infrastructure using either CDKTF CLI commands (e.g., cdktf deploy
) or by synthesizing your application into a Terraform configuration file and using Terraform directly. Both approaches allow you to use HCP Terraform and integrate with a CI/CD pipeline.
Run CDKTF CLI Commands
We recommend using CDKTF CLI commands in the following use cases:
Your application performs additional tasks For example, your application may build a Docker image or start a build pipeline locally through synchronous APIs. You might also be using the null provider to execute these actions when a resource is created (e.g., after the Docker registry has been created). Running
cdktf deploy
triggers all of these actions at runtime in addition to using Terraform to provision your infrastructure.Your application contains stacks with complex dependencies. Each stack in a CDKTF application is like a separate Terraform working directory. Terraform respects complex dependencies within the same configuration, but it is not designed to manage complex dependencies between multiple working directories. For example, if you define a stack A that depends on data from stack B and stack C, Terraform runs will fail. This is because Terraform will not understand that it must wait to build stack A until both stack B and stack C are completed.
Run cdktf synth
and Use Terraform Directly
We recommend synthesizing your CDKTF application and using Terraform directly when you need to integrate into existing Terraform workflows. Your organization may already use HCP Terraform or have integrated Terraform into CI pipelines. In these cases, you may want to run cdktf synth
and set the output folder to a particular directory that you can reference in your existing workflows.
Using HCP Terraform
HCP Terraform lets you review the current state of your infrastructure and run progress in the HCP Terraform UI. You can also use HCP Terraform as the source of secrets.
Refer to Set Up CDKTF With HCP Terraform for details. Refer to Example Workflows for several examples of connecting your CDKTF application to HCP Terraform and using HCP Terraform in a Continuous Integration pipeline.
Managing Secrets and Sensitive Data
You should read secrets with Terraform Variables so that they do not appear in your synthesized CDKTF code.
Example Workflows
The following examples demonstrate common deployment workflows for your CDKTF application.
Deploy with Terraform and HCP Terraform
Connect your synthesized CDKTF configuration to a HCP Terraform workspace with the following steps:
- Add a pre-commit step in your CDKTF application that runs
cdktf synth
. This creates Terraform configuration files in thecdktf.out/stacks/<stack-name>
directory. - Configure the VCS integration for a HCP Terraform workspace to point to the directory with the synthesized configuration files. To deploy multiple independent stacks, configure one HCP Terraform workspace to point to the output directory for each stack.
Refer to Automatic Run Triggering in the HCP Terraform documentation for details about how to trigger Terraform runs from merges and commits.
Terraform CDK GitHub Action
You can use the Terraform CDK GitHub Action if you are using GitHub Actions and you want a default review / deployment workflow. The Terraform CDK GitHub Action runs the CDKTF CLI under the hood, it comments Terraform plans on your pull requests and provides a default review workflow. If you need more customization, refer to GitHub Actions CI and HCP Terraform.
GitHub Actions CI and HCP Terraform
Set the TERRAFORM_CLOUD_TOKEN
environment variable to the HCP Terraform API token. This allows the CDKTF stacks CloudBackend
to connect to HCP Terraform.
You must create a job like this for every stack so that you can pass the stack name into cdktf diff <stack name>
. None of the stacks can depend on each other because Terraform cannot reason about which stacks must be launched first to respect these dependencies.
The following example shows a GitHub Actions configuration where the CDKTF application is deployed from the main
branch and uses HCP Terraform. You could store this file in .github/workflows/cdktf-deploy.yml
.
name: CDKTF Deployment
on:
push:
branches: [main]
jobs:
deploy:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v3
- name: Use Node.js 18.x
uses: actions/setup-node@v3
with:
node-version: 18.x
cache: "npm"
- name: Install CDKTF CLI
run: npm install -g cdktf-cli
- name: Install Terraform
uses: hashicorp/setup-terraform@v2
with:
terraform_version: 1.1.7
- name: Install dependencies
run: npm ci
# If you use providers or modules that are not pre-built, you can install them here
- name: Generate bindings for providers and modules
run: cdktf get
- name: Run Tests
run: npm test
- name: Deploy
run: cdktf deploy --auto-approve '*' # Deploys all stacks
env:
TERRAFORM_CLOUD_TOKEN: ${{ secrets.TF_API_TOKEN }}
To get the plan output posted as a comment on your pull request, add the following to your .github/workflows/cdktf-diff.yml
file:
name: CDKTF Diff
on: [pull_request]
jobs:
diff:
name: "Terraform CDK Diff"
runs-on: ubuntu-latest
steps:
- name: Checkout
uses: actions/checkout@v2
- name: Setup Terraform
uses: hashicorp/setup-terraform@v1
with:
terraform_version: 1.1.7
cli_config_credentials_token: ${{ secrets.TF_CLOUD_TOKEN }}
- uses: actions/setup-node@v1
with:
node-version: "14"
- run: yarn install
# CDKTF runs the plan here, so you need to fill in the name of your stack.
- name: plan
run: cdktf plan <stack name>
env:
TERRAFORM_CLOUD_TOKEN: ${{ secrets.TF_API_TOKEN }}
continue-on-error: true # We want to see the plan output even if the plan fails
# Replace this step with any workflow you like, e.g. posting a message in a slack channel.
- uses: actions/github-script@0.9.0
if: github.event_name == 'pull_request'
env:
PLAN: "terraform\n${{ steps.plan.outputs.stdout }}" # CDKTF gets the output from the last step
with:
github-token: ${{ secrets.GH_COMMENT_TOKEN }} # Create a secret with a GitHub token that can comment on PRs
script: |
const output = `#### Terraform Plan 📖\`${{ steps.plan.outcome }}\`
<details><summary>Show Plan</summary>
\`\`\`${process.env.PLAN}\`\`\`
</details>
*Pusher: @${{ github.actor }}, Action: \`${{ github.event_name }}\`, Working Directory: \`${{ env.tf_actions_working_dir }}\`, Workflow: \`${{ github.workflow }}\`*`;
github.issues.createComment({
issue_number: context.issue.number,
owner: context.repo.owner,
repo: context.repo.repo,
body: output
})
Running the CDKTF CLI on a General Purpose CI
If you have a general purpose CI like GitHub Actions or CircleCI configured, use the cdktf deploy --auto-approve <your stacks>
command to trigger a deployment. This deploys your stacks in the right order and in parallel. To set up this workflow, you must install the following software:
- Node in version 14.0+
- The
cdktf-cli
CLI - Terraform v1.0+
- Any other languages you use for your CDKTF application
Warning: Auto-approved deployments skip the option to review planned changes to your infrastructure before Terraform applies them. Minimize risk of unpredictable infrastructure changes and configuration drift by making sure that no one can change your infrastructure outside of your automated build pipeline. Refer to Non-Interactive Workflows for details.
Contribute Additional Examples
To share another solution, please open a GitHub issue or submit a pull request for this documentation page.