.Net Foundation On .NET, 13 Oct 2020

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: YARP: The .NET Reverse proxy

Description

Reverse proxies can help simplify how clients access your backend services. YARP (Yet Another Reverse Proxy) is designed as a library that provides the core proxy functionality which you can customize to fit your application’s specific needs.

In this episode, Jeremy chats with Chris Ross and Sam Spencer about why they decided to start working on YARP. They show us some demos of various YARP features like live reloading, authorization policies and more.

[01:13] - What is the goal of YARP?
[02:04] - What’s the difference between a load balance vs reverse proxy?
[05:04] - Setting up YARP in an ASP.NET Core application
[06:39] - Reviewing the route configuration
[11:25] - Supporting TLS termination
[13:23] - Live reload for configuration
[14:33] - Dynamically updating configuration
[17:04] - Service Mesh?
[18:58] - Using ASP.NET Core authorization policies
[20:31] - Getting started with Yarp

Getting started with Yarp
https://microsoft.github.io/reverse-proxy/articles/getting_started.html

Yarp on Github
https://github.com/microsoft/reverse-proxy

ASP.NETCore Middleware
https://docs.microsoft.com/aspnet/core/fundamentals/middleware/?view=aspnetcore-3.1&WT.mc_id=ondotnet-c9-cephilli

#aspnetcore #ReverseProxy #dotnet #YARP

A

C-Sharp developers, you have a reverse proxy that you can extend and customize with c-sharp code and integrate directly in your asp.net core projects in on.net. We're talking about yarp check it out.

A

Hello and welcome to another episode of on.net. My name is jeremy likness and today I'm joined by sam and chris to talk about yet another reverse proxy. So before we get started sam chris, why don't we start with chris tell us who you are and what you do, hi.

B

I'm chris ross, I'm a developer on the asp.net core team and I own a lot of the underlying server stacks.

C

I'm sam spencer, I'm a pm on the.net, runtime team um and I happen to own the uh networking class library, so http, client, etc.

A

Awesome so let's talk about, I guess we call it yarp. Is that the right pronunciation? Yes, so tell me about yarp.

C

So yarp is a reverse proxy. um We come from the the, so we come from the two different teams um independently. We had a couple of teams, come to us asking about a reverse proxy functionality or how they could build one, and, after being asked more than once, we were like.

C

We probably ought to put something in the space, and so that's how uh yarp came about, and so the the goal of europe is to make a reverse proxy um based on top of uh kestrel. Is the kind of front end to it, and then http client is the back end and in between you can uh add your own custom logic.

C

A

A couple questions: when we talk about a reverse proxy versus I know, developers are familiar with load balancers that you put in front of multiple instances. What is a reverse proxy versus a load balancer, so.

C

The difference is, um if you can remember back to school and there's the osi networking model.

C

There's layer, four is tcp and then um yarp is actually what we call a layer, seven proxy, which is it works at the http level. So a load balancer will just pass on the package regardless, whereas what we do is we actually terminate the http connection at the reverse proxy and then create a new connection to the backend server, and this means that we can remap the url space and abstract what the uh public sees versus how it's actually implemented at the back end.

C

So um you could have like slash orders as part of your request and that can go to a different uh set of servers than slash customers and then load balance those requests between those individual servers. So it allows you to like redirect the url space as you need to, um but you can also do additional work at the proxy layer.

C

So typically you'll terminate tls encryption there. You can do authentication and authorization you can do compression. You can do cachings. You can offload a bunch of the work from your backend servers.

A

And then the other question, before we jump into details that I know I get asked a lot is: whenever we build our own product, we're asked okay, there's other products out in the community. So what sort of drives that decision build it here versus use something out there. What what was the unique? I guess value prop for for us building a proxy.

C

So the thing that we found with other proxy servers is they're, typically written in c plus, and people want to do something. It's not just. I want to proxy the requests, but I need to proxy request and do something else. At the same time, I want to massage headers.

C

I want to manipulate data, there's various pieces that people want to do, and so the difference with yarp is that we are just as sp net has its own pipeline, where you can add your own middleware modules, uh we've designed yarp with that same goal in mind, so that, as part of the reverse proxy, you can actually customize how it handles routes uh where data comes from. So a lot of it is typically reverse proxies, have a static configuration or a mechanism to pull the configuration with yarp.

C

We have apis internally, so you can go suck the configuration from wherever you want and change it dynamically on the fly without having to restart the server, for instance,.

A

Sounds like there's a a lot of capabilities. Did you have something to show us or some way to demonstrate what it can do.

C

um Yeah, so chris has some demos which uh pretty well illustrate the the functionality of yarp and how that is using kestrel um to implement reverse proxy server.

B

Yeah: okay, if we're ready, let's switch over all right, so this is starting off with the startup class from a default asp.net, core application.

B

Okay, uh you've got sure I can construct. I can inject my configuration, you can configure services and you can configure your web app pipeline, and so anybody that's done any asp.net core development. This will look really familiar.

B

um Yarp plugging in is going to plug in just two things: it's going to plug in some services and it's going to say, I'm going to load my data from the configuration and we'll go look at that in a moment, and then it goes down here and it plugs into the route table, so that only requests that you tell it to map will get proxied.

B

uh You can also have other controllers in your application. So if you want to do part of the app in the front end and part in the back end- or you want to add some dashboards or anything like that, it composes via the route table.

C

Okay and that's useful for handling things like static content, so you can handle that at the proxy layer rather than requiring to go to a back end for it.

B

A

B

All right, so, let's go look at the config file.

B

uh This is this is all just normal, asp.net stuff, you've got logging, you've got kestrel and then there's that reverse proxy section, and what I've done here is I've defined two routes.

B

Route 1 is just going to say everything where the request path is slash example and get in post methods. Route 2 is everything else sent to the localhost host name.

A

B

And on route 2 we're actually going to add some transforms on the request. I'll come back to those in a bit and each of these routes is paired with a cluster, and the cluster has some options on it like session affinity, load, balancing and a list of destinations that should be able to handle that request.

B

So route 1 was mapping slash example, and it's going to come here and it's going to say we're going to proxy that out to example.com.

A

Okay, so I'm I'm understanding this now, unlike a load balancer where we'd come in the front end and fan out. This is we're hitting this web address, whether it's locally on my laptop, whether it's deployed and a certain route, even though it looks like we're accessing it through the the url we're accessing it through behind the scenes.

B

A

Proxying out to the target.

B

Right right- and you can do some fan out here- where we're going to load balance across two destinations.

A

B

uh But that's still hidden from the caller.

A

B

Okay, let's see, uh let's just go ahead and run this, so we can look at a few things all right. That's just some noisy startup stuff. I've got it on debug for reasons uh but kestrel started we're up and listening. Let's go ahead, and so we just requested localhost from the front end and you'll see here.

B

This is the host on the back end. I have it dumping out all the headers and all the attributes of the request.

A

B

And I'm going to refresh that once or twice we're being balanced across that randomly between the two destinations.

B

One thousand one thousand one or ten thousand two thousand one um everything else is flowing through normally you've got all the request, headers all that fun stuff, and then you have a few things that the proxy added for you, the proxy. I told it to insert this header on every request.

B

I didn't tell it to do this. It did this by itself. These are headers that are on by default. That tell you what the original client was asking for.

B

The original request was an http request that was terminated at the proxy, an hbs request, I should say- and this was the host name they had asked for- and this was the ip of the original caller, because it turns out proxies obscure a lot of that information from the destination sure so you've got to flow it through.

B

B

Transforms and just for reference, this was the transform that we had defined in here to add that extra header just manually and I've got.

A

B

A

I was going to say this could be done to transform even let's say, authentication information is that.

B

That's a common ask: yeah.

A

C

Well, one of the common things is: you can actually terminate the authentication at the proxy and then add a add header information for what the claims are that the user actually has. So it goes to the backend server.

A

B

And we're still formalizing how you would actually flow that information, but it is possible today, with a little bit of custom code. Okay,.

A

B

Similarly, you can add response headers to every response and even response trailers, which is an hp2 thing that we won't get into right now.

A

B

All right seen the example, um so tls termination is a thing lots of people ask about. In this case the site was listening on hbs and http.

B

And the destination is independently set to hbs in this case, but it could just as easily be set to http and the reason you would do that is that tls adds a lot of overhead.

A

B

And extra configuration and things like that that you might not need if your destinations are just other servers on the same machine, for example,.

A

Right so in in the case, for example, I'm hosted on an app service and I have something local or a virtual machine, and I even think about with managed identity in azure. There's a local endpoint that you can access to get information about the logged in user- and I imagine this would enable you to terminate to that even though the front end is behind ssl. Does that make sense.

B

Something like that, yeah.

A

C

The other, the other nice thing is, the reverse proxy can actually change the http protocol. That's used, so um if your client can do http one, but you can still have an http two two http two connection from the proxy to the back end or vice versa. Your proxy can be http 2, so the client can connect to that and over that single tcp connection can send multiple requests.

C

um Those can then be fanned out by the proxy to individual backend destinations, and it will then send those back on that same http, 2 connection and as tls negotiation is one of the more expensive things for smaller requests that can actually make things quite a lot more efficient.

B

Yeah- and this is actually a good opportunity to demonstrate something else. Oh that's dangerous. Actually I don't know the other port, we'll just save and see what happens, uh which is.

B

Live reload, uh I edited that config file and it noticed that destination 1 and destination 2 changed and it just live updated. So you don't even have to restart the app.

A

So if I have this deployed and I need to tweak configuration- I just deploy the new configuration, it'll, auto sense and and reload nice.

C

Okay, the other thing we, the other thing we have, and I think chris may demo. If we have time is we actually have an api uh that you can do your own custom configuration live with inside the app.

B

Yep, that's next.

A

Yeah I'd love to see that, because I think a big appeal, like you mentioned earlier for net developers is going to be what sort of customizations they can do or what's the extensibility story for the proxy. So I'd love to see more of that.

B

Exactly so, for starters, your extensibility is that it's just an asp.net core app I can put in any middleware. I want, I can add, other endpoints and still take advantage of the config model if I want it, but if I need to do something more complicated, like pull these routes from a database, that's completely possible. Let me switch over to this example for a moment.

B

So this example is just manually constructing those same routes and clusters setting them up here into yarp with a proxy config provider. This is just something you can implement to arbor load your routes from completely arbitrary destinations.

A

So this example is basically recreating what the configuration file did, but doing it programmatically to show that you can dynamically.

B

You can pull this data from anywhere. You want.

A

B

As long as you can provide these same fields,.

B

Then we don't really care where it comes from and you can still live reload in that example,.

A

B

Because that's something supported here by the provider, you just tell it: hey: I've got new data. Now update your state.

A

B

um And we've had a lot of cl of our partners. Ask about integrating with specific providers um a big one is service fabric and.

C

There's already a.

B

Pr in the repo that has implemented this uh proxy config provider for service fabric.

A

And that was going to be another one of my questions since we're talking about service fabric is deployment targets. What are the options or limitations of deploying an app that integrates the reverse proxy? Is it as long as the app can be exposed over http? This is going to work, or are there constraints that people should know about with implementing this.

B

Yeah anywhere, you can deploy an asp.net core app.

A

B

C

Under the the app that you're proxying to does not need to be asp.net core, it can be any any http endpoint. So right, one of the uh interesting scenarios- reverse proxies is um what we call a service mesh whereby you deploy um and let me switch to my slides.

C

How do I get to that window? Sorry, I need to find powerpoint and until it's going next slide. So in the service mesh scenario, you put a mesh proxy on a server and that can handle both the inbound and outbound traffic for that server and redirect to individual services there. So in this case I have service one which is calling over to service b. It doesn't need to know where, in the data center service b, is it just asks for localhost service b, the local proxy figures out.

C

Oh host 2 has a service b on it, so I'll redirect over to there and then the mesh proxions on that then goes and redirects to the correct port, and the advantage here is that logging and telemetry and things can all be captured by that mesh proxy and your services don't need to know about the data center configuration.

C

So if you have service yeah, they can move service b, so service b could be written in java. It could be, php could be node, um it doesn't matter and you can still get the same. Telemetry and metrics across your data center, regardless of what those services are written in.

A

And that's one of the the big challenges right that traditionally, with writing. Microservices is the whole catalog and discovery. So how do I find the url for the service? So what you're saying is I can build an application and just have well-named local endpoints, and then it doesn't matter where it's implemented. We can do that through configuration and make it all light up. Exactly very good. Did you have anything else to show before we wrap up.

B

um The one thing that people keep asking about is off, so I will just show that real, quick.

A

B

And what we did decided to do was to integrate directly into asp.net core's, author authentication and authorization stack.

B

So all you end up doing on a route is saying that this route requires the default authorization policy, and this route requires a custom one and in startup you use asp.net, core's authorization setup and say the custom policy requires this extra claim and the default policy only requires that you be authenticated.

B

So when a request comes in for that route, it won't be proxied until it has met the authentication requirements.

A

And then, if it is proxied, the authentication information can be proxied forward. Is that.

B

They have to have.

A

B

In theory, um we're still working out patterns for how to flow that information, because people want it presented in different ways. You may want to flow it as a jot token or just as a header, with claim with raw text of claims or a username.

A

B

That's something we're discussing with users right now.

A

And then probably the most important item, so I'm a.net developer, I'm watching this show. I'm super excited about trying it out. How do I get started with using this reverse proxy.

B

Turns out, we have our own getting started guide.

A

Nice, so it's microsoft, github! I o slash, reverse proxy.

B

Yep or even simpler, you just go back to github and it's linked from our github page.

A

Okay sounds great.

B

All right, thank you.

A

Thank you very much for your time today we talked about reverse proxies with yarp, go ahead and check it out, pull it down and the team is always looking for feedback. So if you have features or you run into any type of issue, let us know thank you and that's been another episode of on.net.

A