provider/aws: Add top-level ELB Attachment resource

[phinze]

Based on an ML discussion:

https://groups.google.com/d/msgid/terraform-tool/e9ef8081-db96-4329-9b62-adf8c0b40c81%40googlegroups.com

It seems like it might be worth splitting out instance <-> ELB attachments as their own resource, in the way that we've done in several other scenarios now.

The use case from the thread is the desire to be able to create an ELB w/ instances and to have provisioners on the instances reference details about the ELB. You can't do that today w/o a cycle because the only way to attach instances to an ELB is via the instances parameter on aws_elb.

If we had a top level attachment resource you could do something like this:

# ==> Proposed config, does not work today <==

variable "count" { default = 3 }

resource "aws_elb" "app" {
  # no instances field specified
}

resource "aws_instance" "app" {
  count = "${var.count}"
  # ... provisioners here, reference ELB normally
}

# New proposed resource:
resource "aws_elb_attachment" "app" {
  count    = "${var.count}"
  elb      = "${aws_elb.app.id}"
  instance = "${element(aws_instance.app.*.id, count.index)}"
}

[mberhault]

@phinze: thanks for filing this, that would definitely solve my problem. From the way ELBs are configured, it should also be fairly straightforward as creation and instance-registration are different steps.

[lvjp]

I have the same problem when i want to run my configuration with Amazon recommended rules

[amochtar]

We have a similar use case, but then with auto scaling groups in stead of instances. To add SSL certificates for new domains, we are adding new ELBs. These ELBs point to existing ASGs. The ASGs are generic infrastructure that are shared between applications, while the new ELBs are application specific.

We are currently trying to modularize our terraform codebase. We would like to create separate plans to create the ASGs and ELBs, where the ASGs are created before the ELBs exist. Currently this is not possible because the the ELBs have to be passed in the load_balancers parameter of the ASG.

An ELB attachment resource would help us out greatly, when it also could support ASGs.

[roderickrandolph]

To expand on @amochtar's use case, here's an example where aws_elb_attachment would be powerful in managing docker containers across an ASG of docker hosts. This allows one to associate containers with an ELB (for port mapping) while also giving them the ability to destroy the containers and ELB without destroying the underlying docker hosts (which may have other unrelated containers running with their own independent ELB). I also threw wait_for_elb_capacity argument in there as an added bonus 😉

# proposal

resource "aws_autoscaling_group" "docker_hosts" {
    # no load_balancers field specified
}

resource "docker_image" "app" {
    count = "${var.count}"
    name  = "nginx"
    lifecycle {
        create_before_destroy = true
    }
}

resource "docker_container" "app" {
    count = "${var.count}"
    image = "${docker_image.app}"
    ports {
        external = "${var.container_port}"
        internal = "80"
    }
    lifecycle {
        create_before_destroy = true
    }
}

resource "aws_elb" "app" {
    depends_on = ["docker_container.app"]
    listener {
        lb_port     = "80"
        lb_protocol = "http"

        instance_port     = "${var.container_port}"
        instance_protocol = "http"
    }
    # no instances field specified
}

resource "aws_elb_attachment" "app" {
    elb = "${aws_elb.app.id}"
    autoscaling_group = "${aws_autoscaling_group.docker_hosts.id}"
    wait_for_elb_capacity = 1
}

[ghost]

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 have found a problem that seems similar to this, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further.