CI/CD with Terraform

# CHAPTER 14

CI/CD with Terraform #

1. Introduction #

2. Learning Objectives #

• Explain the necessity of integrating Terraform with CI/CD pipelines.

• Architect a two-phase deployment workflow (Plan on PR, Apply on Merge).

• Configure a GitHub Actions YAML file to execute Terraform safely.

• Understand how to inject cloud credentials securely into the CI/CD runner.

• Automate posting terraform plan output as comments on Pull Requests.

3. Beginner-Friendly Explanation #

• The Old Way (Laptop Execution): A rogue architect writes a blueprint, walks to the building site at 2:00 AM, and starts knocking down walls without telling anyone.

• The DevOps Way (CI/CD):

• The architect writes the blueprint and submits it to a committee (Opens a Pull Request).

• A robot (CI/CD) reads the blueprint and creates a 3D simulation of exactly what walls will be knocked down (terraform plan).

• The committee looks at the simulation. They agree it looks good and sign the approval (Merge).

• A different robot instantly takes the approved blueprint and physically knocks down the walls (terraform apply).

4. The Enterprise CI/CD Workflow #

1. 1. Developer creates a branch (e.g., add-new-database).

1. 2. Developer writes HCL code and opens a Pull Request to main.

1. 3. CI Pipeline triggers. It runs terraform fmt, terraform validate, and terraform plan.

1. 4. CI Pipeline comments the output of the plan directly onto the GitHub PR so human reviewers can see exactly what will be created/destroyed.

1. 5. Team approves and merges.

1. 6. CD Pipeline triggers. Now running on the main branch, it executes terraform apply -auto-approve, modifying the live cloud.

5. Mini Project: Build Terraform CI/CD Workflow #

Step-by-Step Architecture Concept:

name: Terraform CI Pipeline
on:
  pull_request: # Only run on PRs!

jobs:
  terraform-plan:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout Code
        uses: actions/checkout@v4

      # 1. Install Terraform on the GitHub Runner
      - name: Setup Terraform
        uses: hashicorp/setup-terraform@v3

      # 2. Authenticate to AWS (Crucial: Use OIDC or Secrets, never hardcode!)
      - name: Configure AWS Credentials
        uses: aws-actions/configure-aws-credentials@v4
        with:
          aws-access-key-id: ${{ secrets.AWS_ACCESS_KEY_ID }}
          aws-secret-access-key: ${{ secrets.AWS_SECRET_ACCESS_KEY }}
          aws-region: us-east-1

      # 3. Initialize the working directory
      - name: Terraform Init
        run: terraform init

      # 4. Check for syntax formatting errors
      - name: Terraform Format
        run: terraform fmt -check

      # 5. Generate the execution plan
      - name: Terraform Plan
        id: plan # We give this step an ID so we can reference its output later
        run: terraform plan -no-color -out=tfplan

6. The Magic: PR Comments #

      # 6. Post the plan as a PR Comment
      - name: Post Plan to PR
        uses: actions/github-script@v7
        with:
          github-token: ${{ secrets.GITHUB_TOKEN }}
          script: |
            // This script takes the output from the 'id: plan' step above
            const output = `#### Terraform Plan 📖
            \`\`\`terraform
            ${{ steps.plan.outputs.stdout }}
            \`\`\``;
            
            github.rest.issues.createComment({
              issue_number: context.issue.number,
              owner: context.repo.owner,
              repo: context.repo.repo,
              body: output
            })

7. Real-World Scenarios #

8. Best Practices #

• -auto-approve Flag: When running terraform apply in the CD pipeline (after the merge), the pipeline will hang infinitely waiting for a human to type "yes." You must append the -auto-approve flag to the command. Since the code was already peer-reviewed during the PR phase, this automated execution is considered safe.

9. Security Recommendations #

• Locking State in CI: If two developers merge Pull Requests at the exact same time, two GitHub Actions runners will trigger terraform apply simultaneously. This is why a remote backend with State Locking (Chapter 5) is an absolute, non-negotiable requirement before implementing CI/CD. The lock ensures one pipeline waits for the other to finish.

10. Troubleshooting Tips #

• Pipeline Permissions: If the "Post Plan to PR" step fails with a 403 Forbidden error, check your repository settings. Ensure the automatic GITHUB_TOKEN has read/write permissions for Pull Requests, otherwise it cannot post the comment.

11. Exercises #

1. 1. Explain the "Plan on PR, Apply on Merge" workflow paradigm.

1. 2. Why is it dangerous for human developers to possess the AWS IAM credentials required to run terraform apply from their local machines?

12. FAQs #

13. Interview Questions #

• Q: Describe the architectural workflow of a fully automated Infrastructure as Code CI/CD pipeline. How do you implement a human-in-the-loop review process without requiring developers to manually execute commands?

• Q: An organization wants to ensure that no infrastructure code is merged if it violates company tagging policies. At what stage in the CI/CD pipeline would you implement this validation, and how?

14. Summary #

15. Next Chapter Recommendation #