Infrastructure as Code in CI

# CHAPTER 14

Infrastructure as Code in CI #

1. Introduction #

2. Learning Objectives #

• Define the role of Infrastructure as Code (IaC) within a CI/CD workflow.

• Differentiate between the functions of Terraform (Provisioning) and Ansible (Configuration).

• Integrate Terraform commands (fmt, plan, apply) into GitHub Actions.

• Understand the "Plan on PR, Apply on Merge" workflow paradigm.

• Securely manage Terraform state files within a CI environment.

3. Beginner-Friendly Explanation #

• The Software (Application Code): The script, the actors, and the costumes. (What we've automated so far).

• The Hardware (Infrastructure): The stage, the lighting rigs, and the sound system.

If the script calls for a rainstorm in Act 2, but the stage crew manually forgot to install the sprinklers, the play fails. Infrastructure as Code (IaC) is writing a script for the stage crew. When the CI pipeline runs, it first reads the IaC script, builds the stage with the sprinklers perfectly (Terraform), and then brings out the actors (Software Deployment). The environment and the application are deployed together automatically.

4. Terraform vs. Ansible in CI #

• Terraform (The Builder): A declarative tool. You write resource "awsdbinstance". The CI pipeline runs terraform apply, and Terraform builds the physical database server in AWS.

• Ansible (The Configurer): A procedural tool. Once Terraform builds the blank server, the CI pipeline runs ansible-playbook, which logs into the server via SSH and installs Nginx and PHP.

5. The "Plan on PR, Apply on Merge" Workflow #

Step 1: The Pull Request (The Simulation) When a developer modifies a Terraform file and opens a Pull Request, the CI pipeline runs terraform plan. This simulates the changes without actually touching the cloud. The pipeline posts a comment on the PR: *"If you merge this, I will create 1 server and destroy 1 database."*

Step 2: The Merge (The Execution) Human reviewers read the simulation comment. If it looks correct, they click "Merge." The code enters the main branch. This triggers the second half of the CI pipeline, which runs terraform apply -auto-approve, making the physical changes to the live cloud.

6. Mini Project: Automate Infrastructure Deployment #

Step-by-Step Architecture Concept:

name: Terraform Infrastructure Pipeline

on:
  pull_request: # Only run on PRs!

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

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

      # 2. Authenticate securely with AWS
      - 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 and check formatting
      - name: Terraform Init
        run: terraform init
        
      - name: Terraform Format Check
        run: terraform fmt -check

      # 4. Generate the execution plan!
      - name: Terraform Plan
        id: plan
        # The -no-color flag makes it readable for GitHub comments
        run: terraform plan -no-color -out=tfplan

*(In a full enterprise setup, the next step would use a GitHub Script to post the stdout of this plan directly as a comment on the Pull Request UI for the reviewers to see).*

7. Real-World Scenarios #

8. Best Practices #

• Remote State Locking: Terraform uses a "State File" (terraform.tfstate) to remember what infrastructure it has built. If two developers merge code at the exact same time, two CI runners might try to run terraform apply simultaneously, corrupting the state file and destroying the cloud environment. You MUST configure a remote backend (like an S3 bucket) with state locking (like DynamoDB) to ensure CI runners form a queue and only execute one at a time.

9. Security Recommendations #

• Least Privilege for IaC: The AWS IAM user attached to a CI runner executing Terraform is incredibly powerful because it literally builds the cloud. It needs permission to create EC2 instances, VPCs, and databases. However, it should strictly be DENIED permission to manipulate core IAM permissions (so it can't create new admin users) or delete CloudTrail audit logs, ensuring a compromised pipeline cannot cover its tracks.

10. Troubleshooting Tips #

• Hanging Pipelines: If a pipeline running ansible-playbook hangs indefinitely until the 6-hour GitHub timeout cancels it, it is usually waiting for an interactive prompt. For example, SSH might be asking *"Are you sure you want to continue connecting (yes/no)?"*. Since there is no human to type "yes", the runner freezes. Always use flags like ANSIBLEHOSTKEY_CHECKING=False in automated environments.

11. Exercises #

1. 1. What is the operational purpose of running terraform plan during the Pull Request phase of a CI pipeline?

1. 2. Explain the fundamental difference between the automation tasks handled by Terraform versus Ansible in a deployment pipeline.

12. FAQs #

13. Interview Questions #

• Q: Describe the "Plan on PR, Apply on Merge" paradigm. How does this CI workflow mitigate the risks of applying declarative infrastructure changes to a production environment?

• Q: Two automated Jenkins pipelines executing Terraform run simultaneously against the same environment. Explain the catastrophic risk this poses to the terraform.tfstate file and the architectural requirements necessary to prevent it.

14. Summary #

15. Next Chapter Recommendation #