Support Multiple Hosts for a Route

[stevejgordon]

As per this Twitter thread, I recently configured NGINX to support local development of a multi-tenant service.

The configuration is as follows...

To replicate this it seemed to required multiple routes, which for numerous tenant domains would be painful.

I understand it is planned to remove the requirement for the host in which case, path matching for all hosts would occur. However, we also need to match specific paths for each host to different services.

[samsp-msft]

Would changing host to be an array solve the problem for you?

[saithis]

We have a similar scenario and changing host to be an array would solve it for us.

[stevejgordon]

Yes it would @samsp-msft

[Tratcher]

@stevejgordon we expect many of our customers will use a programmatic approach to set up large deployments. Do you expect to stick with the config file approach long term?

[Tratcher]

#164 proposes a grouping feature that could help here. In theory the above config could have everything grouped except for the route id and host.

[saithis]

@Tratcher For our scenario there could be a few hundred hosts all with the same route. We plan to use the programmatic approach, but wouldn't it be better to define the route once with a hosts array instead of creating the same route for each host?

[Tratcher]

@saithis from an implementation perspective there's a limit here based on what AspNetCore routing supports. Right now I think you can only specify zero or one host per route.

The config could still be array based but the implementation may have to copy that into multiple routes.

How many of these hosts could be consolidated using a single wildcard (*.example.com)? I think that's already supported by routing.

[saithis]

All of them are like customername.example.com and most of the time all but a few have the same route, but while we are rolling out a new release, we will switch them over one by one to a new route.

So maybe we could add a *.example.com host for the most used route and only add the others individually (if the proxy prioritises the individual routes over the wildcard one). But in the middle of upgrading, we would still have to add half of them individually.

Also if we rush the release out, then the config would change multiple times per minute until all customers are updated. So the fewer config objects we have to create, the better.

[stevejgordon]

@stevejgordon we expect many of our customers will use a programmatic approach to set up large deployments. Do you expect to stick with the config file approach long term?

If it were just me, programmatic would appeal in some cases. However, much of this layer is managed by a systems team and there config would likely be preferred. That could change with something like YARP where it could become more of a dev service.

Right now we manage three sites for each client under their own domains which route to us. In some cases the three domains will be on the same hierarchy, but sometimes not. With hundreds of clients this grows quite rapidly.

For a simple local dev proxy I'd be happy to configure in code.

Offhand I'm not sure what our current NGINX configs looks like for prod. Everything is fronted by CloudFront and some host infoand client identifiers is stamped onto headers routed on from there. I'll see if I can get my hands on some more details on what that looks like in production at the moment.

We also have some Kong gateways in the chain for Auth requirements. Our infrastructure is quite complex as we're breaking a monolith down into microservices. So we have layers of routing as we migrate over. Over time we can simplify that.

[Tratcher]

@stevejgordon let me clarify. What I mean programmatically setting up routes is pulling them from a database or similar. It seems like anyone generating a large config file wouldn't be doing it by hand, they'd already have that data in some other source that you could pull or push from directly.

[stevejgordon]

I can imagine a case where we have the domains stored somewhere such as a DB and there we also maintain a list of paths to services elsewhere and then we build the routes based on those. I guess we could equally pre-build a final route config in some store based on those sources as and when they change.

[samsp-msft]

We think the scenario for the customer is better handled by programmatic route generation.
Moving to backlog as something to reconsider post v1.

[Tratcher]

Nevermind, multiple hosts per route is already a first class concept in aspnetcore routing.
https://github.com/dotnet/aspnetcore/blob/90511e60390b5aa74669d8b4f812a82a622a0feb/src/Http/Routing/src/HostAttribute.cs#L41

Bumping out of backlog for re-triage, this is worth supporting.