Support for YARP-based reverse proxy to use as ingress

[Kralizek]

In Tye we could define ingress nodes to route requests to the different services. From this comment, it seems that the idea is to leverage YARP.

It would be cool if we could have something built-in that could let me translate

ingress:
  - name: admin
    tags:
      - admin
    bindings:
      - port: 12000
        protocol: http
        name: http
    rules:
      - service: api
        path: /api/
        preservePath: false
      - service: admin-web
        path: /
        preservePath: true
  - name: app
    tags:
      - app
    bindings:
      - port: 12100
        protocol: http
        name: http
    rules:
      - service: api
        path: /api/
        preservePath: false
      - service: app-web
        path: /
        preservePath: true

into

var database = builder.AddPostgresContainer("database")
    .WithVolumeMount("../../data/database/data", "/var/lib/postgresql/data");

var apiService = builder.AddProject<Projects.API>("api")
    .WithReference(database);

var webAdmin = builder.AddProject<Projects.Admin_Web>("admin")
    .WithReference(apiService);

var webApp = builder.AddProject<Projects.App_Web>("app")
    .WithReference(apiService);

builder.AddIngress("app")
    .WithPath("/api/", apiService, preservePath: false)
    .WithPath("/", webApp, preservePath: true)
    .WithBinding(12100, "http");

builder.AddIngress("admin")
    .WithPath("/api/", apiService, preservePath: false)
    .WithPath("/", webAdmin, preservePath: true)
    .WithBinding(12000, "http");

builder.Build().Run();

[davidfowl]

I don’t think we want to build ingress into the app model. Given that we have YARP now, just make it one of your projects and configure it there with the service discovery extensibility. Take a look at eshop lite for an example.

https://github.com/dotnet/aspire/tree/main/samples/eShopLite/ApiGateway

[a-shoemaker]

I'm not exactly sure how everything works in Aspire yet, but seems like it would fit nicelly into the AppHost project as, for how we use it at least, it's a local dev thing. Only the configuration matters for taking to deployment. If not built in, guessing you can add your own stuff to the AppHost project perhaps?

(I feel how Dapr works or will work perhaps is relevant.)

[davidfowl]

Where are you deploying to? What extracts this configuration and does something in deployment? The advantage of making it a project with YARP is that it works like any of your other projects and is truly portable and doesn't need to be translated into some other form since it is your proxy project.

You can build an ingress resource that uses YARP under the covers in the apphost project itself (it can host another web server) but then you also need to support that mapping from ingress rules into whatever makes sense for your deployment.

I'll attempt to build a sample that you can use, but we won't be building this into the apphost, at least as of right now.

[a-shoemaker]

We have our own specification language (YAML configuration) and we dynamically create the tye.yaml for local dev or terraform / helm (values.yaml) for AKS deployment (we don't use Tye for deployments). So, it goes to K8 Ingress, we don't need/want our own C# project for an ingress component (it wouldn't be used in deployements). We utilize dapr with communication through the side cars. The ingress gives us the nice single static port to use with the path that matches the deployment and everything else uses "service discovery" (dynamic ports in local dev).

I would for sure vote this item up. To me it makes total sense to be integrated into Aspire, the manifest/tooling/dashboard, etc. This is potentially something that will keep us from using Aspire anytime soon. But this could also be due to me not fully understanding Aspire yet...

[Kralizek]

I understand what you suggest and I understand the complexity of the mapping/rewrite rules.

But now I need to pollute my src/ directory with a project and code that is only to facilitate local development.

Probably the example I posted isn't the best one because you dont really need the ingress in this case.

The other case I use the ingress is in a react+aspnet core app.

We deploy the react bits on a Azure Static Site and let access the backend with relative paths instead of having to sissle around with hostnames to be passed in the react build process.

This deployment solution really works well for us and being able to easily replicate this behavior locally was a huge thumb up for Tye.

On the other hand, being forced to roll out my own mapping project only for development purpose feels a bit of a let down for a "development inner cycle" tool.

[davidfowl]

So, it goes to K8 Ingress, we don't need/want our own C# project for an ingress component (it wouldn't be used in deployements)

This is the design of the YARP ingress. You make a project and you deploy it to K8s.

The app model is fully extensible C# you can build this yourself, in fact this is a feature. I'd urge you to attempt to build this if it's something you need and give us some feedback about how extensible the app model is for these situations. We're not going to build generic ingress mapping to various proxies. YARP based ingress for development only is a sweet spot.

That said, I look forward to customers extending the platform for their needs.

[Kralizek]

Hi @davidfowl
I'm trying to giving it a shot here: https://github.com/Kralizek/AspireIngress (see the AspireIngress.Resources project)

I could use some pointers on how to hook into the resource creation after it has been defined. I went through the repo looking at how projects and containers are created but I think I miss something.

Also, I can't find the source generator that takes care of creating the service metadata classes for the referenced projects.

[davidfowl]

I have a spike of this, I'll be able to share tomorrow hopefully.

[Kralizek]

Hi @davidfowl

Is there any documentation on how to communicate with the DCP (which I guess is the component that does all the magic here)?

I'm really stuck at understanding how the flow to get Aspire to create a custom resource is.

Thanks!

[davidfowl]

This wouldn't be a DCP resource. DCP is the kubernetes API and it supports containers and executables (https://github.com/dotnet/aspire/tree/main/src/Aspire.Hosting/Dcp/Model). The ingress resource would either need to run directly in the app host or be another process that runs as part of DCP orchestration. That's why it's so attractive making it a project.

[Kralizek]

That's why it's so attractive making it a project.

My idea was to create a "hidden" project. With just the YARP setup extrapolated from the annotations.

[davidfowl]

@Kralizek where is this hidden project?

[Kralizek]

Well, hooking into the pipeline of creation of resources/project is what I'm trying to understand :)

That's why I was looking for some pointers on what to look at.