machulav
Support EC2 launch templates
Сontinuation of the discussion started by @jpalomaki in https://github.com/machulav/ec2-github-runner/pull/62#issuecomment-907469554
Related issues that may be covered using the EC2 launch template approach:
| Feature | Issue | Can be covered by EC2 launch template |
|---|---|---|
| Re-use runner | #4 | ? |
| Spot instances | #5 | yes |
| Parallel processing | #8 | ? |
| Public IP | #52 | yes |
| Custom storage | #53 | yes, block device mappings, e.g. larger root volume |
| Re-use storage | #59 | ? |
| Multiple regions/AZ support | #60 | ? |
| Multiple security groups | #68 | yes |
| Tags | #3 (implemented) | yes |
| IAM role | #6 (implemented) | yes, via instance profile |
| EC2 keypair | #74 | yes |
However, we would need to introduce v3 with a changed approach to using the action
I don't think this is necessarily the case. Launch templates provide overrideable defaults for selected instance parameters (see docs), so this could be made an optional input (retaining backwards-compatibility). One could then e.g. override the instance type defined in the launch template (if any) by passing one thru the instance-type input.
Yes, you're right, we can add one more input and retain the backward compatibility.
But we can also go the other way by introducing v3 and make the action simpler, and as a result, more stable:
- support only launch templates way of the EC2 runner configuration;
- use #56 approach by default;
- remove all the not useful parameters and functionality;
- make the documentation simpler.
What do you think?
I like simplicity, so that plan for v3 definitely sounds reasonable. :+1: Consider placing those ideas in a v3 roadmap item or discussion.
That said, I do also like backwards-compatibility (even more so as this action seems to be quite widely used), so if we tested the launch template approach with v2 first, it might help us gather user experiences and get v3 right from the get-go.
As to the table above, I think #53 (block device mappings, e.g. larger root volume), #3 (tags) and #6 (via instance profile) can also be covered by using a launch template.
so if we tested the launch template approach with v2 first, it might help us gather user experiences and get v3 right from the get-go
That's actually a very good point! 🤔
@machulav Here's a quick CloudFormation template for setting up an EC2 launch template (I'd imagine something like this would help users adopt launch templates): https://gist.github.com/jpalomaki/003c4d173a856cf64c6d35f8869a2de8. Subnet is currently left optional, so we can test if automatic AZ assignment could help with #60, and spot/public IP settings are exposed as optionals. ~EBS todo.~
CloudFormation template now updated with most settings we have been looking at, including EBS, instance profile and example tags. I also tested it quickly with my Ubuntu AMI, seems to work.
Thank you! I will test it and try to figure out more details of what we can cover with this and get back to you.
