https://pulumi.com logo
q

quick-action-34599

04/18/2019, 5:59 PM
what’s the right way to forward from an
awsx.elasticloadbalancingv2.ApplicationListener
to a port on an ecs service other than the port that it’s listening on? i.e. the AL listens on port 80 and forwards to port 8081 on the container. I assume you can’t pass the listener itself as an argument to the container’s
portMappings
?
w

white-balloon-205

04/18/2019, 5:59 PM
cc @lemon-spoon-91807
l

lemon-spoon-91807

04/18/2019, 5:59 PM
One sec
You can basically do this:
Copy code
new awsx.elasticloadbalancingv2.NetworkTargetGroup("custom", { port: 8081 })
         .createListener("custom", { port: 80 });
(would have to see your cde to know the best way to structure). i.e. are you manually making a target group today, are you starting from an LB, etc.
q

quick-action-34599

04/18/2019, 6:01 PM
Starting from an ApplicationListener
l

lemon-spoon-91807

04/18/2019, 6:02 PM
ah, in that case, start from an ApplicationTargetGroup
q

quick-action-34599

04/18/2019, 6:02 PM
ah, ok I shall try that
l

lemon-spoon-91807

04/18/2019, 6:03 PM
terrific. let me know how it goes 🙂
technically, you can start from an AppListener too, you'd just need to pass in the AppTargetGroup as it's [defaultAction] argument
i personally think it reads more clearly to just start with the AppTargetGroup.
q

quick-action-34599

04/18/2019, 6:04 PM
OK then how would I assign it to the container?
Can I pass the targetGroup to portMappings like I would a listener?
seems like typescript likes it
l

lemon-spoon-91807

04/18/2019, 6:05 PM
you'd still take your listener, and pass that into [portMappings]
you don't need to change teh container/service side of things
just checked. you're right. we support passing either.
so whichever you feel best fits your intuition on how this all hooks up. TG actually fits well here.
q

quick-action-34599

04/18/2019, 6:07 PM
well if I’m not creating a listener anymore
and I assume relying on awsx to create it for me
l

lemon-spoon-91807

04/18/2019, 6:07 PM
oh, you still are creating a listener:
Copy code
new awsx.elasticloadbalancingv2.NetworkTargetGroup("custom", { port: 8081 })
         .createListener("custom", { port: 80 });
q

quick-action-34599

04/18/2019, 6:07 PM
ahhh
l

lemon-spoon-91807

04/18/2019, 6:07 PM
see the last bit:
.createListener
er... that should be ApplicationTargetGroup
but you get the idea 🙂
q

quick-action-34599

04/18/2019, 6:07 PM
yea
l

lemon-spoon-91807

04/18/2019, 6:08 PM
listener says what it's open on. then it has the 'default target', which tehn has the port that is forwarded to
both work as 'port mappings' as they both know about each other.
q

quick-action-34599

04/18/2019, 6:08 PM
I see
l

lemon-spoon-91807

04/18/2019, 6:13 PM
good luck, and feel free to ping me if you run into issues!
q

quick-action-34599

04/18/2019, 6:14 PM
looks like the target is failing to register because it’s timing out
l

lemon-spoon-91807

04/18/2019, 6:17 PM
hrmm
not sure. can you see any logs for this in aws?
because it would be interesting to see why it thinks it can't reach stuff
also, have you considered Fargate here? or is EC2 critical?
q

quick-action-34599

04/18/2019, 6:19 PM
so
l

lemon-spoon-91807

04/18/2019, 6:19 PM
one thing you can do to help with diagnosing this is to set:
waitForSteadyState: false
on your EC2Service
that way everything will get deployed.
q

quick-action-34599

04/18/2019, 6:19 PM
I wasn’t going to use rds initially. I was hoping to making things cheaper by hosting it all on one instance
l

lemon-spoon-91807

04/18/2019, 6:20 PM
you'll still have the same issue. but you'll at least have the AWS console to look at logs to figure out why ECS thinks things are not in good state.
q

quick-action-34599

04/18/2019, 6:20 PM
so I needed permanent storage
I can use a Fargate service now I suppose
l

lemon-spoon-91807

04/18/2019, 6:21 PM
for example, it might be taht something about your memory/cpu needs just can't be satisfied, and ECS is constantly failing to be able to spin things up appropraitely
but the logs would at least go toward diagnosing things.
settings
waitForSteadyState: false
at least gets you in a position where you can start interrogating AWS to see what issue they have.
q

quick-action-34599

04/18/2019, 6:25 PM
hmm
On the targetGroup:
None of these Availability Zones contains a healthy target. Requests are being routed to all targets.
oh wait
l

lemon-spoon-91807

04/18/2019, 6:27 PM
right.. so there's something that is seeminly preventing ECS from thinking it can spin up healthy containers to saitsfy your autoscaling needs.
(note: figuring this stuff out can be a PITA for sure)
i find fargate an easier place to at least start as it removes a bunch of complexity
q

quick-action-34599

04/18/2019, 6:32 PM
ok
lol well I’ve got a public IP on my fargate service now
so that’s closer!
maybe the health check is too quick?
l

lemon-spoon-91807

04/18/2019, 6:43 PM
maybe. but we also can't control that unfortunatley
it's baked into AWS as 10 minutes 😕
it's something that has annoyed me as well in the past
they basically just expose this functionality as a single bool, and that bool has the 10 minute behavior baked in.
q

quick-action-34599

04/18/2019, 6:46 PM
um
This looks like it times out after 5 seconds