Microsoft Azure Application Gateway Deep Dive

hey everyone welcome to this video diving into azure app gateway thinking about how i can offer my web-based services out to the internet or to private networks before we get going as always if this is useful a like subscribe comment and share really is appreciated and hit that bell icon to get notified of new updates now in other videos i've talked about the azure load balancer i've talked about how i select the various load balancers and i want to focus on the idea that we have some services running that are offering something that we want our end users or end services to be able to get to i think about hey i have multiple instances of some kind of resource this could be an app service plan it could be virtual machines it could be something else entirely but i have these multiple instances of my service now i don't want the end consumers of this to have to know about the fact that there's multiple instances so what we do is we create this kind of front end ip address which people will connect to and then whatever service i kind of put here will distribute those incoming requests to the healthy members of what is going to be known as a back end set these resources make up a certain set now i talked about that as a load balancer now the azure load balancer so i could think about this it has kind of a front end ip this is what we call a layer 4 solution so if you think about kind of the osi layers this understands things like tcp and udp but it has zero concept of things like http https http 2 websockets doesn't understand that and often if i am offering those kind of web-based services i want a balancing solution that understands that because he can add additional functionality things like cookie based affinity maybe i can offload the ssl maybe redirection rewrite other capabilities and so if this was kind of the azure load balancer well then we have kind of app gateway so app gateway is a layer 7 solution i.e it understands http https http 2 and websocket so it can kind of understand all of those various components and so that's kind of how i can make a decision when i think about hey we have the azure load balancer and we have azure app gateway which should i use well what am i offering if it is a http http 2 https websocket solution well then i probably want to use app gateway and get those additional capabilities now an important point when we talk about app gateway is often we talk about global solutions and regional solutions so critical to understand here is app gateway lives within a certain region so it is not a global solution the components that make up that azure app gateway live within a specific region so maybe that's um east u.s or west u.s or north central whatever that might be they all exist within a single region so if that region had a problem well then that instance would not be available so it's really important to actually understand that now when i think about actually deploying this it deploys into your virtual network and just a note so see this is a regional solution a global equivalent at a layer seven we say like azure front door so an azure front door is a global solution that could then point to app gateways at the regional level so if you needed a global that's really azure front door maybe traffic manager but that's dns and again look at my other video we'll actually go through how do you pick the right load balancer solution so when i think about deploying azure app gateway i can think well within my particular subscription and within my region what i actually have is a virtual network so i have pre-created a virtual network remember that virtual network will have one or more ipv4 sider ranges optionally ipv6 now i'm going to create a subnet i create it i can call it whatever i want i might call it gateway subnet the name doesn't actually matter and when i actually go and deploy this it's going to put its resources into this subnet now when i think about the sizing there are different versions of app gateway now i'm going to focus on the v2 the v1 was built on really a different set of kind of cloud services it was the earlier version it had different limits it could only have for example 32 instances and so when i think about the sizing of that subnet a slash 26 would probably be sufficient to cover a v1 i probably want to use a slash 24 for the v2 because the v2 can actually have 125 instances that kind of make up at gateway so it needs an ip address from this subnet so i can really think behind the scenes it's deploying these various instances of kind of this app gateway appliance i don't see these i just see app gateway service but in the v2 this is essentially a vm scale set that's what it's really building behind the scenes so as it scales well it's creating these they all take an ip address from that subnet so something that has to be big enough so that as it's scaling out hey they can get an ip address additionally i can think about well if i opt to have a private ip behind the scenes again it's kind of deploying a load balancer and that will have a private ip again from that subnet and that kind of distributes the load now i can well i will also have a public ip so the public id also deploys an additional external load balancer and that's going to have kind of a public ip obviously a public ip does not come from the subnet that's a separate type of resource see the standard load balances it's going to leverage that's going to kind of distribute the traffic to the various instances it's actually creating so from the sizing has to be big enough to support the maximum number i intend to scale to and one for that kind of internal load balancer now if i know hey i'm never gonna scale beyond four instances well four plus one then i lose kind of the five for the subnet i could have a much smaller subnet but unless you're really short of ip addresses hey i'd probably just opt for that 24 if you can size it that way and then as we'll kind of talk about obviously things like web application firewall can also kind of help protect those various services that i'm actually offering so when i do think about those ip addresses again we're focusing on that v2 now the v2 has to have a public ip address so i'm always having that public and i can optionally have the private so i can have public only or i can have public and private i cannot today just do private i always have the public that's because the way it's architected today these instances have to be able to actually get outside of the v-net to talk to the various management plane components of azure and if i'm behind a standard load balancer if it's private only i wouldn't have that external access it has to do like in that gateway or something else so i always have to have this now remember it's still sitting in a subnet so technically i can still use constructs like network security groups and apply that here so although i have to have that public ip i could if i wanted to restrict it so that traffic would not really go to that public ip now microsoft actually has a document that walks through that so if i want the app gateway v2 again the v1 can just have a private ip but if i only want that private front end it basically talks about look you have to have the public ip either public ip only or private and public ip but if you just want the private ip to be usable hey you can go through using the network security groups and essentially lock it down so that public ip really just wouldn't be addressable and what i'm going to do is i'm going to probably talk about a lot of links during this video they're all in the description so go and look at the description i'll have the links for all of these various things so yes it always has a public ip when i think about the v2 but if i really wanted to yes i can essentially hide it away now we do have this idea again of the web application firewall as well i'm doing it on the outside it doesn't live on the outside it's kind of enabled through the various components but there's a waff v1 and a waff v2 that kind of correlates to the v1 and the v2 version of azure app gateway now as i mentioned i'm going to focus on the v2 version of the skus now there's not actually a huge amount of difference in the components it's really just some things about some of the additional functionality we get with the v2 but i guess just super quickly so we understand those things and there is some variance in how these things are priced so if i think kind of dollars with the v1 sku the way the v1 worked is we had different types of app gateway so i could think there was kind of a skew where we had a size so we had like small medium large there were tiers and how many instances did i actually have so we had those elements and then i also paid for the amount of data processed the v2 has kind of shifted so on the v2 doesn't actually care about the number of instances what we pay for is hey do we have app gateway configured and do we have optionally the web application firewall configured and that's basically an hourly cost so whether there's 10 instances or one it's just an app gateway cost and then we pay for these things called capacity units so this is how we handle things hey based on the scaling they're two they're five they're ten because the capacity units handle things like well how many persistent connections do we have they handle things like well what is the actually the throughput and then they actually handle compute units the kind of work being done so it's kind of this fixed cost and then these variable costs so it does vary between the v1 and the v2 what they actually are and again we can go and look at the documentation and there's a whole document about the pricing and then it talks about the v1 skus hey yeah look v1 there's the fixed cost the tier the size number of instances and then the variable is the amount of data processed so that's how you work out the v1 skus for the v2 skew there's all examples you can really understand all of this that variable part what is this capacity unit and that capacity unit really is hey each capacity unit has these 2500 persistent connections a certain amount of throughput and you get a compute unit with it and then that compute unit itself hey here's the guidance here's the number of connections it can handle how many capacity units we get etc etc and then you just have this fixed amount of time the app gateway is provisioned for or the waff it doesn't matter how many instances if it's provisioned i pay for those things and again there's kind of examples that go through all of those various things now sometimes you'll actually see kind of the standard v1 just called basic so when we talk about standard v1 you may see the term basic but the v2 we always refer to as kind of standard v2 and then waff v2 if we add that optional waff actually to it one of the things the v2 adds is actually some additional functionality and realize because it is a layer 7 we get certain features anyway so we talked for a second about this idea of hey layer 7. so because we are layer 7 we get a bunch of features so i can do things like url redirection and also i can do url based routing or routing if i use the english terminology i can also do things when i understand the url i can do things like rewrite i can actually change elements of the url i also can change elements not just the url but also things like the request i can modify many different things about that because i'm at the layer 7 i can do things like ssl tls termination and offload so what that basically means is ordinarily when i have kind of a tls connection i can think hey the client comes in and it's talking to some back-end resource that establishment of the tls and the compute associated is to the back-end resource so this resource has to do a whole bunch of computation and work around okay that decryption and encryption well when we put in app gateway now so before that was kind of the tls going here and that way now i can actually just do it to here it can offload the work and then it can just send regular http i.e unencrypted removing the work from that back end resource but i still have that kind of encryption to protect me now i can do end to end still if i want to but i don't have to we can do things like session based affinity again now we understand layer 7 i can do things like cookies because i'm layer 7 i can do things like connection draining so we gain a whole bunch of functionality because i actually have these things now with the v2 one of the nice things we actually got you know is kind of here well the v2 gives us things like auto scale so it can change the number of instances we actually have here based on the work coming in if i actually go and look for a second if we jump over and i go and look at my app gateway i can see on the configuration hey look i can do a manual scaling and i've set it to one because i'm cheap or i can say auto scale and let's even go all back to 125 so it will auto scale based actually on the amount of work i could set the minimum maybe to 3 for example or i can go back to manual also notice on this page while we are here this is where i can enable or disable http 2. so just kind of bear that in mind so the v2 we get that nice auto scale now if i was just go and create a new app gateway one of the other nice things that the v2 does is notice we have this option about availability zones so let's pick a different zone actually has it so notice i could pin it to a certain zone or i could just say hey i'll i'll have it in three zones i'm actually resilient across zones or i could make it zonal and just pin it to one so one of the great things we also get with this nice v2 is i get a z support now i don't get that with the v1 if we went back for a second and looked and actually note a few other things so this is the v2 skew and notice we have this availability zone if i change it to the v1 just the standard that a z option has gone away but notice now i also get this skew size small medium large that does not exist for the v2 we just have kind of those auto scale there's no concept of this skew size thing because in the v1 we pay differently based on these so when i go to the standard v2 there's no in idea about size we just have these kind of scale capabilities and once again i can enable or disable the http 2. and that was you're going to configure that virtual network when i actually go and create it but i've already got mine um some other i guess big changes from the v1 is it's always static ips so it's always going to be static they added things like header rewrite so a kind of header rewrite it's all static kind of those virtual ips and it's actually a nice document so if we jump over and again it's going to be in the links in the description you can see the comparisons between v1 and v2 and hey i can see that okay the the v2 skew auto scaling zone redundancy static vip aks ingress controller uh integrates with key vault for the certificates that we can actually use and rewrite http https headers um there's also web application firewall custom rules you can see that one there as well for the v2 and then that's it so those are the the key differences between the v1 and that v kinda two so we have those things available to us so we have these nice features all of this goodness again things like cookie based affinity we have there the connection draining is really nice because now i can have like a back end set member maybe i want to replace or update i can let current connections kind of finish over a timeout that i configure and then i can actually remove it and kind of be on my merry way okay so they're the features how does it actually work so i kind of started to allude to the fact that well hey like it's back end resources and there's some front end i talked about as these app gateway so they're the physical components there's a whole bunch of logical components that i configure to actually make this thing work so let's kind of take a step back so i'm sending traffic to something there are those back end set members either things actually hosting this web service that i want to enable connectivity to and it really supports a lot of different things when i think about app gateway it's very different from like the azure load balancer where hey i need things in my v-net i have a nics or ip addresses so for when i think about those back end sets so we're going to create a back end set called back end set one in that back end set i could point to app services like an azure app service i could point to a virtual machine i could point to a virtual machine scale set so those are things in azure but i could also point to an ip address to a fully qualified domain name now for these app services these vms the vm scale sets they can actually be in any region it doesn't care so i could point to things i might have a v-net in another region remember virtual networks are regional if i can peer i could go and peer to avena in another region so i can get to that thing but remember the key point here app gateway itself exists in a certain region so yes i can point to things in different regions but if the region the app gateway is in it's not pointing to anything anymore so this is not a global balancing solution because i have that single region kind of point of failure so i don't consider this a global solution yes it can point to things anywhere but it as a unit of work a feature exists in a single region these ip addresses all these these could be on premises again i just need a network connection to them from the virtual network to act gateway so for example i might have my on-prem network and maybe i'm connecting via a site to site vpn maybe i have express route so i could include an ip address or resolvable fully qualified domain name that's on premises it could be something out public so it could be a public ip out on the internet it doesn't matter it's a public ip name it just has to be able to get to it so my key point about all of this when i think about azure at gateway i just need ip connectivity if i can get to it from an ip perspective it can be part of the back end set that's it everything else is just kind of i'm going into bits of detail that really aren't that important if i can get to it from my p it could be part of the back end set and obviously i'm probably going to have multiple back end sets so i might have another back end set too i might have a back end set three with different sets of resources in it or some of them might be the same resources in it now in the portal when i go and like browse for app services vms vm scale sets it will only show me things in my current subscription that's just a portal i can absolutely through other means add resources from other subscriptions it doesn't care that's that's great so from the back end set members what can be in it i can really have anything i want that's super easy so that's one end of the picture the stuff i'm actually gonna go and get to and obviously there's other stuff before that and again we talked about this so we talked about the idea of these ip addresses always have a public ip and optionally i can have a private ip so i think about i have these static ip addresses so i can go okay i hope we're going to scale this picture right what we'll say we have this static ip so remember we always have a public we can optionally have a private don't have to have that we can do there's also always a dns name that doesn't change for the life of the app gateway that will kind of point to the ip address again in v2 these are static in v1 they could be dynamic that's why we kind of have that and optionally now i'm drawing this logically we can have that web application firewall i'm not going into detail about that in this but because this actually kind of exists within the components but it just complicates the picture but that does those additional types of checks so it has those core rule sets protects from things like sql injection attacks and much much more um for the v2 i can actually customize those waff rules as well as a bunch of extra stuff i can actually do that so we have the idea of this ip address now with an ip address hey i can have different ports coming in i have different protocols i support to actually get to it it may have used different dns names like the fully qualified domain name i don't go to an ip address i go to www.saviltech.com and then from dns that resolves to an ip address and maybe port 80 if it's just regular http or port 443 if it's https so the next component we have is saying it has to kind of well listen for traffic so they originally named it and it makes it fairly obvious what it does there is a listener and so the listener is taking certain traffic from the ip address so it's tracking a certain ip a certain port and a certain protocol and optionally it can think about the host name i'm going to talk more about that because we do get sent kind of the host name as well and there's different mechanisms of doing that the host header will have the host name if it's encrypted there's actually server name indication sni that will still even if we don't know what's in the packet we can still know well this is the address it was actually sent to so we think about okay i'm going to have a listener and it's kind of listening on a certain ip address now that i p address will have multiple different listeners connecting to it so i could think about there's n number of listeners but a listener is tied to a particular ip address so this one ip will have multiple listeners across different ports and protocols actually listening to it now there are different types of listener depending on what i'm actually trying to do this thing called the basic listener so if i have a basic listener it is just essentially all traffic for that ipport protocol it's just sending everything it does not care then there's also i'm going to run out of space aren't i i'm going to change the color let's make this a bit obvious i'll keep it green okay there's also the idea of multi-site now the goal of the multi-site is you can imagine i only have one public ip and one private ip but what if i wanted to be able to have multiple different websites hosted on the same app gateway but actually what is coming in is it uses different host names www.savotech.com www.contoso.com www.savtech.net but they're all coming into the same public ip so with multi-site what it lets us do is have different listeners using the same ip port and protocol so it's going to have these additional kind of checks to say well which listener does this match and it will be based on that hostname so we have the same kind of ip port protocol but what we can then actually do is use that fully qualified domain name so using that fully qualified domain name and again that could be from the host header that could be using server name indication sni there were things like wild cards and question marks for single characters supported as part of that and then that helps us work out well which actual listener should this one apply to because i've got multiple listeners on the same iport protocol well it's going to go and look at well what's the host header what does sni tell us about the actual name that the client requested so hey i'm over here and i go to www.savaltech.com when the host header it can see oh even if this was encrypted with https so i can use sni there okay well this listener listens to star.sampletech.com if i went to savtek.net there's another listener that says star.savtech.net that would be a different listener so i can think about hey i can have multiple listeners normally it's different ports and protocols but i can have multi-site rules and then each of those multi-site rules yes it says the same iport protocol but it's going to use a different fully qualified domain name to be able to separate hey what is that request actually doing so this is probably easier to kind of just see this if we jump over for a second let's close that so if i jump over for my app gateway you can see i already added a listener and if i look at my listener we can see i'm listening on i have public or private ip i specify the port and this was a basic listener type not a multi-site and then i associate a rule ignore that for now so what that means if i try to add another listener and i did the same front end ip it will not let me do port 80 because i already used that on one of the other rules i can't do that now i could say 8080 and that's a unique port it's fine i can use other ports for that i could also say oh this is https and it's again there's nothing on https right now so it's defaulting to 443 i'm going to go back to the 8080. now notice i can do multi-site now with a multi-site i can either have an absolute name so i could say www.savilltech.com i can't use wildcards i just have to do the full fully qualified domain name i can have one of those and that is this rule or i say actually i want to either support wild cards or have multiple ones so if i say multiple now i can do things like star dot savaltech dot com or maybe also on this one i'll do it could be like three characters maybe it's savile tech dot co dot uk so i can add up to five of these for this multi-site and then i could go and add this so this is me actually going and creating this listener so it was 8080 http so i could click add now i could add let's say test two the same front end ip pull 8080 but it's going to let me because i can do multi-site and now i could do a different list of host names maybe this is now www dot or actually i'll just do star.saviletech.net i'll just do one but i wanted to use a wildcard add my name's a terrible it's going to confuse me later on but you get the idea i can actually go and add those so that's the whole point of doing these things it lets me with that multi-site as exactly as the name suggests hey i can use the same port and protocols across different rules sorry different listeners and that ultimately is what's going to let me send to different backend sets from that same shared public ip and or private ip so that's where i use multi site hey i want to be able to have multiple listeners i'm just going to vary based on the fully qualified domain name because ultimately i'm going to then make different routing decisions on where it goes on the back end exactly in my scenario i have one set of back-end servers for saviletech.com maybe another set for saviletech.net completely different sites but i only have the one public ip but hey i can go and look at that host header or sni and then later on i can do different things because they're going to go to different listeners based on that multi-site now you'll notice i don't configure web sockets anywhere here websockets is just enabled by default and it will work over both http and https http 2 remember was part of that configuration when i actually create it i can say turn on http 2 and in the configuration i can turn that on or off as well i showed you that earlier on so this is just me picking the listener so that is fundamentally just hey i'm listening on that thing now one of the things if i did https is obviously i have to have a certificate so also i do kind of configure if i'm doing https the certificate that then the basic or kind of the multi-site rule would point to and i can upload that file so if we go back over for a second if i was going to add that listener again if i do https you know is hey i can upload the serp that it's actually going to use this would kind of be the private key or this is this integration with key vault i can actually choose it from key volts that's one of those nice new v2 features so this will enable it to do that tls kind of offload and let it do the work and save that on my back end side so i can absolutely do that okay next so all we've done right now is have a listener that will take certain traffic based on these conditions well now what i ultimately want to do remember is get that traffic to a back-end set so we then have is a rule and i basically link the rule to a certain listener this is kind of a one-to-one relationship so a listener is associated with one rule and a rule links to one listener and it's the rule that actually then governs well what back end set am i actually going to do now there are different types of raw um there's some ink called basic and as the basic kind of says hey just everything everything just go there my other option is i have kind of a path based it's going to look at the path of the request so again when i go www.com well actually as part of that i might say slash blog or maybe there's slash cart or something else so that's the path so i can use the path actually as part of the routing decision so again i have different back end sets handling different parts of my website so i can say hey if it goes to blog we'll then send it to this back end set if it's going to cot we'll then send it to that back end set so those different types of rule but it's still one rule it's just within the rule it will have the different paths i can identify and i link the different back backend sets there's a little bit of magic going on because i remember the pathways we have to be able to see the path remember we're doing the ssl offload here and i'll come back to that and i'll talk about how we're actually doing that but it can see the path because it's doing that ssl tls termination so i can see the full url i'm not just seeing the fully qualified domain name from sni for example so i can actually see the path so let's look at one of these so again we'll jump over so now we go to rules and you already kind of saw notice my listener had an associated rule so if i go to my rule and select the rule you notice it's tied to the listener so i select it i can't link it to another listener it's very much a one to one relationship with that and then also within the rule you specify the back end set so i can do a back end paul or ignore the redirection for now i'll talk about that in a second so the rule really is just saying hey for this listener um here's your back end target and my back end pulls here's the one i created i just add stuff but i can add vms vm scale sets app services or ip dress fully qualified domain again it does not care if you can get to it from a networking perspective that's all that matters if i create a new rule so i'll call it rule2 we have to associate with a list that's not currently used remember it's not showing my main list now because it already has a rule i can select one of my new listeners i just created and then i could go and select my back end targets now by default remember it's just one in my back end target what pool remember i can reuse the pools and then my http settings i'm going to talk about that in a second but they give me things like do i want to re-encryption the type of affinity draining probing those types of things or i can do path-based rules so here i could say hey what's the path so my path is blog my target name blog target then it has its own set of configurations so i can really think about the the flow is based on the unique kind of rules to the back end sets so when i drew this picture i'm going to start adding to this each of these entries has its own selection of kind of the http settings i actually want to leverage so again we can see hey what is the target i want to get to and what are its http settings and i could go and add multiple ones of these to target a slash car etc etc so we'll cancel out of that for now and i've obviously realized i just did my slash the wrong way around so we're trying to make this as professional as possible at least get my slashes the right way around just try not be completely incompetent so so that's that's all that does but you can see hey within one rule i can have different paths going to different places so then we saw a couple of different options i could actually do that now one thing i should say when i have these multiple possible targets as part of that back end set well what it is doing is round robin it's just anything that's healthy it's going to round robin the request that there's multiple possible back ends in that back-end set now the other thing we can actually do is well we can have a redirection rule so we saw that actually in the options there so the other thing i could actually do is redirection with redirection i can redirect to a different listener so that i would think about hey it came in as http i want to redirect it to https i want to make it kind of encrypted or i just want to do some external site just redirect it somewhere else completely when it comes in so i don't want to send it to a back-end set i want to either redirect it to a different listener my 443 encrypted or just redirect it somewhere else completely random so again we go back to our rules if i do a new request routing rule doesn't really matter what the name is pick a different listener now is i can do redirection now is it a different listener so i could redirect it probably to a https listener or i just put in an external site hey i'm going to go and redirect to contoso.com and i can say do you want inquiry include the query include the path and i'm doing this for the entire rule ie this is just a basic i could do the same thing with multiple targets once again i could say hey maybe my shopping cart well do you know what that that's actually i want to make sure that's encrypted so i'm going to maybe redirect https so i could go and redirect that to a different backend sorry redirection i want to redirect that to a different listener my https listener or maybe i've just a completely different site to actually host that so i'll redirect it to an external site so i have those options both for everything or again based on the path i can do different things so that's the same one there we go so i could add that so you can now see there's a path and i could go and add another path so now maybe i'll do blog and that one doesn't have to be redirection maybe that just is a back end pull so that could be my blog pool so i can mix them up when i'm doing that path based this one hey that's good i'll just send it to my vms add so now we can see hey i've got path based and redirection within the same rule and i can just keep adding these as i want to so that's the the basic rules so it gives me the redirection and all of those different capabilities that i have there now the other thing i might want to do is maybe i want to change stuff so be stuff came in that isn't actually how i want it so the next thing i can actually do is a rewrite rule and the relationship here is hey a rule can be associated with multiple rewrite rules and a rewrite rule can be associated with multiple rules i can reuse them all over the place so i can rewrite things like the header i can rewrite things like the url because i'm messing around in here i can do things like cookie query string i i can pretty much change anything and parameters i could change if i wanted to essentially go and rewrite what's come in before it then actually can go to the path rules so i might rewrite things in the url which would then influence well what path-based rule would it then actually what back-end set would it actually go to so if we jump over if i go to my rewrites i create a new rewrite set i give it some name we want one we associate it with any number of rules if i'd other rules i could associate it with them and then my configuration and this is kind of a nice gooey experience so i add a rewrite rule and it says do this and then this could actually be well i can rewrite the request header or the response header or the url so i have different options here and you see for the request header hey i can set or delete elements of that is it the common header so there'll be different elements we typically see in the header or it could be custom now i type it in and i put my new value if it was the url for example well then i can't delete but i can set or i can change the url path the query string or both the url path and the query string so we'll change the path and then hey what's the bit i'm actually changing and then reevaluate the path map because i've changed it i now want the rules to go and reevaluate it and notice we can actually put these in order and what i can do is i can add multiple ones to this so i could set that one then i could add a new action to do something else and then i could add conditions have all these different things i can actually do um within here so i create this set of rewrites i have the sequence for all of these different items on what i'm doing i can delete the various things as part of this notice i can go and do if hey if the http header or some variable case sensitive checks operators then go and do something else so these really powerful capabilities to actually rewrite these things so i'm leveraging that and linking those let's cancel out that so i'm linking that from the rule now the next part we saw as part of the rule was what color haven't i used yet okay we're gonna people get excited when i pull out the gold right so we'll do gold so the next thing i can actually have is kind of the http settings so once again it's the rule that links to the hdb settings so revolve can only link to one http settings but http settings can be used by multiple rules i might use capital ends sometimes and uppercase and other times now the http settings is all about hey i want to do things like i want to re-encrypt so remember i talked before about the idea that i don't know where i drew that picture somewhere on this board i drew a picture of something decrypting let's zoom out for a second there okay i drew this idea of hey the app gateway actually does the decryption they could send it just regular http to the back end what about if i didn't want to what about if i want this to be encrypted was in the http settings i can actually say hey i want to send that re-encrypted so over here i can configure hey i want to do the re-encryption i can hear set things like cookie based cookie affinity i.e stickiness to certain back ends based on a cookie i can enable things like draining and what is the time limit to do the draining to finish off current sessions uh i can do things like have custom probing to check the health of these so these are really super important and again this could then actually connect to [Music] health probes if i had a custom health probe configuration and again http settings will only use one but a health probe could be used by n number of http settings this custom is completely optional or it has kind of this built in capability as well so once again if we jump over if i go and look at my http settings you can see i have one very basic port 80 http protocol i've enabled cookie based affinity i could enable connection draining if i do what's the drain timeout it has to finish existing sessions so it wouldn't allow new ones to connect but it will give 60 seconds to these other ones and then it will kind of remove it from the environment request timeouts override backend paths um hostname modifications over here hostname overrides don't want to use a custom probe if i say yes then i would have to go and add what the custom probe is i don't configure any of them but that's just the basic kind of http now if i do https i have to add the trusted root certificate for the chain unless it's using a well-known ca certificate so what is this talking about so if you think about on this back end set if it was offering something on https i.e i want to remember re-encrypt the traffic so if i'm doing https the way that fundamentally works is i have a certificate so i have kind of my private key here and there's a public key that i know that i can use to do that initial communication and then find a symmetric key we can use for the actual the stuff well that private key and this whole certificate was issued by something and so whatever that issuer was there's kind of a root certificate authority that normally then signs some intermediary ca that actually then goes and creates my web ser so this might be some internal root ca that azure app gateway would not trust so it will fail so i have to take the public key of the route completely misspelled public there's no r in public i have to take the public key of my root ca certificate and bring that in to my http settings so that's what it's asking for now if this website i'm using on my servers was issued by one of the internet standards like a very sign or did you sell something like that well then that's already built into the trusted root cas i i don't have to do that import so that's what that screen is basically saying it's saying look i need the root ca certificate so upload the public certificate of the back-end servers to this http setting unless i'm using a well-known in which case if i'm saying yes it's well known i don't have to import the certificate anymore it's good it's going to trust it anyway there's nothing more i need to do so with this setting now if i'm setting this back end protocol to https this is what is telling it to re-encrypt the traffic if i just say http it's going to send it unencrypted remember that that front end on the listener it will have done the decryption so if it was https coming in remember it offloads this is where it decrypted it at the listener so now it's just regular basically http but if i'm saying no no when it gets sent here i want it encrypted well then i set the http settings to https and i have to give it that root public key so it knows to trust it so it will use that for the actual initial establishment and then the sending of the data over um or if this was issued by a well-known i don't need to do anything because it's already going to be built into those kind of virtual appliances as part of that os it's already trusted it will allow it to be used for that tls establishment so that's kind of the key point of that so that's what the https settings are used for and again you saw kind of that cookie affinity the draining the probing i had all of those kind of other options within there so that's kind of put all of this together at this point with that all of these things now talk hey traffic comes in optionally waft the wife really kind of sits there i kind of draw on the outside okay it goes to a listener that matches the ip protocol if it's multi-site based on the host name okay the rules then tell it where to go or i can use the path as well if it's a path based or i might redirect it to a different listener hey i want to go http to https um i can rewrite bits of it and if i rewrite i can say reevaluate the rules because it's been rewritten maybe it now goes different rule http settings enabling me to do hey yes you did the offload and decrypted it i want to re-encrypt it okay well i need to make sure i've got the cert if it's not from a well-known kind of public issuer cookie affinity draining if i want custom probes then it goes to the back end sets which again if i have ip connectivity it's just going to work and that's it i mean that's that's at gateway the only other thing i'll quickly mention because more people kind of using kubernetes and aks one of the kind of special features of that gateway is it can act as an ingress controller for app gateway so for azure kubernetes services been long long warning already now if you think about the whole point of containers is i have some aks cluster now there's really a data plane where the workers live and the kind of managed control plane but forget about that for now and i just have pods remember i just had those pods that are running inside the pod i haven't it says my containers little side car with the networking stack but i have pods and what i want to be able to do is use app i gateway that's the icon app gateway i wanted the traffic to come into here and then it distributed to the pods now remember one of the tricky things we have here is the whole point of these pods is i might have kind of replica sets so the number of them maybe vary based on scale conditions so pods being added and removed well i need to make sure the basic the rules are updated to make sure it's pointing to all the valid pods or remove pods that aren't valid anymore so the way this works is what app gateway does is that gateway actually adds a pod so we have added here is the kind of app gateway ingress controller and there's the kubernetes api the api scheduler so what the app gateway ingress controller does is it's kind of monitoring it it's listening for things that change so hey a pod's been added and the pod's been added to a deployment that i'm providing the service to distribute the traffic to so when it sees a change it goes and configures via arm the azure resource manager it reconfigures this to now distribute to the right pods and then as the traffic comes in hey it distributes to the pods directly now there are different networking configurations for azure kubernetes service if i'm using cni with cni the pods have valid ip on the network so we can just talk to it directly there's nothing more i need to do if i'm using cubenet then the pods um have an isolated ip space that is not valid on the network essentially all the traffic is matted out so what we have to do is this aks actually lives within a subnet or the worker nodes and that subnet actually has a route table associated with it so that route table when i have kube net specifies hey this portion of the isolated ip space lives on this worker node this is on this work node so what i would actually have to do is that route table if i'm using cubenet i have to associate to the app gateway subnet as well so i would essentially that route table i would associate so now the app gateway knows which host to send it to for that target pod so just realize so it still kind of works a similar fashion but i need to have that route table associated so it knows how to send it there because the ip address when i'm using cubenet is from a different ip space that's not part of the virtual network that the aks on it so i would have zero clue how to get to so i have to basically take this route table that's automatically maintained um actually by change the color of that to make it match that's maintained as part of the cubenet networking i'm going to associate that route table with my app gateway subnet so now it also knows hey pod one are you on this node port two you're on this node so i can still know to send it to the node which will then get it to the various pod so the whole bunch of nat essentially goes on when i'm using cubenet so that that's that's how it works as a an ingress controller i have a whole video on aks network in deep dive if that's something you're interested in i want to kind of throw that out there because that is kind of an important point that's a big piece of functionality but that's it uh i really hope that was useful i hope it clears away some of the mystery of that gateway it's really not complicated and it's really nice sets of functionality very powerful using these kind of especially like multi-site um these path-based rules the redirection i can do rewrites different settings um yeah so again a lot of work goes into these videos i really would appreciate a like and subscribe um but until next time take care you

Channel: John Savill's Technical Training

Views: 15,478

Keywords: azure, azure cloud, microsoft azure, microsoft, cloud, azure networking, layer 7, load balancer, app gateway, application gateway, aks ingress controller

Id: B3O6bXu-NbM

Length: 63min 29sec (3809 seconds)

Published: Tue Sep 07 2021

Reddit Comments

[u/drowninbetterworld]

What would you suggest as an alternative for Application gateway? The only reason we use WAFv2 is because it has a static public IP and our backend is web app service. We can't really go back to WAFv1 as you can't create cname for root domain.

I read something about front door premium, but price-wise it will be very similar when it goes out from preview.