Size limit for user_data?

Terraform
1

I use terraform to create my ec2 instances in Amazon cloud.
However: There seems to be a limit in size of 16k for the app-init.tpl.sh script I use to bootstrap the machine.
There is no difference between


and

We have this size because we create docker-compose files with this mechanism and also doing some stuff with ssh-keys. This needs the space.

I know I can shift some code to
provisioner "remote-exec"

However are there other solutions or ideas?
16k seems to me also not very comfortable. With 1MB a lot of practical issues would disappear I think.

2

Hi @porschberg,

The limit you are referring to is an EC2 service limit, not something Terraform controls. Therefore Terraform cannot increase the limit.

My suggestion would be to consider building a custom AMI that has your full script already installed in its filesystem, and then use user_data only to trigger that script to run, possibly passing in some arguments to the script that are determined from Terraform.

If you take that approach you could also decide to pre-run some of the actions that your script would do today. For example, if the content of the docker-compose files is known at build time then you could elect to include those in your custom AMI so that they are already present on disk when the instance starts up.

One way to build custom machine images is using HashiCorp Packer, which works by starting up a temporary EC2 instance with an existing AMI, running a set of commands you provide, and then shutting down the EC2 instance and capturing its disk contents in a new AMI.

3

Hi,
thank you for your explanation. The idea to use a custom AMI is worth considering.
Currently we just trust the latest ami2-images from Amazon.
For now I will go the way via provisioner "remote-exec".
Thomas

4

Great!

If the complexity of provisioners is lower than the complexity of building custom images for your use-case then that is certainly a viable alternative.

For anyone else who finds this thread in future, you can find some additional context on this design tradeoff on the provisioners documentation page.