ALB / ECS Upgrade path (host-based routing)

Gruntwork Customers
1

This message is extracted from a ticket originally emailed to support@gruntwork.io. Names and URLs have been removed where appropriate.

Following a previous discussion, I have been looking into defining an upgrade path for our modules to be able to use host-based routing.

Do you have any other customer that went through this upgrade or do you have any documentation to minimize the trial-and-error part of it?

2

The relevant release notes, including the hyperlinked PRs, have some useful info:

https://github.com/gruntwork-io/module-ecs/releases/tag/v0.6.0
https://github.com/gruntwork-io/module-load-balancer/releases/tag/v0.6.0

We’ve had a few customers take advantage of this. Are there specific issues you’re struggling with?

The main changes are:

  1. Bump the version number on your usage of the alb module and redeploy.
  2. Bump the version number on your usage of the ecs-service-with-alb module and remove the alb_listener_arns and alb_listener_rule_configs params.
  3. Instead of those params, use the aws_alb_listener_rule resource directly to create your routing rules.
    Here are a few examples: https://github.com/gruntwork-io/module-ecs/blob/master/examples/docker-service-with-alb/main.tf#L222-L307.

Does that help?

3

Thanks Jim.

I think that part of my issue is that I am not sure of where I should declare the aws_alb_listener_rule resource.
According to the example you linked, this would be in https://github.com/redacted/infrastructure-modules/blob/master/services/ecs-service/main.tf

But doing so the "${lookup(module.alb.https_listener_arns, "443")}" call is failing :

resource 'aws_alb_listener_rule.host_based' config: unknown module referenced: alb

Also this would hardcode the rule priority to 95.

So in short there is something that I don’t understand here.

Thanks for your help!

4

I think that part of my issue is that I am not sure of where I should declare the aws_alb_listener_rule resource.

In infra-modules, in whatever modules need to have the ALB route to them. Typically, these will be the modules for your ECS services.

But doing so the “${lookup(module.alb.https_listener_arns, “443”)}” call is failing :
resource ‘aws_alb_listener_rule.host_based’ config: unknown module referenced: alb

In the example code, the ALB is defined using a module in the same file, so it is being referenced using module.alb. For you, since you have one ALB shared amongst multiple services, it is defined in a separate module, and you pull in the information for it using a terraform_remote_state data source. Therefore, you’d need to replace module.alb.https_listener_arns with something like data.terraform_remote_state.alb.https_listener_arns.

Also this would hardcode the rule priority to 95.

You have two general approaches you can take:

  1. Each of your ECS services gets its own module, where it declares its own listener rules, and hard-codes the priorities for them. As long as those priorities don’t overlap, since you use separate ALBs in each environment, this will work fine.
  2. You can try to create a more generic ECS module that takes in a list of priorities, ports, paths, etc and to generate the listener rules dynamically using the count parameter and lots of interpolation functions. This would be more dynamic/reusable, but probably harder to reason about.
5

Thanks Jim!

data.terraform_remote_state.alb.https_listener_acm_cert_arns was what I needed, it works as expected now. I’ll have to take care of the rules priority now.