[Question]: Is it possible to add listeners (and target groups) to an existing ALB?
See original GitHub issueIs it possible to add listeners (and target groups) to an existing ALB? I’m getting an error Error: Can only call addTargets() when using a constructed Load Balancer; construct a new TargetGroup and use addTargetGroup
. What is the best way to share an existing ALB between (in my case Fargate) projects then?
From Fargate docs: https://awslabs.github.io/aws-cdk/refs/_aws-cdk_aws-ecs.html#include-a-load-balancer
I’m trying to do something similar as @nathanpeck did in https://github.com/nathanpeck/greeter-cdk
My target groups would be separate projects (i.e. /app1, /app2, etc) behind a shared ALB.
EDIT: This issue also relates to #1948. Our security team prevents us from creating roles, policies, SG, etc. So even if we could create an ALB (using elbv2.ApplicationLoadBalancer
) we cannot perform security group changes that cdk
is trying to introduce. Kinda catch 22. 😞
//Import existing VPC
const vpc = ec2.VpcNetwork.importFromContext(this, "VPC", {
vpcId: props.vpcId
});
//Import existing Security Group
const sg = ec2.SecurityGroup.import(this, "SecurityGroup", {
securityGroupId: props.securityGroupId
});
//Import ECS cluster
const cluster = ecs.Cluster.import(this, "Cluster", {
clusterName: props.clusterName,
securityGroups: [ sg ],
vpc: {
vpcId: props.vpcId,
availabilityZones: props.availabilityZones,
privateSubnetIds: props.subnets
}
});
//Import existing taskRole
const taskRole = iam.Role.import(this, "TaskRole", {
roleArn: `arn:aws:iam::${props.accountId}:role/csr-Task-Role`
});
//Import existing executionRole
const executionRole = iam.Role.import(this, "ExecutionRole", {
roleArn: `arn:aws:iam::${props.accountId}:role/csr-Execution-Role`
});
//Import existing ELB
const elb = elbv2.ApplicationLoadBalancer.import(this, "ALB", {
loadBalancerArn: props.loadBalancerArn,
securityGroupId: props.securityGroupId
});
//Create ECS Task definition
const fargateTaskDefinition = new ecs.FargateTaskDefinition(this, 'TaskDefinition', {
memoryMiB: "512",
cpu: "256",
taskRole: taskRole,
executionRole: executionRole
});
//Create a container for task definition
const container = fargateTaskDefinition.addContainer("Container", {
// Use an image from DockerHub
image: ecs.ContainerImage.fromDockerHub(props.dockerRepositoryUrl)
});
container.addPortMappings({
containerPort: props.port
})
//Create fargate service with corresponding task definition
const fargateService = new ecs.FargateService(this, "Service", {
cluster: cluster,
taskDefinition: fargateTaskDefinition,
desiredCount: 1,
securityGroup: sg
});
const lst = elb.addListener("Listener", {
port: props.port
});
lst.addTargetGroups("default", {
targetGroups: [
new elbv2.ApplicationTargetGroup(this, "default", {
vpc: vpc,
protocol: elbv2.ApplicationProtocol.Http,
port: props.port
})
]
});
lst.addTargets("demo", {
port: props.port,
pathPattern: props.path,
priority: props.priority,
targets: [ fargateService ]
})
Issue Analytics
- State:
- Created 5 years ago
- Reactions:7
- Comments:8 (8 by maintainers)
I somehow managed to make this work. Here is what I have ended up with…
It feels sooooo hacky to me (mixing L1 and L2 constructs) and I hope that in the future
cdk
will be more friendlier towards limited AWS environments (reusable ALBs, SG, roles etc).If there is more cleaner way to do this please let me know.
@rix0rrr I’ve implemented your suggestions (see code below).
However, now during deployment I’m being asked to approve SG changes.
When I implement your ingress/egress no-op suggestions from #1948 I’m still getting SG change when I try to deploy. If you recall, I work in an environment where I’m unable to create SGs, roles, policies, etc.
And here is what
cdk deploy
is trying to perform, so no-op approach is definitely doing something but only for ingress.Again, thank you so much for helping me figure this one out (and all other Github issues).