https://pulumi.com logo
Join Slack
Powered by
<@UB9JVTW07> On the latest version of awsx package...
# general
a
@lemon-spoon-91807 On the latest version of awsx package, we cannot override the defaultAction to the below, without getting this error: 
[Listener] was not connected to a [defaultAction] that can provide [portMapping]s
. Do you know what might be happening?
Copy code
const httpsListener = targetGroup.createListener('https-443-listener', {
    certificateArn: options.certificateArn,
    defaultAction: {
      fixedResponse: {
        contentType: 'text/html',
        messageBody: '<!DOCTYPE html><title>404 - Not Found</title><body><h1>404 - Not Found',
        statusCode: '404',
      },
      type: 'fixed-response',
    },
    external: true,
    port: 443,
    protocol: 'HTTPS',
    sslPolicy: 'ELBSecurityPolicy-2016-08',
  });
l
looking
just so i know, what sort of TG is ths? a network TG, or application TG?
i assume the latter.
a
ALB target group
l
and this used to work?
can you show me your container using this?
a
Never done this before, we are trying to write a reusable function for this stuff, let me grab a snippet.
l
gotcha. 🙂
that makes more sense then
so, basically, you have a container somewhere where you're doing something like this: 
portMappings: [httpsListener]
when you pass a listener, we normally look at it's default target group to decide what port mapping you should have
but you've overridden htat. in that case, you should be able to do this: 
portMappings: [targetGroup]
a
ok, we will try it
l
here's a good picture:
note: when you do this, it doesn't make a ton o sense:
Copy code
ts
targetGroup.createListener('https-443-listener', {
    certificateArn: options.certificateArn,
    defaultAction: {
      fixedResponse: {
        contentType: 'text/html',
        messageBody: '<!DOCTYPE html><title>404 - Not Found</title><body><h1>404 - Not Found',
        statusCode: '404',
      },
      type: 'fixed-response',
    }
because you're basically not using any part of the TG for the listener
i.e. the listener doesn't do anythin with that TG, it literally just has a 'default action' that it performs, isntead of actually reaching out to a TG
does that make sense?
we have the tg.createListener entrypoint to effectively allow you to build from teh "bottom up" if you find that nicer to think about. arguably, we shouldn't let you pass in this 'defaultActoin' in that case. but we'd need to define an entirely new interface for the args then...
a
That seems to work, one sec, let me understand, cause the dispatching here is a little magical
l
but i can see how this would be misleading
happy to explain. and i can def see how this coudl confuse people 😞 (sorry!)
a
So the expectation of tg.createListener is really that you must pass an action that forwards to tg?
l
right. if you pass no defaultAction, then defaultAction is the TG (that's what we do on your behalf)
note: it's also only in thi case where we support the idea of passing the 'listener' to the portmappings
because then we can see that the TG is really what it's going to call into
and we literally just point the port-mappings at the TG.
if you do something else in there, we really have no insight as to what that is doing, so we need more detail for the container. sounds like we need much better error messages here too
a
Ok, I see, so really this defaultAction must always use the tg in some way, but in our code it was masked by the fact that we happened to call tg.createLister without a defaultAction earlier, causing a tg to be set, and then further calls would not blow up.
l
right.
a
ok I understand now. Yea, the errors on this are early which is good, but hard to debug. I think it would be best to take the ergo hit and make stricter types on the interface such that defaultAction.type must be forward or something like that.
The use case behind these listener actions was to drop traffic with the wrong host header, and forward only correct host traffic, avoid the bots and scanners clogging logs.
2 Views
Open in Slack
PreviousNext
Powered by