https://pulumi.com logo
Join Slack
Powered by
Also tried setting `associatePublicIpAddress: true...
# general
f
Also tried setting 
associatePublicIpAddress: true
in 
launchConfigurationArgs
when calling 
createAndAddAutoScalingGroup
. Still no change to the Auto-assign public IP field.
b
@lemon-spoon-91807 Any ideas on this?
f
Not sure if this is relevant but according to [1], the valid values for 
assignPublicIP
are 
"ENABLED" | "DISABLED"
. Pulumi takes a boolean for that value. [1] https://docs.aws.amazon.com/AmazonECS/latest/developerguide/service_definition_parameters.html
b
I just looked at the underlying implementation, and it definitely looks like boolean is correct. I wonder if we're not passing it down to the underlying ECS resource definition.
f
Perhaps. Where is the ECS resource defined?
l
it's in: experimental/ecs/Service.ts
Still no change to the Auto-assign public IP field.
what are you looking at that is showing that data?
f
ECS console.
l
can you show me specifically?
f
From the ECS console
l
that's currently something set on hte loadbalancer
that code is currently in experimental/ecs/loadBalancer.ts
f
I don't have a load balancer.
l
(but i'm rewriting it all in tihs milestone)
can you link me to a gist of your code?
f
l
so, what is likely happening is that we are using your default network and using that for the networkconfiguration piece
or, this is just hardcoded as:
Copy code
networkConfiguration: {
                assignPublicIp: false,
                securityGroups: cluster.securityGroups.map(g => g.instance.id),
                subnets: cluster.network.subnetIds,
            },
f
It is using the default network. All subnets in are set to auto assign a public IP.
l
this comes from how we originally did things in pulumi-cloud:
Copy code
networkConfiguration: {
                assignPublicIp: config.useFargate && !network.usePrivateSubnets,
                securityGroups: securityGroups,
                subnets: network.subnetIds,
            },
f
This is the cluster def:
Copy code
const cluster = new infra.x.ecs.Cluster("fibonacci", {
    name: "fibonacci",

});
l
will have to update this to allow you to pass in this info, or to base it entirely off the network
f
So right now it is basing it on the cluster's 
network
?
l
right now it's explicitly passing in 'false'
it's hardcoded as:
Copy code
networkConfiguration: {
                assignPublicIp: false,
                securityGroups: cluster.securityGroups.map(g => g.instance.id),
                subnets: cluster.network.subnetIds,
            },
f
Gotcha.
l
for fargate we base this on hte network. for ec2 we just set it to false
no good reason for us to do that though
(it's just how the code moved down from 'cloud' to here)
i'll update it to allow you to pass your own config
f
Great, thanks! How are you going to allow it to be passed in?
l
like how your gist shows it
👌 1
cheers!
f
Anyway we could get a dev release of aws-infra?
l
Let me see what it would take to get that!
oh... there should be a dev release of it
we're making both dev and normal builds
f
Looks like the last dev release was 8 days ago. No?
l
ah. you mean a more recent drop
gotcha!
let me see why my latest cahnge didn't go make one
f
l
super strange!
that should have automatically made a new drop
have to go investigate 🙂
infrastructure is hard 😄
f
True that
l
someone needs to make infrastructure easier
😆 1
f
I checked out the code locally for the time being. I am getting this exception when running `pulumi up`:
Copy code
updating urn:pulumi:fibonacci-dev::fibonacci::awsinfra:x:ecs:EC2Service$aws:ecs/service:Service::datadog-daemon: InvalidParameterException: Assign public IP is not supported for this launch type.
l
i mean... is that something aws supports?
f
No idea. ECS design decisions continue to confuse me.
Any idea if there is another way to give ECS containers access to the internet? I see lots of people suggesting NATs but that doesn't make sense to me. Why would I need to deploy 3 NATs (one per AZ) for my containers to connect to the internet when my ECS EC2 nodes can connect just fine?
Yikes [1] :
The awsvpc network mode does not provide task elastic network interfaces with public IP addresses for tasks that use the EC2 launch type. To access the internet, tasks that use the EC2 launch type must be launched in a private subnet that is configured to use a NAT gateway. For more information, see NAT Gateways in the Amazon VPC User Guide. Inbound network access must be from within the VPC using the private IP address or DNS hostname, or routed through a load balancer from within the VPC. Tasks launched within public subnets do not have outbound network access.
[1] https://docs.aws.amazon.com/AmazonECS/latest/developerguide/task-networking.html
l
trying to read up on i now
but i'm in a similar boat that i find AWS super confusing here 🙂
but this sounds like this simply may be by-design on their part
if you figure things out, let me know 🙂
btw, any reason not to use fargate?
it seems like the simpler "get me out of this complexity hell" approach that AWS is offering.
f
You cannot use Datadog's APM service.
Datadog APM requires access to the docker sock.
l
interesting
does DD recommend how you set things up?
f
l
do they have a walkthrough on the appropraite way to configure the service to work on ec2 in a way that is also public?
f
I think they leave the public part for you to figure out on your own. Does seem a bit strange.
l
This documentation assume you already have a working EC2 Container Service cluster configured. If not, review the Getting Started section in the ECS documentation.
yeah... great 😕
yeah, everything i run into mentions 'nat', with zero extra information
it's all so vague
f
Right... It's so weird that there isn't more info on this. I'd imagine almost all production services require access to the internet...
l
my understanding is this is why you have an LB
the LB faces the internet
and the LB is configured to hit your containers.
f
Right but most internal services require access to the internet for doing 3rd party operations.
l
i think this is by-design on their part. your stuff is isolated. and if you want thins to be able to talk to internet, you need to set upthe appropriate mechanisms to allow this.
f
Which is fair but that makes the cost of running an ECS cluster higher -- you need to pay for 3 NATs in addition to your ECS instances.
Open in Slack
PreviousNext
Powered by