Terraform-provider-aws: AWS CodeDeploy blue/green after deployment

[golimer]

Terraform Version

terraform 0.11.7

Affected Resource(s)

• aws_codedeploy_deployment_group

Problem is then applying terraform creating Blue/Green deployment successfully, BUT after deployment aws changing asg group name to "CodeDeploy_web_d_EXJHJHG..." and after this terraform state lose this asg. After this when applying again TF want to create asg(auto_scaling_group ) which was set in module...

[luisrod-olx]

Hi all. This is an issue since last year, any news on this?

[niclic]

Unfortunately, terraform is not compatible with CodeDeploy Blue Green deployments that use the COPY_AUTO_SCALING_GROUP action.

What is the problem:

When using green_fleet_provisioning_option with COPY_AUTO_SCALING_GROUP, CodeDeploy (and not terraform) creates a new ASG with a different name. This ASG is not managed by terraform and conflicts with existing configuration and state.

I'm not sure how this can be resolved at this time. There is no way to change the name of an existing ASG (attribute is immutable).

What can I do?

• Importing the Autoscaling Group(s) created by CodeDeploy _can_ work in some scenarios, but success depends on your particular setup.

# remove state of original ASG
terraform state rm ADDRESS

# import state of new ASG
terraform import ADDRESS NEW_ID

However, this isn't a manageable solution for frequent deployments and can quickly become complex when multiple modules and resources are involved.

Next steps

As it stands, I suggest adding a note to the docs explaining that this option does not currently work without caveats. If absolutely necessary the COPY_AUTO_SCALING_GROUP option for the green_fleet_provisioning_option configuration can be removed altogether.

I know this does not fix the issue. But I would prefer to be open about the problem and prevent people from running into it, opening new issues, and ending up disappointed.

An attempt was made to use tags to manage an ASG from the terraform side (instead of the unique resource id). This could work in theory, but I'm not sure this is a viable approach. Terraform (and not AWS) would need to use tags to enforce a unique constraint across different ASG, which seems brittle. I would be surprised (but pleased) if such a PR was accepted.

What else can I do?

You probably want to use a different approach to managing blue-green deployments in AWS that involve multiple ASG. For example, when using green_fleet_provisioning_option with DISCOVER_EXISTING, terraform can be used to manage separate blue and green ASG, one of which is active, and the other can be used to discover instances for the replacement environment. I have used this approach successfully. Just be sure to keep the original instances in the deployment group running or scaled down. This would work even better if CodeDeploy deployments were also managed via terraform.

[bflad]

Hi, folks! 👋 Sorry for the hassle. I would agree with @niclic's assessment and writeup above. Since supporting COPY_AUTO_SCALING_GROUP would require Terraform to implicitly manage externally created resources (not a design tenet of Terraform) and generally speaking would introduce a lot of complexity either in the resource or Terraform configurations, a documentation update seems very appropriate.

@niclic so you get credit, would you feel comfortable submitting a documentation note to the top of the resource documentation page as a pull request to help future travelers? I think mentioning the limited support for COPY_AUTO_SCALING_GROUP and a quick recommendation of DISCOVER_EXISTING seems appropriate. The page lives at: https://github.com/terraform-providers/terraform-provider-aws/blob/master/website/docs/r/codedeploy_deployment_group.html.markdown

The yellow box can be added to the documentation via this syntax:

~> **NOTE:** Text goes here

Thanks!

[niclic]

Yes @bflad , I will submit a documentation update. I meant to do just that when I originally wrote that comment, but haven't got around to it. I will flag you on the PR when it lands.

[jwhitcraft]

@niclic just wondering if you could share how you did this with terraform?

You probably want to use a different approach to managing blue-green deployments in AWS that involve multiple ASG. For example, when using green_fleet_provisioning_option with DISCOVER_EXISTING, terraform can be used to manage separate blue and green ASG, one of which is active, and the other can be used to discover instances for the replacement environment. I have used this approach successfully. Just be sure to keep the original instances in the deployment group running or scaled down. This would work even better if CodeDeploy deployments were also managed via terraform.

Thanks.

[bee-keeper]

Currently looking at this very problem and I'm left wondering can TF work for my use case or not?

I think it would really make sense here to elaborate on the use of DISCOVER_EXISTING as I have no idea how imperfect or not this solution is without in depth investigation.

[dedamico]

I have done some research and testing into how CodeDeploy groups are created in the AWS console and have closely matched the AWS console GUI options with how these would translate into Terraform code:

resource "aws_codedeploy_app" "codedeploy_app" {
name = "TEST"
compute_platform = "Server"
}

resource "aws_codedeploy_deployment_group" "codedeploy_group" {

app_name = "${aws_codedeploy_app.codedeploy_app.name}"
deployment_group_name = "TEST"
service_role_arn = "<arn>"
autoscaling_groups = ["<autoscalinggroup>"]
deployment_config_name = "CodeDeployDefault.AllAtOnce"

ec2_tag_set {
    ec2_tag_filter {
      key   = "name"
      type  = "KEY_AND_VALUE"
      value = "daved-12345"
    }

  }
auto_rollback_configuration {
enabled = true
events = ["DEPLOYMENT_FAILURE"]
}

blue_green_deployment_config {
deployment_ready_option {
action_on_timeout = "CONTINUE_DEPLOYMENT"
}

terminate_blue_instances_on_deployment_success {
action = "TERMINATE"
}

green_fleet_provisioning_option{
action = "DISCOVER_EXISTING"
}
}

load_balancer_info {
target_group_info {
name = "<load balancer name>"
}
}

deployment_style {
deployment_type = "BLUE_GREEN"
deployment_option = "WITH_TRAFFIC_CONTROL"
}
}

NOTE:

1) DISCOVER_EXISTING maps to the 'Manually Provision Instances' setting in the AWS Console.

2) The ec2_tag_set maps to the "Tag Group" in the AWS Console, and the child tags underneath will be individual tag settings.

Conclusion: all that should be needed is to have the ec2 tag/filter set in place for the instances to be discovered.

[hashibot[bot]]

I'm going to lock this issue because it has been closed for _30 days_ ⏳. This helps our maintainers find and focus on the active issues.

If you feel this issue should be reopened, we encourage creating a new issue linking back to this one for added context. Thanks!