I seem to have an odd chicken and the egg situatio...
# aws
b
I seem to have an odd chicken and the egg situation. I'm standing up an ECS Fargate Cluster/Service/ALB/Target Group. However, when I do it from scratch, the Service fails to create the first time because the target group isn't associated with the load balancer, but the app autoscaling target fails to associate them because the Service doesn't exist. How can I get it to do things in the right order? If I simply run up again, it builds everything left immediately and finishes without issue.
Here's our function. Our structure is to parameterize everything, and then each environment has a very simple index.ts that gathers the correct values for that environment and then passes them to this function.
q
If I understood correctly, the problem is that the ECS service gets created before the target group and ALB are connected. Can you try adding an explicit dependency (
dependsOn
) on the listener to the definition of the ecs service? Something like this:
Copy code
const service = new aws.ecs.Service(`${envStub}-service`, {/*...*/}, { dependsOn: [listener] });
b
Not exactly. The TG getting attached to the LB is waiting on the TG to not be empty, but it's empty because the service isn't up yet, because the TG isn't attached to the LB. It finally times out and those two actions fail with those reasons, and if I immediately UP again, they both finish creating in 10 seconds.
I'll have to dig deeper into dependsOn. I must have been adding it in the wrong place, because it was saying that wasn't defined
q
IIRC you should be able to attach an empty target group to an ALB. I don't recall it checking for registered targets.
b
That's what I expected to happen, yeah. Later tonight I'll destroy it and start over and catch the exact error, but I had to reboot and lost it in my console
q
Sounds good! If you need some more details about
dependsOn
have a look here: https://www.pulumi.com/docs/concepts/options/dependson/
b
Here's the errors, even after I added the dependsOn [listener]
q
And to confirm, the target group this is complaining about is the one that's referenced in the listener? Can you show your ECS service config after the changes?
b
sigh laptop on my lap, I put the dependsOn in the wrong place. One moment, another destroy and up in progress
So, dependsOn kept it from trying the service, but the autoscaling target, which is what's connecting the TG to the ALB, won't go without it?
q
The
scaling_target
needs a dependency on the ECS service. You could either add the depends on or change the resource id to reference the service object.
b
Ok, I got it to work. I had to put two dependsOn in place, and now they finish in the right order. Some of this is because the service creation does not result in an output that's easily compatible with the resourceID of the autoscaling.target, so I'm naming it with a created value. Therefore it doesn't know to wait on it. So that's something that would probably help
lol, jinx
q
Hehe 🙂 You could assemble the resourceId using the
name
output of the ECS service. This would also set the dependency. Something like this:
Copy code
const scaling_target = new aws.appautoscaling.Target(
    `${envStub}-lb-scaling-target`,
    {
      maxCapacity: 25,
      minCapacity: 2,
      resourceId: pulumi.interpolate`service/${envStub}-cluster/${service.name}`,,
      roleArn: vpc_consts.scalingRole,
      scalableDimension: "ecs:service:DesiredCount",
      serviceNamespace: "ecs",
    }
  );
b
oooh, I like that. I think I was stuck trying to build both the cluster and service names into a string with ` and ${}. I'll try that next, and also see if I can do something similar to the listener to remove its dependsOn as well. I'd much rather Pulumi be free to analyze and optimize than me forcing blockers
q
I think with the listener it's a bit more problematic because the service has no direct dependency on it. It's rather a 'connecting' resource in AWS' API
b
oh, got it. Ok, 1 is still better than 2, lol
q
Have you had a look at Pulumi Crosswalk for AWS? https://www.pulumi.com/registry/packages/awsx/ It has higher level components for LBs and ECS that can simplify this setup for you: https://github.com/pulumi/pulumi-awsx?tab=readme-ov-file#pulumi-aws-infrastructure-components
b
I did, but when I started, it didn't seem to support all the things I needed, and I really preferred to stay with just one package for simplicity, and of the 3, aws classic was the only one that seemed to do everything I wanted. When I'm on the other side of this massive urgent project, I might give it another shot, though. It seemed better for this on paper, for sure. Next on my list is to learn how to deploy Babelfish with Amazon Aurora, as I'd love to get rid of SQL Server forever someday. 🙂
Your suggested change worked. Fully deployed in just under 3 minutes! Thanks!
q
That makes sense! Once you try it out please let us know what you think about it 🙂 Happy to help!
b
I'm seeing very little in the docs referring to AWS Babelfish (however, apparently alibaba cloud has an identical service?)
q
For babelfish you need to set some parameters in the cluster parameter group. This should do the trick:
Copy code
"rds.babelfish_status": ["on", "pending-reboot"]
  "babelfishpg_tds.tds_ssl_encrypt": ["1", "immediate"]
b
Awesome. I'll set a reminder for this in about a week, when hopefully I'll have time, lol
q
Let me know if it works when you get to it 🙂
b
Will do!