Building Cloud Native Apps with .NET Core 3.0 and Kubernetes

all right so my name is Shane Boyer and I am a p.m. on the college advocate team and today we're gonna be talking about building cloud native apps with dotnet core three oh and kubernetes so a couple of things that we're gonna go through here is first when talk about some health checks address the changes in updates that we've made in a docker images talk about that new template that Glenn started out with he did a great job but we're gonna we're gonna jump more into building some worker services some endpoint routing and then we'll talk about some of the things that we can do with kubernetes and also the configuration system that we have built into asp net core and dotnet core and what it offers there so first let's talk about health checks health checks is that in point that we have built into our on our system here in asp net core and i know for a long time in my past life at work i've done a lot of coding around building an endpoint that we used to call watchdog services where i would just build an endpoint on my services that would return some sort of a response that in turn i would probably have some sort of a service that would hit it and say that it was okay so now on asp.net core we've got a new way to create an endpoint that's just a simple ad so now we're just referencing a new nougat package that's SP not core Diagnostics under health checks and just by adding in this new services middleware services dot add health checks and then new and now adding this this new endpoint endpoint map health checks and then on in this specific example i'm just adding a slash health and we can make that anything we'd like but for me it makes sense to add slash health by running that now I can go ahead and hit that slash health endpoint and it returns obviously a response if I'm healthy and it'll say ok or return that that 200 now we can expand upon that and also also add in my transitions want to keep going I had in dot add database checks as well so if I want to make sure that my app also has database connectivity I can also set up connections to my database backends and if my service is not connecting to the database properly then then we returned in on healthy response as well and this is really helpful when you're running in to microservice development and you're deploying onto your cluster or into your containers and you want to make sure that when you're doing these rolling updates that your service starts up correctly and you're hitting your your health points that they're up and running so just by adding that dot add database checks is available now also in these Diagnostics as well so moving on to our docker images now containers is really at the core of building our micro services in some of the improvements that we've done and on a core 300 is really important when it comes to building doing that inter new inner loop development and making these more efficient as we're building out our services as a part of that making them smaller is is very important so when we look at our Debian based images previously under 2.2 there were 261 Meg's which is a decent size but now we've reduced that down to 207 and in Alpine images you'll see that we've got 166 down to 106 and that's a significant reduction in size when it comes to pulling those images and also scaling out then that's just the SDK when you're looking at the actual runtime here we're down to 88 Meg's on an Alpine image which is really nice when it comes to being able to pull those images and scale those out on the cluster when we're having to expand for those spikes in traffic now Glenn mentioned in the keynote briefly about building out the new worker service now a worker service is a new template now we have available to us in Donette core 3 oh that allows us to build those types of services that don't necessarily rely on an HTTP request these services are much like that Windows service that you would create has long-running processes that just needs to continually run and do work without having to rely on some sort of a request these are also services that we can expand to do work similar to a system D data system daemon service on Linux was simple simple support really easy to get started with this it works on the generic host and a generic kosis much like our our web host except it does not rely on anything that's web specific the web host builder is built to kind of pre pre run the kestrel this year is just to host any generic service that's built on on on the I host builder and in this specific example here we just have a worker service that's going to add a host of service and be able to run in order to expand that to run a Windows service we're just going to add a new get packaged very simply using a hosting that Windows service nougat package and then add one simple line called use Windows service and similarly if we want to run the system D service on Linux it's the same example for us to make that change we add the Microsoft extension hosting systemd nougat package and then this add new system D and then all of the other nice features of dotnet core is available to us such as dependency injection and all of the other features of our middleware are available to us here so let's see what that looks like I'm gonna hop out to my Ubuntu wsl and very simply we'll just use our dog net new just a worker and when we can out directory of worker and here we're just using the new templates gonna create a worker service and we'll see what that looks like in vs code so we'll open this up I'm TS code to see how this looks like and it looks like it's kind of unpack a couple of things for us on our ABS code server which means we got a quick update no right so what this is going to show here's just a template we'll open up our worker real quick this is gonna look like many of the other templates that we've had in dotnet core 3 Oh again it just works on the generic host and by default we're gonna have our loggers an ilogger and we'll execute a sync with the cancellation in this particular the template here it's just going to wait for a cancellation token or a cancellation request to come in before it shuts down the service in our program CS you see you use this create host builder does the build run we don't want to do that right now and it's just going to run our worker service so we go look at worker real quick and what's this doing is basically is every second we're just going to write out to the console that we're running at a specific time so if I go back out to our con man line here and then boo - I just do our simple done at run oh I actually have to go into my worker let's clear that and do dotnet run so this should run just like any of our other dotnet applications and we should the expectation should be that it's just actually gonna print out that we're running here you'll see that we're workers running which is really great now we could to add those NuGet packages and either set this up as a linux service or as our window service but we should in the interest of staying with our theme of building our services that would run on kubernetes I thought it'd be nice for us to put this in a docker container because I want to run this on my cluster maybe to do some other work later on so what I'm gonna do is I'm going to add a docker container here and we'll pick dotnet core we're running on Linux and sure why not so now that we have our docker container in here it'll just produce our worker here I'm going to use kind of the power of the cloud to build this and I'm going to go ahead and use my Ashur container registry to go ahead and build this out for me so I'll do this build and I'll go ahead and tag this as my worker service if I can spell here service one and tag it latest I need to pass my registry and the context so what we'll do is we'll actually take our worker service and we'll send it up to up make sure my my docker file is in there where did it at my docker file oops let's just do it this way we'll build our image Mayan worker doesn't seem to find my work or file there all right so we did this earlier we're gonna go ahead and go up into our worker so we've got one built here so we've got a latest and we can actually run an instance of this we can run an instance in our container let's say this is worker to run in and Linux here and we can deploy this container over to our an actual container instance so this run an actual AC ike instance of the actual worker and while that's the point we'll go and look at the our container instances we've got a worker side test here and we could fire this up to see how this is running so we could start that container right and the expectation would be that our logs would show the same thing as the actual container instance running which is which is great and now we can take a worker service that would run and you could expect that we could build us to take some things off of a queue and do some work and and then shut it down as we need to or just have it long long running process so we'll let that fire up and go on to the next thing here so endpoint routing is another feature that we have that basically as we were building out previous api's using MVC some of the feedback that we got was well I don't really want the V as a part as my MVC and what I want to build is just the actual endpoint here so I would like to build a lot of api's for my micro services that are out there and really all I want to do is just put an endpoint on on that work on that micro service because it's just doing specific work on a specific endpoint so as we saw with the health checks that's also using this endpoint routing as a way to return a response on a specific route so here we're adding app dot use routing and then we're saying use endpoints and mapping that /hello to a response and this is just part of a the simple web template that if I go to slash hello it'll return our hello world and I don't have to set up the the controller's or the models of the views as part of made me see so this allows me to do endpoints and services based on just a path as opposed to setting up the whole MVC without doing that so if I go into back to my booty instance here you can see what that looks like and we can just do don't add new and we can say web and we'll do a simple web output here all right let's see what that looks like all right so if I go into my startup we've got our points used routing we were mapping this here and again we could just come down here and map another in point if we wanted to same way it's a map in point nope we don't want to do that thank you map in points and I could do slash Shane if I wanted to and then have a response as well and then have that same do that same type of response for whatever endpoint we wanted to it's very simple all right so the last thing that we've got is our configuration so dotnet cork information a configuration is you know based on the key value pairs we have a lot of providers and the configuration providers read configuration data into those key value pairs and since 2.0 2.1 we've been able to use JSON XML any environmental variables now we have a sure out configuration as an option and there's a lot of other custom configuration providers as well so why is that important for micro-services and that really comes into kubernetes so kubernetes provides two primary mechanisms for configuring their apps and what does config maps and another is is secrets so in the secrets here is basically the kind of what we've been doing in asp nightcore where we don't want to deploy our database connection strings and other secrets with our app settings but we want to create a file and be able to put them into into a location that's but that's private and secure so in kubernetes we can create a secret with a key and also pass that file in there and that will create that generic secret on the cluster or pod that will that can be used with by the application so in the actual like deployment llamó file we'll notice here that we've got the key points here and the volume we're creating here we're creating that secrets back so if I go back to the previous slide here what we're doing is we're using the file secret saw Jason with that secret connection so if I'm connecting to a database I'm going to create that on the pod and then I'll reference that in that volume that I'm creating on my kubernetes cluster on the pod under / a / / app / secrets and then using that as a key value now in my asp net Chordata net core application I'm gonna use that adjacent file as the config in my configuration builder in order to reference that and now it's going to be available to me on my pod now the good thing about that is is it just works I don't have to think extra about how I need to reference that information in my kubernetes configuration as a developer I'm just doing it as it makes sense to me with any other configuration it's the same as in any file or XML file I'm just adding it to a path that I think or should exist on on the actual infrastructure that I'm deploying to so we're going to look at this example here if I just open up the full example actually let's go back and check on our sidecar test here looks like we should be running and if we look at our logs for this container let's refresh that our logs are available we can actually go check our logs here I'll refresh them and now our worker is sending back our logs which is pretty great alright so now let me look at our worker here too many CDs alright so awesome so open up this app and this is a full worker file that basically will work as a sidecar for us but what I want to show here is in our sorry that's the wrong map we won't actually look at the web application that has our configuration in it so in our code in our web application we've got our our kubernetes deployment files and that's what we're mapping all of our configuration here we go so let's see if we can all right so here's our kubernetes file for our deployments for the actual web application and then we also want to look at is the worker and the worker file is using that configuration to where we're setting some environment variables we also have a secret already set up in order to set our configuration to our an azure table storage that's set up as the secret as I shown in the on the slide before so what I want to do now is we'll walk through and look at setting up a worker that I've set up as a container we deployed to a CR and that work and we've set up as a way to work as a sidecar to monitor that healthy endpoint you'll see that here and our values that this worker is configured to hit a healthy endpoint and report back as a log washer basically to make sure that we're up and running and it's going to report that into table storage for us so this is an example of a worker that's just set up in a container kind of as a long-running process very similar to be a Windows service that you went running under a box on your desk to as a watchdog service to make sure your apps are up and running so what I want to do now is take all of this and basically push it up to kubernetes and make sure we're up and going so just as we go out to our configuration and we need to clear this out so now I want to deploy all this out to my cluster and if the cloud is working great for us today no I'll get let's look at our cluster make sure we're running all right so we votes no service is currently running out there so now what I want to do is first apply our worker service actually let's actually put the web out there first appointment so that's good to go and then now we're going to actually set out the worker service the deployment we'll deploy our web service out there now we want the worker service to be out there so it's going to check and see if it's up and running all right so it's clear and then we actually look at our services all right so it looks like simple web as being loaded with waiting for that public endpoint and the worker sidecar is also running so what we do is still do queue queue control and we'll get services let's see if we get a public IP look our public IP is running so now we can go look at our super fancy web website make sure that's up and going all right so HelloWorld is working that's fantastic check our health endpoint because that's what our worker service is going to hit Oh healthy can't be found this might be a good test for a worker service alright now we can go check our logs let's take this down here so our logs are actually going to ride out to our table storage it's already written 231 so we go all the way down to the bottom what fresh you can see here it's the bug it's starting you see our workers running is hitting our start we're getting some information here let's go back to the end one more refresh long and the web app is good to go so now we've got a sidecar worker service that's really not related to the actual application you can imagine we have multiple applications on there multiple services to check those health endpoints it makes it where I've been going and now it's hitting an azure table storage using Sarah log so we're using the other in the other services that are available to us to all these applications and all running in the kubernetes cluster we just make sure that we're still going here control here make sure everything is up and going awesome so now I have my super awesome hello world app it's being monitored by a worker service and I'm getting logged in at our table stores alright let's go back here and that takes me to the end of my time

Channel: Microsoft Visual Studio

Views: 10,832

Rating: 4.246377 out of 5

Keywords: .NET, dotNET, dotNETConf, dotNET Core, .NET Core, kubernetes, cloud native

Id: A0i5BUoKu6s

Length: 23min 49sec (1429 seconds)

Published: Mon Sep 23 2019