Proxy is supplied as a pre-built docker image

[Tratcher]

We've proposed shipping YARP in three formats:

• A library - https://www.nuget.org/packages/Microsoft.ReverseProxy/
• A template - https://github.com/microsoft/reverse-proxy/issues/77
• A pre-built application exe #261
• A docker image (this issue)

The pre-built app should:

• Read from a config file
• Cover basic scenarios
• Support a variety of platforms

Scenarios

• Config based routes, clusters, & backends
• Remote route config? E.g. load from a database, service fabric, k8?
• Dashboards? https://github.com/microsoft/reverse-proxy/issues/123
• Health checks for the proxy itself.
• Static files? https://github.com/microsoft/reverse-proxy/issues/187
• Auth?
• Multi-instance?
  • Data protection (Session Affinity)
• Single-file exe with linking: https://github.com/microsoft/reverse-proxy/issues/7
• Config UI? https://github.com/microsoft/reverse-proxy/issues/184

Config

The library already supports loading routes from a config file. However, an app will need to expose additional config for the scenarios described above.

Platforms

• Windows, Mac, Linux
• Builds for both runtime dependent and standalone (servicing?)

Acquisition

• Microsoft download center?

[b0]

Is there use for a docker image with this pre-built application exe as another shipping format?

[Tratcher]

@b0 as an ingress controller (https://github.com/microsoft/reverse-proxy/issues/200) or as a simplified deployment model?

Packaging this exe up into a pre-built container would be one step to consider beyond the development of the exe itself (e.g. additional work item). I'd primarily wonder about the configuration story in that case.

[b0]

@Tratcher I find both usable. It's possible to host containers in Azure App Service too(OpenShift, etc...) so a plain docker image could have value. As of configuration story for that kind of container I find docker volumes and a plain json file YARP already support more then sufficient... Hope this have sense for you?

[Tratcher]

@b0 Good to know. We may split containerizing out into a separate issue when we get around to working on the exe scenario.

[samsp-msft]

Is this about having a pre-built container image for YARP, or having a docker file so that customers can build their own images? For configuration does the config file have to live next to the binary, or is there a way that config can be directed to be loaded from another well-known location that could then be mapped to being stored elsewhere by docker.

[b0]

It's about pre-built image with everything ready for running. Configuration file(routes, destinations, etc...) doesn't need to be inside image nor next to binary but can be provided via docker volumes - pretty standard way of doing things. Volumes are the way to load config from other location and not keeping it next to binary.

[samsp-msft]

From the comments it seems like creating a docker image is also popular. As this issue had the comments, I have changed this to be creating a docker image, and forked a new issue #261 to track the stand alone exe.

[lukemcdo]

This would just be a small layer on top of the existing ASP.NET images, right?

[Tratcher]

@lukemcdo correct, just adding the YARP library and a standard Startup + config.

[damianog]

@Tratcher is it possible to configure the endopoint to map the reverse proxy on the standard ports 80,443 and route request from another port like 81 to a classic MVC controller route?

.MapWhen(p => p.Request.Host.Port == 81, etc.. 

What I want to do is a yarp service with a simple mvc backend with authentication from which to configure routes and clusters and save them on a static file or a sqlite db.

Thanks in advance.

[Tratcher]

@damianog that seems unrelated to this topic, please start a new discussion thread.

I think you could do this with Host based routing, something like [Host("*:81")] https://docs.microsoft.com/en-us/aspnet/core/fundamentals/routing?view=aspnetcore-5.0#host-matching-in-routes-with-requirehost

[PureKrome]

Hi Team - with YARP 1.0 now RTM'd, is there plans to review this issue (an official docker image) for vNext ?

Sure, the docker image can only service a number of scenario's, but it would be a pretty large suite, IMO. Could really help with competing with other RP's.

[samsp-msft]

We can, but I don't think that really shows off the benefits of YARP - being able to customize the way it handles the non-simple cases - such as authentication, dynamic config etc. If you don't need that, you won't get a great deal of benefit out of YARP compared to other RPs.

[PureKrome]

@samsp-msft : ok, maybe I could ask the question in another way. What's the most benefit one person could get from a docker'd instance of YARP via providing a config file? Surely an Out-of-the-box with a config file docker-instance can handle a large common number of scenario's?

Like for example, I want to use YARP instead of Traefik:

• Given these routes, direct them to these backend destination/server(s)/"clusters".
• Log metrics to this-metrics-server (so I can see stuff)
• expose the dashboard so I can see stuff

and this is (i would have thought) a pretty common entry level scenario.

Am I misunderstanding what YARP is, then?

[samsp-msft]

Once we had enabled the customization path, and started going down that road, it meant we made choices where we favored code over config. This is a proxy being developed by a developer platform team - most of our experience is around creating APIs and developer infrastructure such as ASP.NET - and so that has a strong influence around how we approach the problems.

This approach has resonated with service teams at Microsoft who are consuming YARP - they all needed something a little off the beaten path provided by other reverse proxies - and each is different.

For example you mention logging of metrics. In YARP we delivered that as an API together with a couple of samples for how to consume the metrics. For example we don't have Prometheus support built-in, but show how to do it via the sample. We didn't want to try and pick a winner, or force metrics and logging tools to perform unnatural acts to be able to scrape the info that they need. We think its much cleaner for developers to do the (usually simple) wire up between YARPs API and the APIs for their specific metrics/logging tools.

These design choices mean I don't think you'll have as good as an experience with an out of the box YARP container image today as you may have with other proxies. We would need to build more directly into YARP, and provide configuration knobs for controlling that functionality. This may be a direction we can take, but we'd like to see additional feedback asking for it so we can prioritize it.

In the shorter term we should probably make it easier for you to create a your own YARP container images with .NET etc by supplying compose files.

[dpbevin]

Does this feature cover vanilla YARP and the Kubernetes YARP?

I'd like to see an image for the Kubernetes flavoured YARP.