Provisioning Ephemeral Infrastructure with Terraform

In this lesson, you will learn how to orchestrate the lifecycle of isolated, temporary cloud environments within your CI/CD pipeline to ensure every integration test runs against a pristine, production-like state.

The Problem with Static Environments

Relying on a permanent "staging" cluster often leads to "configuration drift" or "polluted state," where leftover artifacts from previous builds cause flaky tests. By treating infrastructure as ephemeral, we ensure that every pipeline run starts from a clean slate and leaves no trace behind, which is critical for maintaining high-confidence deployments.

Orchestrating Ephemeral Infrastructure

To achieve this, we embed Terraform execution directly into our pipeline stages. The workflow follows a strict "provision-test-destroy" pattern:

1. Provision: The pipeline triggers terraform apply using a unique workspace or variable (e.g., based on the $GIT_COMMIT_SHA) to create a dedicated Kubernetes namespace or cluster.
2. Test: The CI runner deploys the application containers into this environment and executes integration suites.
3. Destroy: The pipeline runs terraform destroy -auto-approve as a "post" or "finally" block, ensuring the resources are torn down regardless of whether the tests passed or failed.

Here is a conceptual snippet for your CI configuration:

stages:
  - provision
  - test
  - teardown

provision_env:
  script:
    - terraform init
    - terraform apply -var="namespace=ci-${CI_PIPELINE_ID}" -auto-approve

run_tests:
  script:
    - ./scripts/run-e2e-tests.sh --namespace=ci-${CI_PIPELINE_ID}

cleanup_env:
  after_script:
    - terraform destroy -var="namespace=ci-${CI_PIPELINE_ID}" -auto-approve

Best Practices for Ephemeral Scaling

To keep your pipeline performant:

• Use Remote State: Store your Terraform state in an S3 bucket or similar backend so that the pipeline runner doesn't need to hold the state file locally.
• Variable Injection: Always parameterize your infrastructure using the Pipeline ID or Commit SHA to prevent naming collisions when multiple pipelines run in parallel.
• Resource Pruning: If a pipeline fails before the teardown stage, implement a scheduled "janitor" job that runs terraform destroy on any stale infrastructure older than a few hours to manage cloud costs and resource limits.

Key Takeaway: By binding the lifecycle of your infrastructure to the lifecycle of your CI/CD job, you eliminate state-related test failures and ensure your infrastructure remains truly immutable and cost-effective.