https://pulumi.com logo
#general
Title
# general
f

full-dress-10026

12/11/2018, 1:43 AM
Also tried setting
associatePublicIpAddress: true
in
launchConfigurationArgs
when calling
createAndAddAutoScalingGroup
. Still no change to the Auto-assign public IP field.
b

big-piano-35669

12/11/2018, 1:45 AM
@lemon-spoon-91807 Any ideas on this?
f

full-dress-10026

12/11/2018, 1:50 AM
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

big-piano-35669

12/11/2018, 1:54 AM
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

full-dress-10026

12/11/2018, 1:58 AM
Perhaps. Where is the ECS resource defined?
l

lemon-spoon-91807

12/11/2018, 2:03 AM
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

full-dress-10026

12/11/2018, 2:04 AM
ECS console.
l

lemon-spoon-91807

12/11/2018, 2:04 AM
can you show me specifically?
f

full-dress-10026

12/11/2018, 2:04 AM
From the ECS console
l

lemon-spoon-91807

12/11/2018, 2:06 AM
that's currently something set on hte loadbalancer
that code is currently in experimental/ecs/loadBalancer.ts
f

full-dress-10026

12/11/2018, 2:07 AM
I don't have a load balancer.
l

lemon-spoon-91807

12/11/2018, 2:07 AM
(but i'm rewriting it all in tihs milestone)
can you link me to a gist of your code?
l

lemon-spoon-91807

12/11/2018, 2:09 AM
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

full-dress-10026

12/11/2018, 2:11 AM
It is using the default network. All subnets in are set to auto assign a public IP.
l

lemon-spoon-91807

12/11/2018, 2:12 AM
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

full-dress-10026

12/11/2018, 2:12 AM
This is the cluster def:
Copy code
const cluster = new infra.x.ecs.Cluster("fibonacci", {
    name: "fibonacci",

});
l

lemon-spoon-91807

12/11/2018, 2:12 AM
will have to update this to allow you to pass in this info, or to base it entirely off the network
f

full-dress-10026

12/11/2018, 2:13 AM
So right now it is basing it on the cluster's
network
?
l

lemon-spoon-91807

12/11/2018, 2:13 AM
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

full-dress-10026

12/11/2018, 2:14 AM
Gotcha.
l

lemon-spoon-91807

12/11/2018, 2:14 AM
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

full-dress-10026

12/11/2018, 2:15 AM
Great, thanks! How are you going to allow it to be passed in?
l

lemon-spoon-91807

12/11/2018, 2:15 AM
like how your gist shows it
👌 1
cheers!
f

full-dress-10026

12/11/2018, 5:26 PM
Anyway we could get a dev release of aws-infra?
l

lemon-spoon-91807

12/11/2018, 5:45 PM
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

full-dress-10026

12/11/2018, 5:58 PM
Looks like the last dev release was 8 days ago. No?
l

lemon-spoon-91807

12/11/2018, 5:58 PM
ah. you mean a more recent drop
gotcha!
let me see why my latest cahnge didn't go make one
f

full-dress-10026

12/11/2018, 5:59 PM
l

lemon-spoon-91807

12/11/2018, 5:59 PM
super strange!
that should have automatically made a new drop
have to go investigate 🙂
infrastructure is hard 😄
f

full-dress-10026

12/11/2018, 5:59 PM
True that
l

lemon-spoon-91807

12/11/2018, 6:00 PM
someone needs to make infrastructure easier
😆 1
f

full-dress-10026

12/11/2018, 7:16 PM
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

lemon-spoon-91807

12/11/2018, 7:17 PM
i mean... is that something aws supports?
f

full-dress-10026

12/11/2018, 7:18 PM
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

lemon-spoon-91807

12/11/2018, 7:25 PM
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

full-dress-10026

12/11/2018, 7:29 PM
You cannot use Datadog's APM service.
Datadog APM requires access to the docker sock.
l

lemon-spoon-91807

12/11/2018, 7:30 PM
interesting
does DD recommend how you set things up?
f

full-dress-10026

12/11/2018, 7:30 PM
l

lemon-spoon-91807

12/11/2018, 7:30 PM
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

full-dress-10026

12/11/2018, 7:31 PM
I think they leave the public part for you to figure out on your own. Does seem a bit strange.
l

lemon-spoon-91807

12/11/2018, 7:31 PM
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

full-dress-10026

12/11/2018, 7:35 PM
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

lemon-spoon-91807

12/11/2018, 7:36 PM
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

full-dress-10026

12/11/2018, 7:37 PM
Right but most internal services require access to the internet for doing 3rd party operations.
l

lemon-spoon-91807

12/11/2018, 7:39 PM
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

full-dress-10026

12/11/2018, 7:41 PM
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.