16

It seems like I can use either user_data with a template file or a "remote-exec" provisioner with inline commands to bootstrap. So which one is considered more idiomatic?

Chris
  • 953
  • 11
  • 16

3 Answers3

26

You should use user_data. The user data field is idiomatic because it's native to AWS, whereas the remote-exec provisioner is specific to Terraform, which is just one of many ways to call the AWS API.

Also, the user-data is viewable in the AWS console, and often an important part of using Auto Scaling Groups in AWS, where you want each EC2 Instance to execute the same config code when it launches. It's not possible to do that with Terraform's remote-exec provisioner.

Josh Padnick
  • 3,157
  • 1
  • 25
  • 33
  • 3
    In addition to this, using `user_data` is also applicable when autoscaling is in use, since it can be included in the launch configuration. So using `user_data` gives consistency across both static instances and autoscaling instances. – Martin Atkins Jun 06 '17 at 16:40
5

Though I do agree with Josh, if there are no run time changes to the instance you can use packer to build an ami and then use that in the launch config. That way you don't have to wait for user-data to run.

Packer is part of the Hashicorp family of tools

https://www.packer.io/docs/builders/amazon-ebs.html

strongjz
  • 4,271
  • 1
  • 17
  • 27
  • 1
    This is a valid point. In fact, if you don't need your configuration to be dynamic (e.g. by detecting a private IP address only known when an EC2 Instance launches), building an AMI is usually the fastest and most reliable way to handle configuration. – Josh Padnick Jun 07 '17 at 01:47
  • Thanks for the suggestions. I agree AMI should be the way to go. However my organization currently doesn't allow custom images. – Chris Jul 25 '17 at 01:42
1

It Totally based on condition and scenarios.

Case: Where you are using template mostly in autoscaling group you should use user_data. As all the new instances launched will get launch using same init script which have one more benefit you can actually see the o/p in AWS console logs.

Case: While you are booting new instances and once it is up your configuration management tools runs or template tool like.

provisioner "remote-exec" {
inline = [
  "puppet apply",
  "consul join ${aws_instance.web.private_ip}",
]
}

Refer Docs for remote exec

Dev pokhariya
  • 336
  • 4
  • 16