如何通过Terraform实现Elastic Beanstalk环境URL切换？

Great question—manual Terraform state modifications are always risky and error-prone, so it’s smart to look for alternatives. Your initial blue-green workflow makes sense, but there are better ways to avoid touching the state file directly. Here are a few reliable approaches:

1. Use local-exec to Trigger EB Swap + Auto-Refresh State #

Instead of manually updating the state, you can automate the swap and state sync using Terraform's local-exec provisioner. This leverages the official EB CLI swap command, then forces Terraform to refresh its state to match the real-world environment changes.

Example Configuration #

resource "aws_elastic_beanstalk_environment" "blue" {
  name                = "my-app-blue"
  application         = aws_elastic_beanstalk_application.my_app.name
  solution_stack_name = "64bit Amazon Linux 2 v3.4.9 running Python 3.8"
  # Add your other environment configs (instance type, variables, etc.)
}

resource "aws_elastic_beanstalk_environment" "green" {
  name                = "my-app-green"
  application         = aws_elastic_beanstalk_application.my_app.name
  solution_stack_name = "64bit Amazon Linux 2 v3.4.9 running Python 3.8"
  # Match blue environment configs, except for the version/deployment package

  provisioner "local-exec" {
    command = <<EOT
      # Swap the blue and green environments' production CNAME
      eb swap ${aws_elastic_beanstalk_application.my_app.name} \
        --source-environment ${aws_elastic_beanstalk_environment.blue.name} \
        --destination-environment ${self.name}
      # Refresh Terraform state to reflect the new CNAME assignments
      terraform refresh
    EOT
    # Ensure the green environment is fully created before swapping
    depends_on = [aws_elastic_beanstalk_environment.blue]
  }
}

Notes #

• You’ll need the AWS CLI and EB CLI installed locally, with proper IAM permissions to manage Elastic Beanstalk environments.
• The terraform refresh command pulls the latest state of all resources, so it’s safe as long as your Terraform config matches the actual infrastructure (which it should in a blue-green setup).
• This follows Elastic Beanstalk’s native swap workflow, which also updates environment tags and metadata to reflect which is the "active" production environment.

2. Manage CNAMEs Directly with Terraform Conditionals #

Instead of using EB’s swap command, you can control the production CNAME directly through Terraform variables and conditional logic. This keeps everything within Terraform’s state management, no external tools required.

Example Configuration #

variable "active_environment" {
  type        = string
  description = "Specify which environment is active (blue/green)"
  default     = "blue"
}

resource "aws_elastic_beanstalk_application" "my_app" {
  name        = "my-app"
  description = "My sample application"
}

resource "aws_elastic_beanstalk_environment" "blue" {
  name                = "my-app-blue"
  application         = aws_elastic_beanstalk_application.my_app.name
  solution_stack_name = "64bit Amazon Linux 2 v3.4.9 running Python 3.8"

  # Assign production CNAME if blue is active, else use a temporary prefix
  cname_prefix = var.active_environment == "blue" ? "my-app-production" : "my-app-blue-temp"
  # Add your environment configs (instance type, security groups, etc.)
}

resource "aws_elastic_beanstalk_environment" "green" {
  name                = "my-app-green"
  application         = aws_elastic_beanstalk_application.my_app.name
  solution_stack_name = "64bit Amazon Linux 2 v3.4.9 running Python 3.8"

  # Assign production CNAME if green is active, else use a temporary prefix
  cname_prefix = var.active_environment == "green" ? "my-app-production" : "my-app-green-temp"
  # Match blue environment configs, except for the deployment package
}

How to Switch Environments #

1. Deploy the green environment with your new application version:

   terraform apply
   

2. Switch traffic to green by updating the variable:

   terraform apply -var active_environment=green
   

Notes #

• This approach modifies the CNAME directly on each environment, rather than using EB’s native swap. It achieves the same traffic-switching result but doesn’t update EB’s internal "active" environment metadata.
• Ensure your temporary CNAME prefixes are globally unique (since EB CNAMEs are public and unique across AWS).
• No external tools are needed—everything is managed through Terraform, so state stays in sync automatically.

3. Use Terraform Data Sources to Sync State Post-Swap #

If you prefer using EB’s CLI swap but don’t want to run terraform refresh, you can use a aws_elastic_beanstalk_environment data source to pull the latest CNAME values after a swap. This lets Terraform automatically update its state based on real-world infrastructure.

Example Configuration #

# Define your blue and green environments as resources
resource "aws_elastic_beanstalk_environment" "blue" {
  name                = "my-app-blue"
  application         = aws_elastic_beanstalk_application.my_app.name
  solution_stack_name = "64bit Amazon Linux 2 v3.4.9 running Python 3.8"
}

resource "aws_elastic_beanstalk_environment" "green" {
  name                = "my-app-green"
  application         = aws_elastic_beanstalk_application.my_app.name
  solution_stack_name = "64bit Amazon Linux 2 v3.4.9 running Python 3.8"
}

# Data sources to pull the latest state of each environment
data "aws_elastic_beanstalk_environment" "blue_current" {
  name = aws_elastic_beanstalk_environment.blue.name
}

data "aws_elastic_beanstalk_environment" "green_current" {
  name = aws_elastic_beanstalk_environment.green.name
}

# Optional: Output the current production CNAME for verification
output "production_cname" {
  value = data.aws_elastic_beanstalk_environment.blue_current.cname == "my-app-production.elasticbeanstalk.com" ? data.aws_elastic_beanstalk_environment.blue_current.cname : data.aws_elastic_beanstalk_environment.green_current.cname
}

Workflow #

1. Run eb swap manually (or via CI/CD) to switch environments.
2. Run terraform apply—the data sources will pull the latest CNAME values, updating Terraform’s state without manual edits.

Notes #

• This is a middle ground between manual swap and full automation. It’s useful if you want to trigger swaps outside of Terraform (e.g., in a CI pipeline step) but still keep Terraform state in sync.

To answer your original question: no, manual state modification is not the only way. All of the above approaches let you manage blue-green deployments with Terraform and Elastic Beanstalk without touching the state file directly. Which one you choose depends on whether you want to use EB’s native swap workflow, stay entirely within Terraform, or use a hybrid approach.

内容的提问来源于stack exchange，提问作者Jeremy