Feature request: inventory autoscaling group instances

[cbarbour]

It would be useful if we could inventory the instances created by an auto scaling group, similar to the way we can inventory instances created by a spot request.

This is dependent on a feature request for terraform: hashicorp/terraform#8400

[adammck]

I'm not sure that this is such a good idea... instances launched by ASGs should be ready to use immediately, without needing provisioning by e.g. Ansible. Can you give me an example of your usecase(s), so I might understand what you're aiming to accomplish?

[adammck]

That said, it's outside the scope of this tool, but it'd certainly be possible to hit the AWS API to fetch a list of instances for the given ASG, and generate and inventory from that.

[cbarbour]

We would like a way to easily update the configs on our existing auto-scaling instances.

E.g. we just added a new member to the team, and need to push out their public keys to the ubuntu user's authorized_keys file. New instances will get this change, but existing instances will not. If we can run Ansible, updating our running instances is a trivial task. Otherwise, our options are to replace all the existing instances, or write our own solution to do this out-of-band.

In our case, we're using terraform to create auto-scaling groups, and cloud-init to create mountpoints & manage SSH keys.

If we add a new mount-point, terraform will update our cloud-init template. Same with the SSH keys. We ignore changes to cloud-init data to avoid rebuilding the instances automatically. We'd rather just force cloud-init to re-apply the user data on the existing nodes, and let new nodes pickup the data at first boot.

[rnrbarbosa]

@adammck a good use case for this is, assuming:

• You create an aws_autoscaling_group with a correspondent aws_launch_configuration
• You create an Application Load balancer, aws_alb with the correspondent aws_alb_target_group
• Now you want to link the aws_autoscaling_group with the aws_alb_target_group

resource "aws_alb_target_group_attachment" "test" {
  target_group_arn = "${aws_alb_target_group.test.arn}"
  target_id = "${aws_instance.test.id}"
  port = 80
}

how do you get the aws_instances ids launched by the aws_launch_configuration to make the link?

[rnrbarbosa]

Sorry, @adammck

On my example above, it can be solved as per below:

resource "aws_autoscaling_group" "main" {
    ...
   target_group_arns = ["${aws_alb_target_group.main.arn}"]
}

[zakkg3]

Another case;

• You create an instance using an autoscaling group. (1 to 1)
• You create an elastic ip address.
• You want to assign the elastic ip address to this instance.

could be useful to have:

resource "aws_eip" "lb" {
  instance = "${ aws_autoscaling_group.main.intance[0].id}"
  vpc      = true
}

[mrcrilly]

@adammck

I'm not sure that this is such a good idea... instances launched by ASGs should be ready to use immediately, without needing provisioning by e.g. Ansible

This isn't (always) true. I've been in situations in which the ASG was used simply to bring up two instances (max: 2, min: 2, desired: 2) and lock that number in place. In that situation an ASG is still useful: it auto-recovers from a failure where as a stand alone EC2 instance does not (without additional work an ASG has already done for you.) The monitoring suite then re-ran Ansible against the system. This was because (a) we could not install or embed Ansible code into the AMI to provision it on launch and (b) the EC2 instance was an inbound only, air gapped set of systems that could use ansible-pull.

That said, it's outside the scope of this tool ...

I don't see how. It's this tool's job to find and extract EC2 instance (for example) information from the Terraform state. Sometimes those instances are abstracted behind another resources and aren't hard coded into a state file. This means the tool should go a bit further and reach out to the AWS API and fetch the instances behind the ASG ID (which is in the state file.)

Would a pull request for this be entertained at all?

[adammck]

Absolutely, I’m not against supporting use-cases which I think are a bad idea :)