-
Notifications
You must be signed in to change notification settings - Fork 4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add support for Launch Templates #6734
Comments
Hello. I was wondering if there is an ETA of this ticket. It would be very helpful if it were implemented for my team. |
Are we going to support AWS::EC2::LaunchTemplate first? Is there any PR working on this? |
Also relevant (some LT & ASG design discussion going on) : #1403 |
I would also appreciate the availability of a plain LaunchTemplate Construct instead of the low level CFNLaunchTemplate Construct. |
…ort (#9881) - This PR allows you to: 1. use `LaunchTemplate` for the managed nodegroups 2. specify custom AMI in the `LaunchTemplate` - `prop.vpc` of Pinger is now `ec2.IVpc` - bump cluster k8s version in the integration testing from `1.16` to `1.17` Closes: #9873 Closes: #9924 ## Note At this moment we use the property override to make it work. When cfn spec is updated we can use `CfnNodeGroup` to specify launch template natively, which should be backward-compatible with no breaking changes. Users will need to create `CfnLaunchTemplate` resource and pass the resource as the property to the nodegroup untill we support the LaunchTemplate L2(#6734). ## TODO - [x] integ testing - [x] unit testing - [x] update README ---- *By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license*
As others have commented, support for launch templates is something my team would like to see implemented soon. Is there any ETA on when this might be fixed? |
It seems that a bunch of other tickets mentioning this issue got closed with this issue as favored one but there are no updates here. Any ETA on the topic? |
The issue is still open, we don't have an ETA to when it will be added. |
This provides an initial implementation of a level 2 construct for EC2 Launch Templates. It is a start that is intended to help get the ball rolling on implementation of Launch Template support within the CDK. It is a step towards resolving #6734 Launch Templates have value even without the integrations into Instance and AutoScalingGroup being implemented yet. Thus, the intention with this PR is to solely implement the L2 for LaunchTemplate. Future work in a separate PR would be required to implement its integration into Instance, AutoScalingGroup, and others. ---- *By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license*
anyone has a workaround to overcome this issue before it gets implemented (without using lc)? I got stuck with alb-listener-tg-asg-lt relationship. first line in https://docs.aws.amazon.com/autoscaling/ec2/userguide/LaunchConfiguration.html says "We strongly recommend that you do not use launch configurations." but if this ticket does not get priorities then I have to give up on cdk, not to mention this is first project i am using cdk. and this ticket is going to have its first birthday cake very soon... |
This provides an initial implementation of a level 2 construct for EC2 Launch Templates. It is a start that is intended to help get the ball rolling on implementation of Launch Template support within the CDK. It is a step towards resolving aws#6734 Launch Templates have value even without the integrations into Instance and AutoScalingGroup being implemented yet. Thus, the intention with this PR is to solely implement the L2 for LaunchTemplate. Future work in a separate PR would be required to implement its integration into Instance, AutoScalingGroup, and others. ---- *By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license*
This provides an initial implementation of a level 2 construct for EC2 Launch Templates. It is a start that is intended to help get the ball rolling on implementation of Launch Template support within the CDK. It is a step towards resolving aws#6734 Launch Templates have value even without the integrations into Instance and AutoScalingGroup being implemented yet. Thus, the intention with this PR is to solely implement the L2 for LaunchTemplate. Future work in a separate PR would be required to implement its integration into Instance, AutoScalingGroup, and others. ---- *By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license*
This provides an initial implementation of a level 2 construct for EC2 Launch Templates. It is a start that is intended to help get the ball rolling on implementation of Launch Template support within the CDK. It is a step towards resolving aws#6734 Launch Templates have value even without the integrations into Instance and AutoScalingGroup being implemented yet. Thus, the intention with this PR is to solely implement the L2 for LaunchTemplate. Future work in a separate PR would be required to implement its integration into Instance, AutoScalingGroup, and others. ---- *By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license*
This provides an initial implementation of a level 2 construct for EC2 Launch Templates. It is a start that is intended to help get the ball rolling on implementation of Launch Template support within the CDK. It is a step towards resolving aws#6734 Launch Templates have value even without the integrations into Instance and AutoScalingGroup being implemented yet. Thus, the intention with this PR is to solely implement the L2 for LaunchTemplate. Future work in a separate PR would be required to implement its integration into Instance, AutoScalingGroup, and others. ---- *By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license*
I was able to create a workaround for this. My specific need was to be able to set gp3 as the volume type and also set the burstable CPU credits to standard. I am using the L2 ECS constructs to create a cluster, then at the very end I create a launch template and replace the existing launch config. Credit to this site for setting me in the right direction: This is in C# but the concept should translate easily // Not shown: creation of the Cluster and the Auto Scaling Group with minimal instance launch config settings.
// Create launch template with the props we really want
var ec2LaunchTemplate = new LaunchTemplate(this, "ClusterLaunchTemplate", new LaunchTemplateProps
{
InstanceType = InstanceType.Of(InstanceClass.BURSTABLE3, InstanceSize.MEDIUM),
CpuCredits = CpuCredits.STANDARD,
MachineImage = MachineImage.FromSSMParameter(
"/aws/service/ami-windows-latest/Windows_Server-2004-English-Core-ECS_Optimized/image_id",
OperatingSystemType.WINDOWS),
SecurityGroup = ec2SecurityGroup,
Role = InstanceIamRole,
DetailedMonitoring = false,
BlockDevices = new[]
{
new Amazon.CDK.AWS.EC2.BlockDevice()
{
DeviceName = "/dev/sda1",
Volume = Amazon.CDK.AWS.EC2.BlockDeviceVolume.Ebs(
50,
new Amazon.CDK.AWS.EC2.EbsDeviceOptions
{
DeleteOnTermination = true,
VolumeType = Amazon.CDK.AWS.EC2.EbsDeviceVolumeType.GP3,
})
}
}
});
// Get the underlying CfnAutoScalingGroup from the L2 construct
// CDK escape hatch docs: https://docs.aws.amazon.com/cdk/latest/guide/cfn_layer.html
var cfnEc2Group = ((CfnAutoScalingGroup)ec2group.Node.DefaultChild);
// Remove the launch config from our stack
ec2group.Node.TryRemoveChild("LaunchConfig");
cfnEc2Group.LaunchConfigurationName = null;
// Attach the launch template to the auto scaling group
CfnLaunchTemplate cfnLaunchTemplate = (CfnLaunchTemplate)ec2LaunchTemplate.Node.DefaultChild;
cfnEc2Group.LaunchTemplate = new CfnAutoScalingGroup.LaunchTemplateSpecificationProperty
{
LaunchTemplateId = cfnLaunchTemplate.Ref,
Version = cfnLaunchTemplate.AttrDefaultVersionNumber
}; |
thanks @zstarkebaumcalico ! That was super helpful. Here's a TypeScript example that also uses Spot instances, based on the code above. Hacky but better than nothing until CDK supports launch templates and instanceDistribution.
|
Thanks for the Launch Template support! |
Looking at the workaround hack, I'm trying to instantiate an AutoScalingGroup with only parameters a LaunchTemplate does not contain, and before I can even cast that to a CfnAutoScalingGroup to take on the rest of config from the LaunchTemplate, its constructor complains Unhandled exception. Amazon.JSII.Runtime.JsiiException: Missing required properties for @aws-cdk/aws-autoscaling.AutoScalingGroupProps: instanceType, machineImage Guess have to include those redundant parameters. |
Is there any ETA for MixedInstancesPolicy? |
With AWS starting to sunset Launch Configurations, any ETA on when proper support for Launch Templates will come? |
Here is a WIP commit: Martin1994@07af2e8 I will send a PR shortly once I finish its unit tests, but any early feedback is welcomed, especially its design including breaking API changes, as the current ASG construct is deeply coupled with the usage of LC. I really wonder whether we take the next major version bump (saying CDK 2.0) as a chance to completely rework the ASG construct. |
I'm very eager to use Launch Templates on a new project. @Martin1994's changes look good, but I'm not sure if this would go into version 1 or 2. Is there any escape hatch that can be used in the meanwhile to achieve this using ASGs ? |
Another few months have gone by... Any updates on this? |
It's been almost 3 years since the initial request for Mixed Instance Auto Scaling groups, and 6 months since a PR has been opened implementing this feature. It's evident that many people are requesting this feature, so I have to ask: what is the hold up? And is there anything we as the community could do to speed up the process? |
Martin1994@07af2e8 hasn't been turned into a PR yet since its testing was missing. I will try to finish its testing this week and open a PR. |
Add support to launch an Auto Scaling Group from a Launch Template rather than a launch configuration. Closes aws#6734.
Add support to launch an Auto Scaling Group from a Launch Template rather than a launch configuration. Closes aws#6734.
Add support to launch an Auto Scaling Group from a Launch Template rather than a launch configuration. Closes aws#6734.
Hi everyone, any news on this? As I noticed, Launch Templates are recommended over Launch Configs. Today I created an ASG using the CDK, but I could not find a way to create the asg from a Launch Template. |
I believe you are still going to have to use CfnAutoScalingGroup for now. |
Add support to launch an Auto Scaling Group from a Launch Template rather than a launch configuration. Closes #6734. ---- High level designs: The current AutoScalingGroup L2 construct, unfortunately, is deeply coupled with LaunchConfiguration. Therefore adding LaunchTemplate to the existing construct is not trivial. There are two different approaches to support LaunchTemplate: 1. Implement another brand new L2 construct with `IAutoScalingGroup` interface. The shared logic between the old and the new one such as adding scaling policies can be extracted to a common parent class. 2. Add LaunchTemplate related interface to the existing L2 construct with minimum breaking changes. Adding a new construct is always guaranteed to be a clean solution code-wise, but it can also cause confusion from the end user about scattered CDK implementation on the same CFN resource, and on the other hand breaks the existing libraries consuming the existing `AutoScalingGroup` construct rather than the `IAutoScalingGroup` interface. Adding LT to the existing construct, as what this PR does, however may change the API behaviour when LT is used. For example, the implementation in this PR turns `AutoScalingGroup.connections` from a public field to a public getter, and will throw an error when the ASG is created from a LT reference, which means existing libraries taking an `AutoScalingGroup` instance as an `IConnectable` will get runtime error in this case. Existing code (i.e. ASG created from the L2 construct with a LC rather than a LT) won't break with this change. This PR picks the latter approach since I believe it provides a better experience overall, mainly because of its continuity. ---- BREAKING CHANGE: Properties relying on a launch configuration are now either optional or turned into throwable getters * **autoscaling:** `AutoScalingGroupProps.instanceType` is now optional * **autoscaling:** `AutoScalingGroupProps.machineImage` is now optional * **autoscaling:** `AutoScalingGroup.connections` is now a throwable getter * **autoscaling:** `AutoScalingGroup.role` is now a throwable getter * **autoscaling:** `AutoScalingGroup.userData` is now a throwable getter ---- *By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license*
|
Add support to launch an Auto Scaling Group from a Launch Template rather than a launch configuration. Closes aws#6734. ---- High level designs: The current AutoScalingGroup L2 construct, unfortunately, is deeply coupled with LaunchConfiguration. Therefore adding LaunchTemplate to the existing construct is not trivial. There are two different approaches to support LaunchTemplate: 1. Implement another brand new L2 construct with `IAutoScalingGroup` interface. The shared logic between the old and the new one such as adding scaling policies can be extracted to a common parent class. 2. Add LaunchTemplate related interface to the existing L2 construct with minimum breaking changes. Adding a new construct is always guaranteed to be a clean solution code-wise, but it can also cause confusion from the end user about scattered CDK implementation on the same CFN resource, and on the other hand breaks the existing libraries consuming the existing `AutoScalingGroup` construct rather than the `IAutoScalingGroup` interface. Adding LT to the existing construct, as what this PR does, however may change the API behaviour when LT is used. For example, the implementation in this PR turns `AutoScalingGroup.connections` from a public field to a public getter, and will throw an error when the ASG is created from a LT reference, which means existing libraries taking an `AutoScalingGroup` instance as an `IConnectable` will get runtime error in this case. Existing code (i.e. ASG created from the L2 construct with a LC rather than a LT) won't break with this change. This PR picks the latter approach since I believe it provides a better experience overall, mainly because of its continuity. ---- BREAKING CHANGE: Properties relying on a launch configuration are now either optional or turned into throwable getters * **autoscaling:** `AutoScalingGroupProps.instanceType` is now optional * **autoscaling:** `AutoScalingGroupProps.machineImage` is now optional * **autoscaling:** `AutoScalingGroup.connections` is now a throwable getter * **autoscaling:** `AutoScalingGroup.role` is now a throwable getter * **autoscaling:** `AutoScalingGroup.userData` is now a throwable getter ---- *By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license*
Is there any documentation regarding the AutoScaling and LaunchTemplates in CDKTF? |
Currently the CDK configures EC2 autoscaling using LaunchConfigurations, we should add support for Launch Templates which enables more advanced features such as:
The text was updated successfully, but these errors were encountered: