https://pulumi.com logo
Join Slack
Powered by
This message was deleted.
# general
s
This message was deleted.
w
cc @lemon-spoon-91807
l
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
Starting from an ApplicationListener
l
ah, in that case, start from an ApplicationTargetGroup
q
ah, ok I shall try that
l
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
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
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
well if I’m not creating a listener anymore
and I assume relying on awsx to create it for me
l
oh, you still are creating a listener:
Copy code
new awsx.elasticloadbalancingv2.NetworkTargetGroup("custom", { port: 8081 })
         .createListener("custom", { port: 80 });
q
ahhh
l
see the last bit: 
.createListener
er... that should be ApplicationTargetGroup
but you get the idea 🙂
q
yea
l
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
I see
l
good luck, and feel free to ping me if you run into issues!
q
Here’s a gist of what I’m doing: https://gist.github.com/c0bra/fcf2f5dfd83254061a5563e9ba0f8a5e
looks like the target is failing to register because it’s timing out
l
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
so
l
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
I wasn’t going to use rds initially. I was hoping to making things cheaper by hosting it all on one instance
l
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
so I needed permanent storage
I can use a Fargate service now I suppose
l
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
hmm
On the targetGroup: 
None of these Availability Zones contains a healthy target. Requests are being routed to all targets.
oh wait
l
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
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
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
um
This looks like it times out after 5 seconds
Open in Slack
PreviousNext
Powered by