Azure Web Sites Secrets, Exposed!
Molnar, Nik
Microsoft’s premier cloud solution for custom web applications, Windows Azure Web Sites, has brought the DevOps movement to millions of developers and revolutionized the way that servers are provisioned and applications deployed. Included with all the headline functionality are many smaller, less-known or undocumented features that serve to greatly improve developer productivity. Join Microsoft MVP and veteran web developer Nik Molnar for a whirlwind tour of these secret features and enhance your cloud development experience. This beginner session is suitable for developers both using and curious about WAWS.
 Alright. Good afternoon everybody. Welcome to room number one. Azure website secrets exposed. My name is Nick Molnar. I'm from New York City. I decided to do something really smart yesterday. I got a horrible cold, so I'm not usually as sultry as this and I've been relying on cough drops to get through the day. It's okay though because I met some people on the internet here in Oslo and they gave me pills that I have labeling that I don't understand because it's not in my language, but they tell me that it should make me feel better and so far so good. But if I kind of like float away, you'll know why. I've been a web developer for a little over 15 years now. I created an open source project with my buddy Anthony called Glimpse that you may or may not have heard of. How many people have heard of or seen Glimpse? Okay, cool. Good number of you. That's great. We won't be talking about that at all today. And then the Glimpse project was sponsored by a company named Redgate that's based in England. So due to their sponsorship, I get to work on open source my baby full time in addition to go and get to speak to great developers like you at conferences around the world. I have become, I've been honored to become an MVP for ASP.net and I'm also an Azure insider. And Azure has become something that's a little bit more part of my world as my day-to-day progresses because even though I see myself as a web developer, I was always kind of the software guy. I would let somebody else go into the closet in the back of the office and they were the ones, they were the server guy. They set up IIS for me, they set up SQL server for me. I never really dealt with that. And then the whole DevOps movement started and I sometimes I'll dabble into DevOps but I feel myself firmly being the dev part of DevOps. And Azure, particularly Azure websites has begun to change the way that I think about myself as being just a developer and becoming a little bit more of a dev op. So if you have any questions after the conference or just want to chat and be online with me, I tweet at nickmd23. So Azure, Azure is huge. It's this monolithic universal thing that we have applied one word which until a few years ago was just a color to me. Azure, as my coworkers like to pronounce it. I know lots of people who are MVPs in Azure and they know lots about different subsections of Azure but I've not met anybody who knows everything about everything. It's just too large now. You can't kind of get a grasp on the whole thing. So what I've decided to do is focus particularly on Azure websites and with that in this talk, I want to really dig into some of the nooks and crannies. Some of the things that maybe aren't as visible to you if you've watched other talks or you play around on the portal. So just a quick show of hands. How many people here have actually deployed an Azure website before? Okay, great. And I'm assuming the rest of you are interested in this technology and that's great. So Azure websites actually aren't that special. At the end of the day, it's infrastructure that you may know. I never knew because I let the guy deal with it in the closet at the end of the hall. I let the ops guy deal with it. But I've been forced to kind of think about it a little bit more. So for those of you who haven't seen it, let me jump in really quick and show you what I'm talking about with Azure websites. So Microsoft Azure, basically everything you do starts in the portal. The portal is this place where you can make new websites, make new databases, make new whatever the thing is that you're trying to create and monitor them and configure them, etc. So this is the new, brand new Microsoft portal. It's in preview. It's at a different URL than maybe you're used to going to. It's at portal.azure.com. And it's pretty fancy. You can click in here and it has nice little alien graphics. It has this concept of things called blades. I can click on this tour and you'll see this new blade pop up and as I work it kind of continues to work horizontally. But here's the problem with preview. It's beta software and it's really slow right now. That's my opinion. And so to save a bunch of time for everybody because it takes much longer to do this talk in the preview portal, I'm going to switch over to the old portal which you may have seen before and that looks like this. So I'm going to really quickly create a website for those of you who haven't seen it and then we're going to dig into some new stuff. So this is actually my personal account or I'm running a couple of different websites that I work on on the side. The Glimpse website is an Azure website as well but it's on a different subscription so you're not seeing it here. But I have a site that I call signatory.io which is for managing contributor license agreements against GitHub and something else called signatory which is a pet project of mine. So I'm going to go ahead and I'm going to say I want to create a new compute website. I'll custom create and we'll just go through the wizard. Let's go ahead and call this NDC demo. I want to create a new SQL database and the code that I'm deploying already is looking for a connection string called data context. So I'm going to make that the default connection string. Context. Great. The source I want to, the code I want to use is already on my GitHub account so I'm going to check that box so that we can publish from source control. Great. Next. Sorry about the water guys. I'm going to need to moisten my throat. So for the database, I don't really like this random name it gives so let's go ahead and just call that DB. It's a little easier to find. We will create it on a new server. I'll create a login and a password. Great. Okay. Now I get to pick where I want to pull my code from. Let's say GitHub. Next. You see this pop up window that was as you're going out to my GitHub account authenticating me. I'm already logged into GitHub so I came back right away and now I get to pick a repository that I want to use. I'm going to use a repository that I have called stack, full stack web perf. This is the actual demo code for my talk tomorrow. It's the second talk of the day where I'm actually going to be taking a look at this specific website and how to improve its performance on the network, on the server, in JavaScript, in CSS. Top to bottom we're going to make this website scream. But we'll just use the demo app for what we're looking at in Azure today. So I go ahead and I press complete and just like that I'm getting a website created. You can see it here being created. Azure usually does these kinds of things pretty quickly within the matter of a couple of seconds. There we go. And so now I can come in and you can see if I go to deployments, a deployment is happening. And so what is going on in the background, you can see that it's fetching changes. It's going to GitHub and it's cloning, it's downloading all of the code that I have on GitHub so that I can get it up and running on the web server. While that's doing that, I'll go ahead and turn on a couple of configuration changes that I like to have. I like to have logging enabled. So I'm going to turn on application logging. This is the logging that comes from my app. This is my trace dot write lines that I put in my code. Let me go ahead and turn that on to verbose. I like to see all of that kind of stuff. I'm also going to turn on web server logging. This is the logging that IIS gives you, the W3C standard log file format. I'll go ahead and hit save. And let's see if we're done deploying yet. Okay, great. We are. I'll browse to it. So a database was created, a website was created. The connection string was automatically put into the config file for me. At this point now, that website is being jitted for the first time. I'm using entity framework migrations in this website. So all of the data is getting populated into the database for this first request. And when all is done, we should see it. Now I'm American, which means a couple of things. I'm fat. A little bit. Self-difficating humor, a little bit. Okay. I love baseball. I'm in New York, but I'm not a Yankees fan. I'm a Miami Marlins fan. So what I decided to do was make and demo application all about baseball. But nobody in Scandinavia cares about baseball. So instead, I've made a website about clowns, essentially. But they're baseball clowns. These are the mascots of minor league baseball. There's 160 minor league baseball teams. And this website shows up their mascot. So if I wanted to, I could go look at the Texas minor league. And I can see all of the mascots that are available there. I can look at the winners of the mascot mania contest that happens every year. This is all the mascots compete and do stupid things, like throw pies in each other's faces. And you can see the winners here. There's some really great ones. Like this guy here, ballapeno. He mixes together jalapenos and baseball. So how can you go wrong with ballapeno? And there's other guys. Like Roscoe the P. Ray Rooster. This is not a guy that I would want to see in a dark alley. I have no clue what wrestling and baseball have to do with each other. But we're American. Why not some gratuitous violence? So this is my website. And so just like that, in a span of a couple of minutes, I have this database of this website up and running. So that's great. If you haven't seen it, that's Azure websites. So let's go ahead and dig into what Azure websites really is. Now, if you've been around the block with Azure a little bit or you've sat in a talk show and you may have heard of something called a web role, websites is not that. Web role, website, two completely different things, unfortunately, that they're named so similarly. Web roles are still around. And I've put a comparison of some of the things that you can do in web roles that you can't do in websites and vice versa. To me, I kind of feel like a web role is really more appropriate when you have something really custom, really enterprise, maybe a legacy code base that you're trying to move into the cloud. That's because of you get elevated startup scripts so you can install things on the machine that is running that website. You can have dedicated IP, virtual networks, things like this. The biggest flaw with web roles to me is deployment can take eight to 15 minutes. That's just too long for me as a developer. And I have to do a little bit more management of the box and I'm the dev half of DevOps, so I'm kind of uncomfortable with that. Websites, on the other hand, really suits me well. Everything runs through my source control and that's a dev friendly thing. And so they're kind of like tacked on ops in the way that a dev wants to do it. That means we're kind of using continuous deployment, basically. Deployment is very fast. Like, yes, that probably took about 30 seconds, but from a hold start, that's not too bad. And the example I just gave, we have some other options that aren't available with web roles like content backup, rollbacks, web jobs. Some of these things are all interesting. But if we stop and think about what really is an Azure website, it's not that different from what the ops guy that I let hang out in the back closet do. It's just like the hardware that you have had in the past. It's a copy of Windows running somewhere with.NET and IIS on it. That's kind of good news because the ops guy can still be quite comfortable. But there's this extra layer on top that is completely open sourced and available on GitHub called Kudu. And so I have the Scott Gu OctoCat here representing Kudu. Now, just to prove that Azure website is nothing special, what I'm going to do is I'm going to use the ops manager's friend here. This is IIS manager. And I'm going to make a change to the website that we just deployed in the cloud. So if I connect to a site, I'm going to type in NDC demo and I'm going to go to port 443 and I'll give it a name of NDC demo. That's arbitrary. My username, my password. Authentication happens. Great. I can name the connection. Finish. Cool. So now what I'm looking at is the standard IIS interface that I would use in my enterprise, but connected to the Azure cloud on that website I just created. So let me prove it to you. There's a whole bunch of things that we can see. Like I can look at application settings and you can see some of the standard NDC settings that are added to your web config. So web pages version, unobtrusive JavaScript enabled, et cetera, et cetera. I'm going to go into this HTTP redirect. I'm going to turn on redirects to my site and we'll just point to something ubiquitous like Google.com. Let me apply that change and now when I come back and I refresh, you'll see that my website redirected me to Google. And let me go ahead and turn that back off because nobody wants to look at Google the rest of the time. Apply that and now if I go back, I can refresh and my site will need to rejit and everything because I restarted the web server, but the site will come back up here in a second. So I show all of that to you just to say what really is websites. Well, it's standard IIS. It's standard.net. It's standard Windows. But this Kudu layer, that's the part I haven't touched. Let's really dig into what that is. You'll notice that I have a diagram here showing Kudu going off to all of these different source control providers. I have Bitbucket on the top and then GitHub and then Dropbox, which I don't understand why we use the word Dropbox when we talk about source control providers, but I've been guilty of using Dropbox as source control, so maybe it makes a little sense. And then Codeplex because everybody uses Codeplex. So Kudu is named after this animal. It's a real animal. It kind of looks like a goat that I wouldn't want to mess with, but he's there. It's interesting. It's a service that is different than most services we interact with today. Today, typically when I think of service, my connotation is a multi-factor service. There is one service that I interact with that might manipulate many different things, but everybody is connecting to the same service. So it's a multi-tenant service. Kudu is a single-tenant service, which means that for every website you create, an instance of the Kudu service is also created to go along with it. It's like a buddy site. These two things go together. And Kudu and that website are linked in a couple of interesting ways. As of right now, this might not always be true, but as of right now, Kudu runs in the exact same process as the website. It runs in the same sandbox as the website, and that means a few different things for you as a user. One, it means that Kudu has access to do anything that your website has access to do. Two, it means that the only thing that Kudu can screw up on that box that you're in is your website. So you can do things in Kudu that break your website. Three, it means that all of your quotas between your website and Kudu are shared. So CPU usage, memory usage, hard drive usage, all of that stuff that you're doing with Kudu is also going along with your website. So you kind of pay for it. So let's take a timeline look at what Kudu does. I basically like to think of Kudu as a very low-level continuous integration server. And I say that because it reminds me of seven, eight, nine, ten years ago when I was working on cruisecontrol.net, if you guys ever played around with that. Basically, cruisecontrol.net would watch some source control provider when the source code changed because you committed or pushed or whatever it was called and whatever flavor of source control you did back then. Whenever that happened, it would pull down those changes and then run some script. So the first thing that we see that Kudu does is it connects to the source control provider and it acquires your source when you change it. The next thing it does is it builds the code that it's received. Now Kudu works with lots of different flavors. I'm a.net guy, so I'll mostly be talking about.net, but it also works with Node and PHP and Java and Python. So if your environment, if your programming environment in Dejure doesn't require build like Node or PHP, it just doesn't build. But for.net, there is a build step, so there is a build. And then the next thing it does is it copies the assets into the WW root, the place that I serve content out on the open internet, whether that's the binaries that have been compiled or it's just the source that run in interpreted languages. And then finally, it does some post-actions. It says, hey, I'm done doing the main thing that I do and there's two flavors of that. There's post-actions, which you see first. These are scripts that you can execute. And the second thing that it does is it uses, I'll use the word technology loosely, it uses webhooks, which are basically the opposite of web APIs. So let me show you what that looks like. First, let's talk about these post-actions. Just a general note, everything that I do today is going to be stuff that you can't do through the portal or mostly can't do through the tools that Microsoft gives you. That's why these are the secrets. So the things that I'm telling you today are available and they're supported, but sometimes they're a little rough around the edges and a lot of it has been me kind of dancing through trying to figure things out or talking to people that work on the Azure team to get this kind of information. You may see in the future that some of these secrets will show up in the portal and it won't be much of a secret anymore because there will be a button that you click and it does the thing that I'm showing you how to do now. But maybe not. So this post thing is an example of that. So let's go ahead and just copy this little thing and cheat a second here. What I'm going to do is I'm going to go back into the portal and on the dashboard I get a URL to an FTPS, a secure FTP location. And a lot of people don't realize this, but Windows Explorer is an FTP client. So I just opened up Windows Explorer. I pasted that FTP address. I hit go. It's going to authenticate me. So once again I'll type in my password and my username was already there. And we are connecting to the site. Cool. I am now just FTPed into that box that I earlier connected to with Internet Information Services Manager, IIS Manager. So I'm connected that same thing via FTP. If I go into the site, I can see all of my content here in the WW root. I can start deleting things and changing things and you're going to see that live on the website. There's a bunch of other files and folders in here though that are not my website like this diagnostics, repository. This is actually where all my Git code lives and you can see my Git attributes and whatnot. But what I'm going to do is I'm going to go into deployments. Kudu stores all of the information about your deployments on disk. So that's kind of cool. But inside of tools I'm going to create a new directory. So new folder and we're going to call it post deployment actions. Cool. And inside of there I can add any number of scripts that I want to. So batch files or cmd files. So let me go ahead and just create a really simple one so you guys get the point. I'm going to say echo hello from post.bat. Let me save this as post.bat. Not nat, bat. Okay, great. And then let me grab that file. What did I stick to? I stuck it on my desktop. Users, Nick desktop. Post.bat. I'm going to copy this file and just, oh, let me copy it. Sorry guys. Copy the file and I'm going to drag it into this FTP window here. Cool. So I just uploaded a file through Windows Explorer over FTP to my website. Now, any time a deployment happens and instead of re-downloading all the code I'll just redeploy what we already have deployed. That script will execute. So I'm going to click on this deployment. I'll say redeploy. Yes, this should happen much faster this time because there's no source code to download. There's been no changes on the repo. So you can see it's deploying. Cool. We're done. If I come through here and look at the logs you will see that I have executed that file and it's saying hello from post.bat. So obviously I just echoed. That's not really anything interesting. But in this scenario any post steps you would make after deploying something you could do. So priming caches, building contents, a CDN provider, anything like that you can all do in these scripts. You can have multiple ones. So you can have one for each different task you're doing. And Kudu will run them in order, the same order that you see them in Windows Explorer. And if one of them errors returns an exit code of zero it will just stop there and the rest of them don't run. But that's kind of cool, nice little hidden trick that you can do to do things after the build has happened. So that's this post action, the one on the top. But there's also this web hook option which is really handy for guys like me who are web developers. I'm not super comfortable getting down into like scripting batch files or whatnot. But web programming I'm all about. So let's take a look at how the web hooks work. What I'm going to do is I'm going to go to this website called Zapier. Zapier is similar to if this then that, if.com if you're familiar with that website. I like to think of it as programming my mother could do. It's very simple like draggy, dropy, point and click kind of thing. So I'm going to make a zap. And the reason why I'm using Zapier is because the Azure website's team has worked with Zapier to have a nice experience specifically for websites. So when I create a new zap which is basically an if then block of code, I can choose what my if is going to be my trigger. And I'll do a search for Azure. And you can see I have Azure websites. So when this happens, either when a web job is run or a site is deployed, that's the one I care about. So when a site is deployed, then what do I want to do? Now I use this all the time for my side project, which I call Glutly. And what I have Glutly do is send me a text message on my phone every time a deployment happens. So that looks something like this. This is literally a screenshot from my phone. You can see there that my last deployment was successful. I have a URL so I can click and go right to that spot. And you can see I fixed the bug resulting from multiple restaurants being added to a database. I'm American and I don't have a SIM card that works here. So we're going to do something a little bit different, but it proves the point of how easy it is to plug and play with something like Zapier. So instead we're going to go to Twitter, because I do have an internet connection here. And we're going to send out a tweet anytime a deployment happens. So that's what I'm going to do. So when there's a new website deployment, I'm going to create a tweet. Like I said, my mom can do this. Now we need to tell Zapier about my website. And so if I say connect to an Azure website account, you'll notice here that it's asking me for a deployment trigger URL. Well, what's that you ask if you go into the portal and you go over here to configure, there is a field that has just that URL. So I'm going to copy it. I'm going to come back to Zapier and I'm going to paste it. And then we'll give a name to this connection. So this is going to be Azure websites. This is for the NDC demo. Great. Continue. And so you can see here the account is working. Zapier and my website are now communicating. And that communication is happening because the Kudu web service is there. I never see it, but that's what's going on there. I can press continue. I'll make this go to my Twitter account, NickMD23. Continue. I can add filtering so I don't always do this. We'll just skip that step because I want to prove the point to you guys. Continue. And so we'll say deployment happened. And I can put in variables. So if I say insert fields, Zapier now goes out to that web service that Kudu is hosting and it will show me all of the fields that I have available in a moment. Hang tight. Can take a minute, apparently. There we go. So you can see I can use the message, the status, the author, the deployer, all of these different things. We'll just go ahead and put the message into the tweet. Continue. And click the button to test. That's fine. And we're good to go. Oh, I need to name this Zap. So we'll also name this NDC demo. Cool. Turn Zap on. And now, anytime I do a deployment, the website will tell Zapier. Zapier will see that anytime a deployment happens, I should be doing a tweet. And you can see that this thing is on Azure websites to Zapier. So what I'll do here is I'll come back to my website. I'll look at my deployments. We will redeploy, just like as we did before. And while that happens, we'll go over to my Twitter stream to see the tweet come through because the tweet will come from me. I'm a big foodie, as I already mentioned. So you might notice that last night I went out to dinner here in Oslo and we decided to have whale meat. This is not something I'm accustomed to in the States. It made me kind of think that I bet Twitter never fails in Oslo because everybody knows the famous fail whale. You guys would eat it. So Twitter just, it's like we're not going to fail in Oslo. We'll kill our beloved mascot. So that deployment should have finished. It has. Let me go ahead and refresh my Twitter stream. All right. We're still waiting for Zapier to send the tweet through. There we go. Deployment happened adding, tracing for Azure demo. So just like that, a tweet has happened. Maybe it's told all of them, everybody who cares about the website that there's a new version. I'm going to go ahead and delete that tweet so my followers don't get irritated with me. So that is using the web hooks that Kudu allows you to use. Now, all of these steps in the pipeline are extremely configurable and this is something I find that nobody really knows about. So let me show you the configuration points. All of them. So the first thing is you can change the way that Kudu interacts with your source control provider using app settings. I've shown you some of the app settings here. There are more available in the documentation which links are provided for at the end of the talk. So in the app settings, which I will show you really quickly in the portal. If I go to configure, here are my app settings. These are just key value pairs. If I use the right named key as shown on this PowerPoint, these app settings, I can change things like the path in which Kudu will clone all my code or it will say not to use a repository which is what happens automatically with Dropbox or the target path. So you can do really interesting things like do in place deployments. So you can have the code copy right from the repository into the wwroot. So if you just want to deploy your assets already built, maybe you handle the building, you can just flip a couple of switches here and it will grab it and just stick it right in wwroot and you're serving it. The next thing up that we have here is this Iini file which is a little archaic but I guess I would prefer that over XML. There's all these other settings that we can use. So one of them is you'll see this SCM post deployment actions path. So I just had the FTP into the site and go into this tools and deployment directory to put that post.bat file there. Well that's kind of a pain in the butt. What if I just wanted that to be in my source control? That's fine. I could have put that script right in the source control as long as I go and I change the setting and I tell Kudu when you're done, don't run the things for the scripts from where you normally get them, run them from this path that I've given you. So you can override basically everything. And then finally kind of the Mac Daddy, blow everything up and change it, this dot command file. Essentially everything that Kudu is doing, you can stop and say, hey Kudu, will you write down your logic for me into a file so I can change it? And so you can do that. Let me show you what that looks like. I am here at the command line. I've already installed the X platform Azure CLI tools and I'm looking at full stack web perf. That is my repository, my directory where I have all of this code for this mascot website. So I'm going to say Azure site deployment script and that takes in some parameters. This is going to fail. Basically that's the command that I tell Azure to say, hey, persist all of your logic. So what I need to do is I need to tell it first of all that it is an ASP web application. I need to point to my project file so that's in the directory structure. Actually let me show you the directory structure. So you can see that I have a folder called demo. I have my PowerPoint slides for that talk. I have a demo script, etc., etc. So I'm going to say that it's an ASP web application that lives in demo slash minor league baseball web. Minor league baseball web, that's my CS project file. The other thing that I need to do is I have to say that there is a solution file at demo slash demo dot solution. If I run this, it already exists, that's okay, I'm going to overwrite it for this. It is just gone and written in two files to that directory. So let me go back to DER and you can see that there is this dot deployment file here and this deploy dot cmd file here. So let me go ahead and open up in notepad that dot deployment file. This is the INI file I mentioned before that we were talking about. You can see here that I'm telling Kudu the command that you run after you've downloaded all of my source code is deploy dot cmd. That's the new file that just got created. So you can create your own, you can override, you can do whatever the heck you want to, you're just overwriting what Kudu does right from this spot. If I open up that deploy cmd file, oh, nope, I have to spell it right. You can see here this is everything that Kudu does. It looks big, especially when I scroll really fast like that. It's not too bad, it's very well commented. You can see here that essentially it goes through and sets up a bunch of environment variables. These are the variables that you can override from app settings. You can go in and change any one of these. So if you want to change the deployment target, you can go into the portal, add that as an app setting and that will override this deployment target because you can see it's checking to see if it's already defined first. So you can define it there. It comes through and here's where it does the meter that work. The first thing it does is restore new get packages, then it builds into the temporary path and then it does the sync. This is where it takes all the built files and moves it over into your wwroot. So that's cool. If you want to change anything about how this works, you can go in there and do it. If you don't want to go hog wild, here's where it's actually calling MSBuild to do the build. You'll notice at the very end of both of these lines, it's passing in this build args. Once again, this is another setting that you could put in your inifile or in your app settings to say these are additional build arguments that I want passed into MSBuild when I build my site. So you don't even have to go this far. I've gone this far in a couple of my sites, that one that I showed you where I was texting myself. Let's go ahead and look at that deploy file. I don't want to run it. I want to edit it. So you can see that in this file, the standard thing, restoring the new get packages, building, blah, blah, blah, I've gone in and I've added unit tests. So my unit tests basically, oh, here we go. This is the unit test. Sorry. Really just change the directories into where my X unit runners are. That's just a package. So if I look at my packages, you can see all of the different packages and there's the X unit runner is in there somewhere. I use this little handy trick of using a star here, which you can use with change directory because I never know what version of the runner is going because that all gets handled through new get. So I change into whatever the version I happen to have is and I run it. And if there's an error, then I error out and I continue and that deployment won't happen. And then I get text and I'm told that there was an error on the deployment. So that's great. So basically I have a CI server, a continuous delivery server, all in one with four lines of code that I downloaded from the end unit website. So that's great. I can create that command file and basically do whatever I want. Now Kudu does a couple of other things besides just this deployment and building that we've talked about so far. Oh, don't go. We're going to miss you. Have a good day. It does a bunch of debugging and diagnostics and makes that information available for you in ways that would kind of be difficult to do on your own because you're in the cloud. And that's what the special star.scm website. So what I'm going to do is I'm going to come back over here to my browser. I'm going to copy the website that we've been using all along. So this is the NDC demo Azure website. I'm going to paste it and all I'm going to do is I'm going to add in.scm into the URL. So every Azure website that you have right now already has this thing enabled. You just don't know about it. And that pulls up this Kudu page which has all kinds of really useful, interesting things. So the first thing that you'll see is environment, which shows you a bunch of information about the system that I'm running on. I am running on a 64-bit system, but I'm not in a 64-bit process. I have one processor, blah, blah, blah, blah. I can see all of the app settings, the connection strings, the environment variables, all kinds of good, useful stuff for when you get into a jam sometimes. There's also this Process Explorer that I can click on. This is actually an HTML version of Process Explorer. If I hit Control-Shift-Escape, this is my normal task manager that I get for my local machine. I'm looking at the exact same thing now. I'm looking at the same thing now for my remote machine, just an HTML version of it. I can dig in. You can see my W3WP, that's IIS is running. I can dig in and look at the properties there. I can see all of the threads. I can look at the properties of a thread, et cetera, et cetera. I really like this handles. So if you ever get a locked file, you can see which process is holding on to that file. You can go in and you can actually kill the process from this UI. So that's kind of cool. There's some other tools too, like you can download a diagnostics dump. If I click on that, it's going to give me a zip file that I can run through with some debugging tools. There is this Log Stream. Now, this is streaming logging. This is showing me all the logging information that's happening on my website. So if I come back to my website, let's go to a split screen here. As I click around, I go into the Appalachian League and you can see that that log happened. I go back to the home page and you'll see there's the home page. I can go see all the winners. I'll see the winners. So I could be watching this log as hundreds and thousands of people hit this website if it was well known and I could see what's happening live on the website. So that's kind of a cool tool. There's a few other things that are interesting. Oh, web hooks. This is funny. So if you didn't want to use Zapier, this is where you could come and configure your own web hook. You'll see that Zapier has already reached back into Kudu and set itself up as a web hook. But I can type in any URL that I want to right here and any time a deployment happens, Kudu will post deployment information to that URL so that could be a local service that you're running in your enterprise to update some dashboard that sits in front of your manager to let him know that a deployment happened. So that's all good stuff. The last thing that I'll show you, I'll show you two more things in this Kudu. All of Kudu exposes a RESTful JSON-based API so that you can get at this information programmatically. So if I wanted to see the app settings for this website, here they all are and, Jason, you can see that I'm just going to API slash settings. If I wanted to see all the deployments that have happened in this website, I can open that up and here's the deployment. I like this files one. This basically gives me the file system that I was looking at at FTP in a JavaScript way and I can just drill through and say, okay, I want to dig into site and I can follow this link that gives me for site. I want to dig into WW root. I can follow this link to get into WW root and boom, there's my packages config, my scripts, my snippets, my views, all that kind of stuff and I can build a whole file browser just using these APIs. And then lastly, Kudu has this debug console. It has a PowerShell version and a command EXE. I told you guys I'm not much of an ops guy so I shy away from PowerShell. I'm trying to tell me this for developers. I'm not buying it. So I'll just use the good old command.exe. If I come into that, I am actually now looking at a terminal on the machine that my website is running on. And so if I go CD into site, not only did I change directories but you'll notice that the top part, this HTML table has changed and it follows along with what I'm doing in the command line or similarly if I click on WW root, you'll notice that the command down here changes WW root. So I can go in there, I can check things out, I can look at the file system, I can do whatever I want to without having to go into FTP. So this is all quite handy and something that Kudu gives us which is nice. Now, everything that I just showed you there might be a little bit scary because I'm giving you a lot of access just by knowing the SCM part of the URL. That's where I want to stop and take a step back. Kudu is interesting. It runs on the same process and the same sandbox and all that stuff but unlike your actual website which is not authenticated by default, everything inside of Kudu is. I was just already authenticated so you guys didn't see the challenge. Now, there's multiple types of credentials that you use in Azure and this is kind of confusing but as far as Kudu is concerned there's two and they're called deployment credentials. So typically when you log into the portal or something you'll use your Microsoft account, right? Kudu doesn't care about your Microsoft account, it doesn't know what that does or follow it. Instead, it uses either user credentials which you know user credentials from the portal because on the dashboard you'll see this thing that says reset your deployment credentials. That is a user credential. You have one. You have one of those for every single one of your Microsoft accounts which means if I change the password there, it's not just changing it for my minor league baseball website, it's also changing it for GitGlimpse website and it's also changing it for that signatory website because that set of credentials is stuck to me. Never give out that set of credentials. They're yours. If you lose control, you go in there and you reset it and it'll reset everywhere. The next one is site credentials. These are ones that are made for you to give out. They're generated for you but they're specific to a website. So I have four sets of site credentials, one for the minor league baseball website, one for signatory, one for GitGlimpse, etc. They're auto generated so you can tell a site credential because it begins with a dollar sign and the username is always dollar sign and then the name of the site that you're using and then the password is some long messed up GUID. You can actually see this because if I went back, you guys remember earlier we had a copy and paste something into Zapier which is that trigger URL. Look at this. You can see the name of my site is NDC demo and you can see dollar sign NDC demo here. That's that automated username and you can see here's my password and Kudu is just using HTTP basic auth when the client makes a request to that. It rips those things out of the URL, sticks it into an auth header and that gets sent off that standard HTTP authentication stuff. But there you can see that. If you download your published profile which is available from the dashboard, reset your published profile credentials, I could download it as well right here, download your published profile. That's just an XML file and if you dug into that XML file you'll find that exact same username and password. And most of the tooling that you'll use that wants to connect to Azure for you will say give me your published profile. So you're giving it a set of site specific credentials and if you lose control you can reset those as well but those are site by site. So everything in Kudu, you're good, it's authenticated using one of those ways. Great. So we've looked at a whole bunch of different things that we can do with Kudu and the process but I want to stop and also think about what are the ways that we can kind of configure Kudu to do additional things. And it's not even just Kudu but IIS and.NET and what is afforded to us. So this diagram I made, parts of it should be pretty recognizable to you. So everything in all the blue circles, that is the standard.NET configuration scheme that we've known since day one, right? There's a machine.config, there's a root web config, those things get merged in and then you can have web configs and directories going down farther and farther, deeper and deeper and they all get merged together into your application. And that makes web config and if you're running an IIS 6 or before, that is the whole story, just the blue, the dark blue, those three. And IIS 7, they added a new configuration file called application host.config. These are IIS specific settings and that file gets merged in along with the web root. So now you have IIS and.NET code intermingling. In Azure there's yet one more layer which is this Azure overrides and these are all of the configuration settings that you've put into the portal. So all of these things come together to give you final configuration, stuff that you've typed into the portal into your web config from the app host. Microsoft gives you an app host. Now you'll notice that these two of these have a little bubble that says xdt. That's the web config transform schema that's available. You probably recognize this from Visual Studio when you create a new project underneath web config, you have web.debug.config and web.release.config and you know you can make changes there so the release mode and the debug mode look different. That's called xdt. That exact same file format schema is available in Kudu to run on your app host so you can change IIS settings. So let me show you what that looks like. I'm going to go into Kudu again. I'm going to go to this, oh I'm already in the debug console. Great. I'm going to upload a file. So I have this outer curve SVG. This is an image, a scalable vector graphic image so I can zoom in forever and it will always look good. Outer curve is the foundation, the open source foundation that Kudu is a part of. I'm going to upload that to the site. I can do that very simply because I'm looking at my ww root right now. If I drag this up to the web browser, like I said it's kind of an FTP client, I can just drop it and that's going to get uploaded and now I have outer curve SVG. So if I go back to my site, now I can say slash outer curve SVG. But I get an error. Well, that's because by default IIS doesn't know what to do with SVG files. It's easy enough to change. You just go in and you add the file extension and the mime type and you're good to go. But we want to do this in a Kudu way, a way that's reusable. So Kudu allows us to, I'm going to go up one directory so I'm looking at site. It allows us to put one of these transform files in. So I have this application host transform file right here. I'm going to upload that to the site. And now that that's there, I need to restart the site. So let me go to the portal. I'm going to stop the site. I'm going to start the site. Okay, great. The site is starting up now. So because Kudu solved that file with that name and that location, when the site restarted, it said, hey, this user wants to change application host.config. I'm going to apply that transformation. And I'm going to show you that transformation in a second. But now if I go back to this page and I refresh, you can see I'm getting my outer curve SVG file served to me because I added that other file in that one spot. So what does that file look like? It's quite simple. This is the entirety of the file. So I'm using the XDT transform. So I'm inserting an element. I'm adding any file that ends in.svg to serve it as a mime type of image SVG plus XML. I'm also going a step further because I care about performance, which you'll hear more about tomorrow. I'm saying that image SVG is I want to do HTTP compression. So that's that whole file and boom, now my whole website can serve SVG files. This is a pretty simple example. And actually, this example I could have just baked right into my web config and checked it in. No big deal. But Kudu goes a step farther. So here's another example that you might want to use. This is increasing the length of the queue that IIS holds. IIS has a queue. It's a number of requests that it will hold on to. And once you go past that queue, it will start issuing 503 responses. It will say service unavailable. I think that that number by default is a thousand. In this example, we are once again doing a change. We're changing an attribute. That's what the set attribute does. I'm changing it to 5,000. So more people will wait longer before they get service unavailable on my site. But notice there's this XDT site name that's surrounded in parentheses. There's a token there. What's cool about these apphost.xdt files that I can upload to Kudu is it will scan them for certain tokens and replace them with runtime variables, which means that this file I can now upload to any website that I want to because the name of the site, which normally would have been hard coded, is now variable. And you can see there's a couple of different things. There's a site name, there's the app pool name, there's an extension path, etc., etc. That one difference, that one thing that Kudu does opens up a really interesting universe to us. So let me show you another file. This file is going to add something that Kudu calls a site extension. What a site extension is is really just us leveraging the power of virtual directories, which I've never really used before. But now I can take this file. You guys can literally copy and paste this from my slides, change these two variables where it says extension name, and we can start to put things into Kudu ourselves that are authenticated. So we can give our administrators a place to add them in the website completely. Stuff that is is specific that I've already showed you in the Kudu website, and stuff that is important for our app. So let me show you some examples of this. Actually, you know what, no, let me make sure that this is really hitting home. So this is Azure website in a architecture diagram. There's the user site that sits on top. There's a buddy site right next to it, right? That's kind of what our site extensions. The site I've already been showing you is actually a Kudu site extension. It's just this virtual directory kind of thing. And Microsoft installs some of them for you by default. So Kudu, we've already looked at. Visual Studio Online, you might have seen. Web Deployer, Web Jobs, you might have seen. Microsoft puts those there. And if you want to partner with Microsoft and call them and have one built in, they allow for that. But we're not going to do that. We're just regular users and we're not trying to change the way Azure works in general. Instead, we can either install an existing one or we can upload our own. So let me go back to Kudu. And I'm going to come over here to site extensions. And you can see that from my site, I'm on the installed tab and I don't have any extensions available. So I can go to the gallery. Now, this morning when I did my run through, there was an additional option here that put in an IIS log analyzer that would tell me where my traffic comes from and how many hits I have and all these kinds of things. It's gone. Which stinks for you guys because it's kind of cool looking. But it's actually a teachable moment because you can kind of see already where Microsoft is going with this. The reason why it's gone and I had to dig through the Kudu source code to figure this out is because all of these things are just Nuget packages. And it's fed by some private Nuget feed somewhere that Microsoft controls. And that was the one I want to show you was a package on there. And they've removed that package from the feed. That's fine. I'll install another one. It's less impressive, but it'll still give you the point. I'm going to install this file counter. The source for this one is available on the Internet. It's the only one that I know that source is available for. I'm going to press install. And you see I get this little thing that says restart the site. There's actually a bug with restarting the site. Both in the portal and on the site extensions. So I'm just going to stop and start. That's kind of the way to make sure that it really restarts. And so now that I've done that, I have this little play button available on file counter. And file counter is amazing. You ready? I press play. Oh, hold on. It's still starting up. Told you it's amazing. Okay. There we go. The world's most amazing file counter. Your site has 539 files. All this is is a tiny little website that knows where it's sitting and it counts all the files that sit inside of my www route. Spits that back. Not very useful, but you can make it do anything that you want to. Let me show you one that's a little bit more useful for our application. And obviously I can come in here and I can uninstall this thing. And you can imagine a world where there's all these admin tools. I'm not a PHP guy, but PHP MyAdmin is very full featured. And if this is a PHP website, that would be kind of cool to show you. So what I've done is on our minor league baseball website here, every year the winner of mascot mania changes. So this year it's this guy here, Lucille from the Columbus Clippers. And you can see that he's kind of the hero of the website. He's the big picture that you see. And the administrators of this website are constantly saying, hey, there was a new mascot. Can we change it? And I have to go in there and I have to change the code. So what I want to do is I want to give them an administrative tool. But there's no authentication on this website. I don't want to build out authentication. I just want them to be able to use the credentials they already have with Azure to log in. So what I've done is I've created this simple little file, default ASPX. And this is like, I've made it really simple and ugly on purpose because I don't want you guys to focus on the code. But essentially what it does is there's an if statement. If it's a get request, I build up an HTML form that has a select or I'm looping through and writing a bunch of options. And if it's a post, I do some updates to the database. What's important to note is because I'm running in context of the website, I can still get the configuration manager to give me the data context. I have access to all the variables that the website is already using, so I don't have to ask for any input. So to install this, I have created this application host XDT. This is the exact same thing that I'm showing you here, except for the word extension name has been replaced by hero. And so I'm going to take these two files, and I'm going to upload them. So I'm going to come back to the Azure portal. I'm going to go to the debug console because that's the easiest way to upload things. And you'll notice that there's a new directory now that I installed the site extension right next to site called site extensions. So that's fine. Once again, this just follows the convention. I'm going to add a new folder called hero. I'm going to go inside of hero. I'm going to upload these two files, drop them. Boom, they're there. Once again, I made a change here. I need to restart the web app. So let me stop it and start it. Okay. So if I go back and look at my mascots, I'm refreshing. It's going to take a little bit because of the jit, but we'll still see Lucille as the main winner of the mascot. Contest. Wow. Come on. Come back up, Azure. They promised me that this restart thing has been fixed in the new portal, but we'll see. Yes, because deployments, the question is could you use deployment stops? And the answer is yes, because the deployment slots are still spinning up and the process is new, and so kudu when it spins up, we'll do all the configuration stuff. Yeah. So since I named this hero, I should be able to go to hero. Okay. Now my website is really dead. Let's see what's going on together. Wow. Really dead. I'm not even getting console. Well, this is fun. I am stopping and starting to write website. Okay. Well, let's do this. I could check the logs, but I'm not going to go splunking through all that stuff with you guys here. So let me try one thing. Let me. Okay. This is good. The fact that I got this far is great. This is a good sign that this is working now. That's not a good sign. I'm wondering if I screwed up something in my file. Come on, guys. This is the big demo. This is the one you're on. You're like the edge of your seat, right? I've never screwed this up before. Oh, man, Azure is really killing me here. Okay. You know what? I have another option. We're going to use all the tools that we've learned about in this talk right here right now. Just pretend that I meant for this to happen and it would be awesome. I'm going to use FTP and see if I can even FTP in. So like I told you earlier, this stuff is rough around the edges right now. I can go into the site. Nope. Oh, interesting. The site is back. Hey, thank you. You can hit it, but I can't. You might be coming up here to finish this demo, buddy. Well, okay. So the point here is what's supposed to happen is can you, oh, you can't hit this URL because you can't authenticate this. Let me try another browser. Good call, Anthony Van Der. Hey, hey, hey, hey. That's what you wanted. Okay. Is this one? Everybody hold your breath. So what we have here now is in Hero. This is the admin thing. This is that super simple page I showed you. I have a drop down of all of the different mascots and I can pick who was the winner. So who am I going to pick, guys? Come on, Bala Pino, of course. So Bala Pino, I hit submit. That's now updated. If I could get the website to run, which it is, if I hit refresh now, Bala Pino. Stuck the landing, so, so. You guys are cruel. You only laugh when I call myself fat and when I failed. I understand Norway. So that is the bunch of the stuff that I wanted to show you guys about Azure and the different things that you can do. Now here's the big secret that I've learned screwing around with all this. Even in that moment of panic, I did not plan that, I swear. Even in that moment of panic, I felt safe. And the big secret to me to Azure websites and why you can feel safe goes like this. I'm a chef. I like to cook a lot at home and whenever I talk to people who are my friends who want to cook, they say, oh, I don't know how to cook and what if I ruin the meal or whatever. Here's the deal. If you ruin a meal, it's 20 bucks and you can get pizza and you save the meal. When I was working on hardware in that back closet, I was always afraid because what if I screwed up the hardware? It's thousands and thousands of dollars. Let me show you what happens if you screw up the website and Azure websites. One button, done. I've just deleted the website, the SQL server, everything gone and I can recreate it in 30 minutes. That's the big secret. You don't have to be afraid because it's that fast to reset. It's a couple of bucks, it's a couple of minutes and you can reset yourself. So that is what I wanted to share with you guys today. I have two minutes for questions if there are any. Awesome. Guys, thank you very much. I hope to see you tomorrow. Tweet me if you have any more questions. Thank you. Thank you.
 Alright. Good afternoon everybody. Welcome to room number one. Azure website secrets exposed.  My name is Nick Molnar. I'm from New York City. I decided to do something really smart  yesterday. I got a horrible cold, so I'm not usually as sultry as this and I've been relying  on cough drops to get through the day. It's okay though because I met some people on  the internet here in Oslo and they gave me pills that I have labeling that I don't understand  because it's not in my language, but they tell me that it should make me feel better  and so far so good. But if I kind of like float away, you'll know why. I've been a web  developer for a little over 15 years now. I created an open source project with my buddy  Anthony called Glimpse that you may or may not have heard of. How many people have heard  of or seen Glimpse? Okay, cool. Good number of you. That's great. We won't be talking  about that at all today. And then the Glimpse project was sponsored by a company named Redgate  that's based in England. So due to their sponsorship, I get to work on open source my baby full  time in addition to go and get to speak to great developers like you at conferences around  the world. I have become, I've been honored to become an MVP for ASP.net and I'm also  an Azure insider. And Azure has become something that's a little bit more part of my world  as my day-to-day progresses because even though I see myself as a web developer, I was always  kind of the software guy. I would let somebody else go into the closet in the back of the  office and they were the ones, they were the server guy. They set up IIS for me, they set  up SQL server for me. I never really dealt with that. And then the whole DevOps movement  started and I sometimes I'll dabble into DevOps but I feel myself firmly being the dev  part of DevOps. And Azure, particularly Azure websites has begun to change the way that  I think about myself as being just a developer and becoming a little bit more of a dev op.  So if you have any questions after the conference or just want to chat and be online with me,  I tweet at nickmd23. So Azure, Azure is huge. It's this monolithic universal thing that  we have applied one word which until a few years ago was just a color to me. Azure, as  my coworkers like to pronounce it. I know lots of people who are MVPs in Azure and they  know lots about different subsections of Azure but I've not met anybody who knows everything  about everything. It's just too large now. You can't kind of get a grasp on the whole  thing. So what I've decided to do is focus particularly on Azure websites and with that  in this talk, I want to really dig into some of the nooks and crannies. Some of the things  that maybe aren't as visible to you if you've watched other talks or you play around on  the portal. So just a quick show of hands. How many people here have actually deployed  an Azure website before? Okay, great. And I'm assuming the rest of you are interested  in this technology and that's great. So Azure websites actually aren't that special. At  the end of the day, it's infrastructure that you may know. I never knew because I let the  guy deal with it in the closet at the end of the hall. I let the ops guy deal with it.  But I've been forced to kind of think about it a little bit more. So for those of you  who haven't seen it, let me jump in really quick and show you what I'm talking about  with Azure websites. So Microsoft Azure, basically everything you do starts in the portal. The  portal is this place where you can make new websites, make new databases, make new whatever  the thing is that you're trying to create and monitor them and configure them, etc.  So this is the new, brand new Microsoft portal. It's in preview. It's at a different URL  than maybe you're used to going to. It's at portal.azure.com. And it's pretty fancy.  You can click in here and it has nice little alien graphics. It has this concept of things  called blades. I can click on this tour and you'll see this new blade pop up and as I  work it kind of continues to work horizontally. But here's the problem with preview. It's  beta software and it's really slow right now. That's my opinion. And so to save a bunch  of time for everybody because it takes much longer to do this talk in the preview portal,  I'm going to switch over to the old portal which you may have seen before and that looks  like this. So I'm going to really quickly create a website for those of you who haven't  seen it and then we're going to dig into some new stuff. So this is actually my personal  account or I'm running a couple of different websites that I work on on the side. The Glimpse  website is an Azure website as well but it's on a different subscription so you're not  seeing it here. But I have a site that I call signatory.io which is for managing contributor  license agreements against GitHub and something else called signatory which is a pet project  of mine. So I'm going to go ahead and I'm going to say I want to create a new compute  website. I'll custom create and we'll just go through the wizard. Let's go ahead and  call this NDC demo. I want to create a new SQL database and the code that I'm deploying  already is looking for a connection string called data context. So I'm going to make  that the default connection string. Context. Great. The source I want to, the code I want  to use is already on my GitHub account so I'm going to check that box so that we can  publish from source control. Great. Next. Sorry about the water guys. I'm going to need  to moisten my throat. So for the database, I don't really like this random name it gives  so let's go ahead and just call that DB. It's a little easier to find. We will create it  on a new server. I'll create a login and a password. Great. Okay. Now I get to pick where  I want to pull my code from. Let's say GitHub. Next. You see this pop up window that was  as you're going out to my GitHub account authenticating me. I'm already logged into GitHub so I came  back right away and now I get to pick a repository that I want to use. I'm going to use a repository  that I have called stack, full stack web perf. This is the actual demo code for my talk tomorrow.  It's the second talk of the day where I'm actually going to be taking a look at this  specific website and how to improve its performance on the network, on the server, in JavaScript,  in CSS. Top to bottom we're going to make this website scream. But we'll just use the  demo app for what we're looking at in Azure today. So I go ahead and I press complete  and just like that I'm getting a website created. You can see it here being created.  Azure usually does these kinds of things pretty quickly within the matter of a couple of seconds.  There we go. And so now I can come in and you can see if I go to deployments, a deployment  is happening. And so what is going on in the background, you can see that it's fetching  changes. It's going to GitHub and it's cloning, it's downloading all of the code that I have  on GitHub so that I can get it up and running on the web server.  While that's doing that, I'll go ahead and turn on a couple of configuration changes  that I like to have. I like to have logging enabled. So I'm going to turn on application  logging. This is the logging that comes from my app. This is my trace dot write lines that  I put in my code. Let me go ahead and turn that on to verbose. I like to see all of that  kind of stuff. I'm also going to turn on web server logging. This is the logging that  IIS gives you, the W3C standard log file format. I'll go ahead and hit save. And let's see  if we're done deploying yet. Okay, great. We are. I'll browse to it.  So a database was created, a website was created. The connection string was automatically put  into the config file for me. At this point now, that website is being jitted for the  first time. I'm using entity framework migrations in this website. So all of the data is getting  populated into the database for this first request. And when all is done, we should see  it. Now I'm American, which means a couple of things. I'm fat. A little bit. Self-difficating  humor, a little bit. Okay. I love baseball. I'm in New York, but I'm not a Yankees fan.  I'm a Miami Marlins fan. So what I decided to do was make and demo application all about  baseball. But nobody in Scandinavia cares about baseball. So instead, I've made a website  about clowns, essentially. But they're baseball clowns. These are the mascots of minor league  baseball. There's 160 minor league baseball teams. And this website shows up their mascot.  So if I wanted to, I could go look at the Texas minor league. And I can see all of the mascots  that are available there. I can look at the winners of the mascot mania contest that happens  every year. This is all the mascots compete and do stupid things, like throw pies in each  other's faces. And you can see the winners here. There's some really great ones. Like  this guy here, ballapeno. He mixes together jalapenos and baseball. So how can you go  wrong with ballapeno? And there's other guys. Like Roscoe the P. Ray Rooster. This is not  a guy that I would want to see in a dark alley. I have no clue what wrestling and baseball  have to do with each other. But we're American. Why not some gratuitous violence? So this  is my website. And so just like that, in a span of a couple of minutes, I have this  database of this website up and running. So that's great. If you haven't seen it, that's  Azure websites. So let's go ahead and dig into what Azure websites really is. Now, if you've  been around the block with Azure a little bit or you've sat in a talk show and you may  have heard of something called a web role, websites is not that. Web role, website, two  completely different things, unfortunately, that they're named so similarly. Web roles  are still around. And I've put a comparison of some of the things that you can do in web  roles that you can't do in websites and vice versa. To me, I kind of feel like a web role  is really more appropriate when you have something really custom, really enterprise, maybe a  legacy code base that you're trying to move into the cloud. That's because of you get  elevated startup scripts so you can install things on the machine that is running that  website. You can have dedicated IP, virtual networks, things like this. The biggest flaw  with web roles to me is deployment can take eight to 15 minutes. That's just too long  for me as a developer. And I have to do a little bit more management of the box and  I'm the dev half of DevOps, so I'm kind of uncomfortable with that. Websites, on the other  hand, really suits me well. Everything runs through my source control and that's a dev  friendly thing. And so they're kind of like tacked on ops in the way that a dev wants  to do it. That means we're kind of using continuous deployment, basically. Deployment is very  fast. Like, yes, that probably took about 30 seconds, but from a hold start, that's  not too bad. And the example I just gave, we have some other options that aren't available  with web roles like content backup, rollbacks, web jobs. Some of these things are all interesting.  But if we stop and think about what really is an Azure website, it's not that different  from what the ops guy that I let hang out in the back closet do. It's just like the  hardware that you have had in the past. It's a copy of Windows running somewhere with.NET  and IIS on it. That's kind of good news because the ops guy can still be quite comfortable.  But there's this extra layer on top that is completely open sourced and available on  GitHub called Kudu. And so I have the Scott Gu OctoCat here representing Kudu. Now, just  to prove that Azure website is nothing special, what I'm going to do is I'm going to use the  ops manager's friend here. This is IIS manager. And I'm going to make a change to the website  that we just deployed in the cloud. So if I connect to a site, I'm going to type in NDC  demo and I'm going to go to port 443 and I'll give it a name of NDC demo. That's arbitrary.  My username, my password. Authentication happens. Great. I can name the connection.  Finish. Cool. So now what I'm looking at is the standard  IIS interface that I would use in my enterprise, but connected to the Azure cloud on that website  I just created. So let me prove it to you. There's a whole bunch of things that we can  see. Like I can look at application settings and you can see some of the standard NDC settings  that are added to your web config. So web pages version, unobtrusive JavaScript enabled,  et cetera, et cetera. I'm going to go into this HTTP redirect. I'm going to turn on  redirects to my site and we'll just point to something ubiquitous like Google.com. Let  me apply that change and now when I come back and I refresh, you'll see that my website  redirected me to Google. And let me go ahead and turn that back off because nobody wants  to look at Google the rest of the time. Apply that and now if I go back, I can refresh and  my site will need to rejit and everything because I restarted the web server, but the  site will come back up here in a second. So I show all of that to you just to say what  really is websites. Well, it's standard IIS. It's standard.net. It's standard Windows.  But this Kudu layer, that's the part I haven't touched. Let's really dig into what that is.  You'll notice that I have a diagram here showing Kudu going off to all of these different source  control providers. I have Bitbucket on the top and then GitHub and then Dropbox, which  I don't understand why we use the word Dropbox when we talk about source control providers,  but I've been guilty of using Dropbox as source control, so maybe it makes a little sense.  And then Codeplex because everybody uses Codeplex. So Kudu is named after this animal. It's a  real animal. It kind of looks like a goat that I wouldn't want to mess with, but he's  there. It's interesting. It's a service that is different than most services we interact  with today. Today, typically when I think of service, my connotation is a multi-factor  service. There is one service that I interact with that might manipulate many different  things, but everybody is connecting to the same service. So it's a multi-tenant service.  Kudu is a single-tenant service, which means that for every website you create, an instance  of the Kudu service is also created to go along with it. It's like a buddy site. These  two things go together. And Kudu and that website are linked in a couple of interesting  ways. As of right now, this might not always be true, but as of right now, Kudu runs in  the exact same process as the website. It runs in the same sandbox as the website, and  that means a few different things for you as a user. One, it means that Kudu has access  to do anything that your website has access to do. Two, it means that the only thing that  Kudu can screw up on that box that you're in is your website. So you can do things in  Kudu that break your website. Three, it means that all of your quotas between your website  and Kudu are shared. So CPU usage, memory usage, hard drive usage, all of that stuff  that you're doing with Kudu is also going along with your website. So you kind of pay  for it. So let's take a timeline look at what Kudu does. I basically like to think of Kudu  as a very low-level continuous integration server. And I say that because it reminds  me of seven, eight, nine, ten years ago when I was working on cruisecontrol.net, if you  guys ever played around with that. Basically, cruisecontrol.net would watch some source control  provider when the source code changed because you committed or pushed or whatever it was  called and whatever flavor of source control you did back then. Whenever that happened,  it would pull down those changes and then run some script. So the first thing that we  see that Kudu does is it connects to the source control provider and it acquires your source  when you change it. The next thing it does is it builds the code that it's received.  Now Kudu works with lots of different flavors. I'm a.net guy, so I'll mostly be talking  about.net, but it also works with Node and PHP and Java and Python. So if your environment,  if your programming environment in Dejure doesn't require build like Node or PHP, it  just doesn't build. But for.net, there is a build step, so there is a build. And then  the next thing it does is it copies the assets into the WW root, the place that I serve content  out on the open internet, whether that's the binaries that have been compiled or it's  just the source that run in interpreted languages. And then finally, it does some post-actions.  It says, hey, I'm done doing the main thing that I do and there's two flavors of that.  There's post-actions, which you see first. These are scripts that you can execute. And  the second thing that it does is it uses, I'll use the word technology loosely, it uses  webhooks, which are basically the opposite of web APIs. So let me show you what that  looks like. First, let's talk about these post-actions. Just a general note, everything  that I do today is going to be stuff that you can't do through the portal or mostly  can't do through the tools that Microsoft gives you. That's why these are the secrets.  So the things that I'm telling you today are available and they're supported, but sometimes  they're a little rough around the edges and a lot of it has been me kind of dancing through  trying to figure things out or talking to people that work on the Azure team to get  this kind of information. You may see in the future that some of these secrets will show  up in the portal and it won't be much of a secret anymore because there will be a button  that you click and it does the thing that I'm showing you how to do now. But maybe not.  So this post thing is an example of that. So let's go ahead and just copy this little  thing and cheat a second here. What I'm going to do is I'm going to go back into the portal  and on the dashboard I get a URL to an FTPS, a secure FTP location. And a lot of people  don't realize this, but Windows Explorer is an FTP client. So I just opened up Windows  Explorer. I pasted that FTP address. I hit go. It's going to authenticate me. So once  again I'll type in my password and my username was already there. And we are connecting to  the site. Cool. I am now just FTPed into that box that I earlier connected to with Internet  Information Services Manager, IIS Manager. So I'm connected that same thing via FTP.  If I go into the site, I can see all of my content here in the WW root. I can start deleting  things and changing things and you're going to see that live on the website. There's a  bunch of other files and folders in here though that are not my website like this diagnostics,  repository. This is actually where all my Git code lives and you can see my Git attributes  and whatnot. But what I'm going to do is I'm going to go into deployments. Kudu stores  all of the information about your deployments on disk. So that's kind of cool. But inside  of tools I'm going to create a new directory. So new folder and we're going to call it post  deployment actions. Cool. And inside of there I can add any number of scripts that I want  to. So batch files or cmd files. So let me go ahead and just create a really simple one  so you guys get the point. I'm going to say echo hello from post.bat. Let me save this  as post.bat. Not nat, bat. Okay, great. And then let me grab that file. What did I stick  to? I stuck it on my desktop. Users, Nick desktop. Post.bat. I'm going to copy this  file and just, oh, let me copy it. Sorry guys. Copy the file and I'm going to drag it into  this FTP window here. Cool. So I just uploaded a file through Windows Explorer over FTP  to my website. Now, any time a deployment happens and instead of re-downloading all  the code I'll just redeploy what we already have deployed. That script will execute.  So I'm going to click on this deployment. I'll say redeploy. Yes, this should happen  much faster this time because there's no source code to download. There's been no changes  on the repo. So you can see it's deploying. Cool. We're done. If I come through here and  look at the logs you will see that I have executed that file and it's saying hello from post.bat.  So obviously I just echoed. That's not really anything interesting. But in this scenario  any post steps you would make after deploying something you could do. So priming caches,  building contents, a CDN provider, anything like that you can all do in these scripts.  You can have multiple ones. So you can have one for each different task you're doing.  And Kudu will run them in order, the same order that you see them in Windows Explorer.  And if one of them errors returns an exit code of zero it will just stop there and the rest  of them don't run. But that's kind of cool, nice little hidden  trick that you can do to do things after the build has happened.  So that's this post action, the one on the top. But there's also this web hook option  which is really handy for guys like me who are web developers. I'm not super comfortable  getting down into like scripting batch files or whatnot. But web programming I'm all about.  So let's take a look at how the web hooks work. What I'm going to do is I'm going to  go to this website called Zapier. Zapier is similar to if this then that, if.com if you're  familiar with that website. I like to think of it as programming my mother  could do. It's very simple like draggy, dropy, point and click kind of thing.  So I'm going to make a zap. And the reason why I'm using Zapier is because  the Azure website's team has worked with Zapier to have a nice experience specifically for  websites. So when I create a new zap which is basically an if then block of code, I can  choose what my if is going to be my trigger. And I'll do a search for Azure. And you can  see I have Azure websites. So when this happens, either when a web job  is run or a site is deployed, that's the one I care about. So when a site is deployed,  then what do I want to do? Now I use this all the time for my side project,  which I call Glutly. And what I have Glutly do is send me a text message on my phone every  time a deployment happens. So that looks something like this. This is literally a screenshot  from my phone. You can see there that my last deployment was successful. I have a URL so  I can click and go right to that spot. And you can see I fixed the bug resulting from  multiple restaurants being added to a database. I'm American and I don't have a SIM card that  works here. So we're going to do something a little bit different, but it proves the  point of how easy it is to plug and play with something like Zapier. So instead we're going  to go to Twitter, because I do have an internet connection here. And we're going to send out  a tweet anytime a deployment happens. So that's what I'm going to do. So when there's  a new website deployment, I'm going to create a tweet. Like I said, my mom can do this.  Now we need to tell Zapier about my website. And so if I say connect to an Azure website  account, you'll notice here that it's asking me for a deployment trigger URL. Well, what's  that you ask if you go into the portal and you go over here to configure, there is a  field that has just that URL. So I'm going to copy it. I'm going to come back to Zapier  and I'm going to paste it. And then we'll give a name to this connection. So this is  going to be Azure websites. This is for the NDC demo. Great. Continue. And so you can  see here the account is working. Zapier and my website are now communicating. And that  communication is happening because the Kudu web service is there. I never see it, but  that's what's going on there. I can press continue. I'll make this go to my Twitter  account, NickMD23. Continue. I can add filtering so I don't always do this. We'll just skip  that step because I want to prove the point to you guys. Continue. And so we'll say deployment  happened. And I can put in variables. So if I say insert fields, Zapier now goes out to  that web service that Kudu is hosting and it will show me all of the fields that I have  available in a moment. Hang tight. Can take a minute, apparently. There we go. So you  can see I can use the message, the status, the author, the deployer, all of these different  things. We'll just go ahead and put the message into the tweet. Continue. And click the button  to test. That's fine. And we're good to go. Oh, I need to name this Zap. So we'll also  name this NDC demo. Cool. Turn Zap on. And now, anytime I do a deployment, the website  will tell Zapier. Zapier will see that anytime a deployment happens, I should be doing a  tweet. And you can see that this thing is on Azure websites to Zapier. So what I'll do  here is I'll come back to my website. I'll look at my deployments. We will redeploy,  just like as we did before. And while that happens, we'll go over to my Twitter stream  to see the tweet come through because the tweet will come from me. I'm a big foodie,  as I already mentioned. So you might notice that last night I went out to dinner here  in Oslo and we decided to have whale meat. This is not something I'm accustomed to in  the States. It made me kind of think that I bet Twitter never fails in Oslo because  everybody knows the famous fail whale. You guys would eat it. So Twitter just, it's like  we're not going to fail in Oslo. We'll kill our beloved mascot. So that deployment should  have finished. It has. Let me go ahead and refresh my Twitter stream. All right. We're  still waiting for Zapier to send the tweet through. There we go. Deployment happened  adding, tracing for Azure demo. So just like that, a tweet has happened. Maybe it's told  all of them, everybody who cares about the website that there's a new version. I'm going  to go ahead and delete that tweet so my followers don't get irritated with me. So that is using  the web hooks that Kudu allows you to use. Now, all of these steps in the pipeline are  extremely configurable and this is something I find that nobody really knows about. So  let me show you the configuration points. All of them. So the first thing is you can  change the way that Kudu interacts with your source control provider using app settings.  I've shown you some of the app settings here. There are more available in the documentation  which links are provided for at the end of the talk. So in the app settings, which I  will show you really quickly in the portal. If I go to configure, here are my app settings.  These are just key value pairs. If I use the right named key as shown on this PowerPoint,  these app settings, I can change things like the path in which Kudu will clone all my code  or it will say not to use a repository which is what happens automatically with Dropbox  or the target path. So you can do really interesting things like do in place deployments. So you  can have the code copy right from the repository into the wwroot. So if you just want to deploy  your assets already built, maybe you handle the building, you can just flip a couple of  switches here and it will grab it and just stick it right in wwroot and you're serving  it. The next thing up that we have here is this  Iini file which is a little archaic but I guess I would prefer that over XML. There's  all these other settings that we can use. So one of them is you'll see this SCM post  deployment actions path. So I just had the FTP into the site and go into this tools  and deployment directory to put that post.bat file there. Well that's kind of a pain in the  butt. What if I just wanted that to be in my source control? That's fine. I could have  put that script right in the source control as long as I go and I change the setting and  I tell Kudu when you're done, don't run the things for the scripts from where you normally  get them, run them from this path that I've given you. So you can override basically everything.  And then finally kind of the Mac Daddy, blow everything up and change it, this dot command  file. Essentially everything that Kudu is doing, you can stop and say, hey Kudu, will  you write down your logic for me into a file so I can change it? And so you can do that.  Let me show you what that looks like. I am here at the command line. I've already installed  the X platform Azure CLI tools and I'm looking at full stack web perf. That is my repository,  my directory where I have all of this code for this mascot website. So I'm going to say  Azure site deployment script and that takes in some parameters. This is going to fail.  Basically that's the command that I tell Azure to say, hey, persist all of your logic.  So what I need to do is I need to tell it first of all that it is an ASP web application.  I need to point to my project file so that's in the directory structure. Actually let me  show you the directory structure. So you can see that I have a folder called demo. I have  my PowerPoint slides for that talk. I have a demo script, etc., etc. So I'm going to  say that it's an ASP web application that lives in demo slash minor league baseball  web. Minor league baseball web, that's my CS project file. The other thing that I need  to do is I have to say that there is a solution file at demo slash demo dot solution. If I  run this, it already exists, that's okay, I'm going to overwrite it for this. It is just  gone and written in two files to that directory. So let me go back to DER and you can see that  there is this dot deployment file here and this deploy dot cmd file here. So let me go  ahead and open up in notepad that dot deployment file. This is the INI file I mentioned before  that we were talking about. You can see here that I'm telling Kudu the command that you  run after you've downloaded all of my source code is deploy dot cmd. That's the new file  that just got created. So you can create your own, you can override, you can do whatever  the heck you want to, you're just overwriting what Kudu does right from this spot. If I  open up that deploy cmd file, oh, nope, I have to spell it right. You can see here this  is everything that Kudu does. It looks big, especially when I scroll really fast like  that. It's not too bad, it's very well commented. You can see here that essentially it goes  through and sets up a bunch of environment variables. These are the variables that you  can override from app settings. You can go in and change any one of these. So if you  want to change the deployment target, you can go into the portal, add that as an app  setting and that will override this deployment target because you can see it's checking to  see if it's already defined first. So you can define it there. It comes through and  here's where it does the meter that work. The first thing it does is restore new get  packages, then it builds into the temporary path and then it does the sync. This is where  it takes all the built files and moves it over into your wwroot. So that's cool. If you  want to change anything about how this works, you can go in there and do it. If you don't  want to go hog wild, here's where it's actually calling MSBuild to do the build. You'll notice  at the very end of both of these lines, it's passing in this build args. Once again, this  is another setting that you could put in your inifile or in your app settings to say these  are additional build arguments that I want passed into MSBuild when I build my site.  So you don't even have to go this far. I've gone this far in a couple of my sites, that  one that I showed you where I was texting myself. Let's go ahead and look at that deploy  file. I don't want to run it. I want to edit it. So you can see that in this file, the  standard thing, restoring the new get packages, building, blah, blah, blah, I've gone in and  I've added unit tests. So my unit tests basically, oh, here we go. This is the unit test. Sorry.  Really just change the directories into where my X unit runners are. That's just a package.  So if I look at my packages, you can see all of the different packages and there's the  X unit runner is in there somewhere. I use this little handy trick of using a star here,  which you can use with change directory because I never know what version of the runner is  going because that all gets handled through new get. So I change into whatever the version  I happen to have is and I run it. And if there's an error, then I error out and I continue  and that deployment won't happen. And then I get text and I'm told that there was an  error on the deployment. So that's great. So basically I have a CI server, a continuous  delivery server, all in one with four lines of code that I downloaded from the end unit  website. So that's great. I can create that command file and basically do whatever I want.  Now Kudu does a couple of other things besides just this deployment and building that we've  talked about so far. Oh, don't go. We're going to miss you. Have a good day. It does a bunch  of debugging and diagnostics and makes that information available for you in ways that  would kind of be difficult to do on your own because you're in the cloud. And that's what  the special star.scm website. So what I'm going to do is I'm going to come back over  here to my browser. I'm going to copy the website that we've been using all along. So  this is the NDC demo Azure website. I'm going to paste it and all I'm going to do is I'm  going to add in.scm into the URL. So every Azure website that you have right now already  has this thing enabled. You just don't know about it. And that pulls up this Kudu page  which has all kinds of really useful, interesting things. So the first thing that you'll see  is environment, which shows you a bunch of information about the system that I'm running  on. I am running on a 64-bit system, but I'm not in a 64-bit process. I have one processor,  blah, blah, blah, blah. I can see all of the app settings, the connection strings, the  environment variables, all kinds of good, useful stuff for when you get into a jam sometimes.  There's also this Process Explorer that I can click on. This is actually an HTML version  of Process Explorer. If I hit Control-Shift-Escape, this is my normal task manager that I get  for my local machine. I'm looking at the exact same thing now. I'm looking at the same thing  now for my remote machine, just an HTML version of it. I can dig in. You can see my W3WP,  that's IIS is running. I can dig in and look at the properties there. I can see all of  the threads. I can look at the properties of a thread, et cetera, et cetera. I really  like this handles. So if you ever get a locked file, you can see which process is holding  on to that file. You can go in and you can actually kill the process from this UI. So  that's kind of cool. There's some other tools too, like you can download a diagnostics dump.  If I click on that, it's going to give me a zip file that I can run through with some  debugging tools. There is this Log Stream. Now, this is streaming logging. This is showing  me all the logging information that's happening on my website. So if I come back to my website,  let's go to a split screen here. As I click around, I go into the Appalachian League and  you can see that that log happened. I go back to the home page and you'll see there's the  home page. I can go see all the winners. I'll see the winners. So I could be watching this  log as hundreds and thousands of people hit this website if it was well known and I could  see what's happening live on the website. So that's kind of a cool tool. There's a few  other things that are interesting. Oh, web hooks. This is funny. So if you didn't want  to use Zapier, this is where you could come and configure your own web hook. You'll see  that Zapier has already reached back into Kudu and set itself up as a web hook. But I can  type in any URL that I want to right here and any time a deployment happens, Kudu will  post deployment information to that URL so that could be a local service that you're  running in your enterprise to update some dashboard that sits in front of your manager  to let him know that a deployment happened. So that's all good stuff. The last thing that  I'll show you, I'll show you two more things in this Kudu. All of Kudu exposes a RESTful  JSON-based API so that you can get at this information programmatically. So if I wanted  to see the app settings for this website, here they all are and, Jason, you can see  that I'm just going to API slash settings. If I wanted to see all the deployments that  have happened in this website, I can open that up and here's the deployment. I like  this files one. This basically gives me the file system that I was looking at at FTP in  a JavaScript way and I can just drill through and say, okay, I want to dig into site and  I can follow this link that gives me for site. I want to dig into WW root. I can follow this  link to get into WW root and boom, there's my packages config, my scripts, my snippets,  my views, all that kind of stuff and I can build a whole file browser just using these  APIs. And then lastly, Kudu has this debug console. It has a PowerShell version and a  command EXE. I told you guys I'm not much of an ops guy so I shy away from PowerShell.  I'm trying to tell me this for developers. I'm not buying it. So I'll just use the good  old command.exe. If I come into that, I am actually now looking at a terminal on the  machine that my website is running on. And so if I go CD into site, not only did I change  directories but you'll notice that the top part, this HTML table has changed and it follows  along with what I'm doing in the command line or similarly if I click on WW root, you'll  notice that the command down here changes WW root. So I can go in there, I can check  things out, I can look at the file system, I can do whatever I want to without having  to go into FTP. So this is all quite handy and something that Kudu gives us which is  nice. Now, everything that I just showed you there might be a little bit scary because  I'm giving you a lot of access just by knowing the SCM part of the URL. That's where I want  to stop and take a step back. Kudu is interesting. It runs on the same process and the same  sandbox and all that stuff but unlike your actual website which is not authenticated  by default, everything inside of Kudu is. I was just already authenticated so you guys  didn't see the challenge. Now, there's multiple types of credentials that you use in Azure  and this is kind of confusing but as far as Kudu is concerned there's two and they're  called deployment credentials. So typically when you log into the portal or something  you'll use your Microsoft account, right? Kudu doesn't care about your Microsoft account,  it doesn't know what that does or follow it. Instead, it uses either user credentials which  you know user credentials from the portal because on the dashboard you'll see this thing  that says reset your deployment credentials. That is a user credential. You have one. You  have one of those for every single one of your Microsoft accounts which means if I change  the password there, it's not just changing it for my minor league baseball website, it's  also changing it for GitGlimpse website and it's also changing it for that signatory website  because that set of credentials is stuck to me. Never give out that set of credentials.  They're yours. If you lose control, you go in there and you reset it and it'll reset everywhere.  The next one is site credentials. These are ones that are made for you to give out. They're  generated for you but they're specific to a website. So I have four sets of site credentials,  one for the minor league baseball website, one for signatory, one for GitGlimpse, etc.  They're auto generated so you can tell a site credential because it begins with a dollar  sign and the username is always dollar sign and then the name of the site that you're  using and then the password is some long messed up GUID. You can actually see this because  if I went back, you guys remember earlier we had a copy and paste something into Zapier  which is that trigger URL. Look at this. You can see the name of my site is NDC demo and  you can see dollar sign NDC demo here. That's that automated username and you can see here's  my password and Kudu is just using HTTP basic auth when the client makes a request to that.  It rips those things out of the URL, sticks it into an auth header and that gets sent  off that standard HTTP authentication stuff. But there you can see that. If you download  your published profile which is available from the dashboard, reset your published profile  credentials, I could download it as well right here, download your published profile. That's  just an XML file and if you dug into that XML file you'll find that exact same username  and password. And most of the tooling that you'll use that wants to connect to Azure  for you will say give me your published profile. So you're giving it a set of site specific  credentials and if you lose control you can reset those as well but those are site by  site. So everything in Kudu, you're good, it's authenticated using one of those ways.  Great. So we've looked at a whole bunch of different things that we can do with Kudu  and the process but I want to stop and also think about what are the ways that we can  kind of configure Kudu to do additional things. And it's not even just Kudu but IIS and.NET  and what is afforded to us. So this diagram I made, parts of it should be pretty recognizable  to you. So everything in all the blue circles, that is the standard.NET configuration scheme  that we've known since day one, right? There's a machine.config, there's a root web config,  those things get merged in and then you can have web configs and directories going down  farther and farther, deeper and deeper and they all get merged together into your application.  And that makes web config and if you're running an IIS 6 or before, that is the whole story,  just the blue, the dark blue, those three. And IIS 7, they added a new configuration  file called application host.config. These are IIS specific settings and that file gets  merged in along with the web root. So now you have IIS and.NET code intermingling. In  Azure there's yet one more layer which is this Azure overrides and these are all of the configuration  settings that you've put into the portal. So all of these things come together to give  you final configuration, stuff that you've typed into the portal into your web config  from the app host. Microsoft gives you an app host. Now you'll notice that these two  of these have a little bubble that says xdt. That's the web config transform schema that's  available. You probably recognize this from Visual Studio when you create a new project  underneath web config, you have web.debug.config and web.release.config and you know you can  make changes there so the release mode and the debug mode look different. That's called  xdt. That exact same file format schema is available in Kudu to run on your app host  so you can change IIS settings. So let me show you what that looks like. I'm going to  go into Kudu again. I'm going to go to this, oh I'm already in the debug console. Great.  I'm going to upload a file. So I have this outer curve SVG. This is an image, a scalable  vector graphic image so I can zoom in forever and it will always look good. Outer curve  is the foundation, the open source foundation that Kudu is a part of. I'm going to upload  that to the site. I can do that very simply because I'm looking at my ww root right now.  If I drag this up to the web browser, like I said it's kind of an FTP client, I can just  drop it and that's going to get uploaded and now I have outer curve SVG. So if I go back  to my site, now I can say slash outer curve SVG. But I get an error. Well, that's because  by default IIS doesn't know what to do with SVG files. It's easy enough to change. You  just go in and you add the file extension and the mime type and you're good to go. But  we want to do this in a Kudu way, a way that's reusable. So Kudu allows us to, I'm going  to go up one directory so I'm looking at site. It allows us to put one of these transform  files in. So I have this application host transform file right here. I'm going to upload  that to the site. And now that that's there, I need to restart the site. So let me go to  the portal. I'm going to stop the site. I'm going to start the site. Okay, great. The  site is starting up now. So because Kudu solved that file with that name and that location,  when the site restarted, it said, hey, this user wants to change application host.config.  I'm going to apply that transformation. And I'm going to show you that transformation  in a second. But now if I go back to this page and I refresh, you can see I'm getting  my outer curve SVG file served to me because I added that other file in that one spot.  So what does that file look like? It's quite simple. This is the entirety of the file.  So I'm using the XDT transform. So I'm inserting an element. I'm adding any file that ends  in.svg to serve it as a mime type of image SVG plus XML. I'm also going a step further  because I care about performance, which you'll hear more about tomorrow. I'm saying that  image SVG is I want to do HTTP compression. So that's that whole file and boom, now my  whole website can serve SVG files. This is a pretty simple example. And actually, this  example I could have just baked right into my web config and checked it in. No big deal.  But Kudu goes a step farther. So here's another example that you might want to use. This is  increasing the length of the queue that IIS holds. IIS has a queue. It's a number of  requests that it will hold on to. And once you go past that queue, it will start issuing  503 responses. It will say service unavailable. I think that that number by default is a thousand.  In this example, we are once again doing a change. We're changing an attribute. That's  what the set attribute does. I'm changing it to 5,000. So more people will wait longer  before they get service unavailable on my site. But notice there's this XDT site name that's  surrounded in parentheses. There's a token there. What's cool about these apphost.xdt  files that I can upload to Kudu is it will scan them for certain tokens and replace them  with runtime variables, which means that this file I can now upload to any website that  I want to because the name of the site, which normally would have been hard coded, is now  variable. And you can see there's a couple of different things. There's a site name,  there's the app pool name, there's an extension path, etc., etc. That one difference, that  one thing that Kudu does opens up a really interesting universe to us. So let me show  you another file. This file is going to add something that Kudu calls a site extension.  What a site extension is is really just us leveraging the power of virtual directories,  which I've never really used before. But now I can take this file. You guys can literally  copy and paste this from my slides, change these two variables where it says extension  name, and we can start to put things into Kudu ourselves that are authenticated. So  we can give our administrators a place to add them in the website completely. Stuff  that is is specific that I've already showed you in the Kudu website, and stuff that is  important for our app. So let me show you some examples of this. Actually, you know  what, no, let me make sure that this is really hitting home. So this is Azure website in a  architecture diagram. There's the user site that sits on top. There's a buddy site right  next to it, right? That's kind of what our site extensions. The site I've already been  showing you is actually a Kudu site extension. It's just this virtual directory kind of thing.  And Microsoft installs some of them for you by default. So Kudu, we've already looked  at. Visual Studio Online, you might have seen. Web Deployer, Web Jobs, you might have seen.  Microsoft puts those there. And if you want to partner with Microsoft and call them and  have one built in, they allow for that. But we're not going to do that. We're just regular  users and we're not trying to change the way Azure works in general. Instead, we can either  install an existing one or we can upload our own. So let me go back to Kudu. And I'm going  to come over here to site extensions. And you can see that from my site, I'm on the  installed tab and I don't have any extensions available. So I can go to the gallery. Now,  this morning when I did my run through, there was an additional option here that put in  an IIS log analyzer that would tell me where my traffic comes from and how many hits I  have and all these kinds of things. It's gone. Which stinks for you guys because it's kind  of cool looking. But it's actually a teachable moment because you can kind of see already  where Microsoft is going with this. The reason why it's gone and I had to dig through the  Kudu source code to figure this out is because all of these things are just Nuget packages.  And it's fed by some private Nuget feed somewhere that Microsoft controls. And that was the one  I want to show you was a package on there. And they've removed that package from the  feed. That's fine. I'll install another one. It's less impressive, but it'll still give  you the point. I'm going to install this file counter. The source for this one is available  on the Internet. It's the only one that I know that source is available for. I'm going  to press install. And you see I get this little thing that says restart the site. There's  actually a bug with restarting the site. Both in the portal and on the site extensions.  So I'm just going to stop and start. That's kind of the way to make sure that it really  restarts. And so now that I've done that, I have this little play button available on  file counter. And file counter is amazing. You ready? I press play. Oh, hold on. It's  still starting up. Told you it's amazing. Okay. There we go. The world's most amazing  file counter. Your site has 539 files. All this is is a tiny little website that knows  where it's sitting and it counts all the files that sit inside of my www route. Spits that  back. Not very useful, but you can make it do anything that you want to. Let me show  you one that's a little bit more useful for our application. And obviously I can come  in here and I can uninstall this thing. And you can imagine a world where there's all  these admin tools. I'm not a PHP guy, but PHP MyAdmin is very full featured. And if this  is a PHP website, that would be kind of cool to show you. So what I've done is on our minor  league baseball website here, every year the winner of mascot mania changes. So this year  it's this guy here, Lucille from the Columbus Clippers. And you can see that he's kind of  the hero of the website. He's the big picture that you see. And the administrators of this  website are constantly saying, hey, there was a new mascot. Can we change it? And I have  to go in there and I have to change the code. So what I want to do is I want to give them  an administrative tool. But there's no authentication on this website. I don't want to build out  authentication. I just want them to be able to use the credentials they already have with  Azure to log in. So what I've done is I've created this simple little file, default ASPX.  And this is like, I've made it really simple and ugly on purpose because I don't want you  guys to focus on the code. But essentially what it does is there's an if statement. If  it's a get request, I build up an HTML form that has a select or I'm looping through and  writing a bunch of options. And if it's a post, I do some updates to the database. What's  important to note is because I'm running in context of the website, I can still get the  configuration manager to give me the data context. I have access to all the variables that the  website is already using, so I don't have to ask for any input. So to install this, I have  created this application host XDT. This is the exact same thing that I'm showing you  here, except for the word extension name has been replaced by hero. And so I'm going to  take these two files, and I'm going to upload them. So I'm going to come back to the Azure  portal. I'm going to go to the debug console because that's the easiest way to upload things.  And you'll notice that there's a new directory now that I installed the site extension right  next to site called site extensions. So that's fine. Once again, this just follows the convention.  I'm going to add a new folder called hero. I'm going to go inside of hero. I'm going  to upload these two files, drop them. Boom, they're there. Once again, I made a change  here. I need to restart the web app. So let me stop it and start it. Okay. So if I go  back and look at my mascots, I'm refreshing. It's going to take a little bit because of  the jit, but we'll still see Lucille as the main winner of the mascot. Contest. Wow. Come  on. Come back up, Azure. They promised me that this restart thing has been fixed in  the new portal, but we'll see. Yes, because deployments, the question is could you use  deployment stops? And the answer is yes, because the deployment slots are still spinning up  and the process is new, and so kudu when it spins up, we'll do all the configuration  stuff. Yeah. So since I named this hero, I should be able to go to hero. Okay. Now my  website is really dead. Let's see what's going on together. Wow. Really dead. I'm not even  getting console. Well, this is fun. I am stopping and starting to write website. Okay. Well,  let's do this. I could check the logs, but I'm not going to go splunking through all  that stuff with you guys here. So let me try one thing. Let me. Okay. This is good. The  fact that I got this far is great. This is a good sign that this is working now. That's  not a good sign. I'm wondering if I screwed up something in my file. Come on, guys. This  is the big demo. This is the one you're on. You're like the edge of your seat, right?  I've never screwed this up before. Oh, man, Azure is really killing me here. Okay. You  know what? I have another option. We're going to use all the tools that we've learned about  in this talk right here right now. Just pretend that I meant for this to happen and it would  be awesome. I'm going to use FTP and see if I can even FTP in. So like I told you earlier,  this stuff is rough around the edges right now. I can go into the site. Nope. Oh, interesting.  The site is back. Hey, thank you. You can hit it, but I can't. You might be coming up  here to finish this demo, buddy. Well, okay. So the point here is what's supposed to happen  is can you, oh, you can't hit this URL because you can't authenticate this. Let me try another  browser. Good call, Anthony Van Der. Hey, hey, hey, hey. That's what you wanted. Okay.  Is this one? Everybody hold your breath. So what we have here now is in Hero. This is  the admin thing. This is that super simple page I showed you. I have a drop down of  all of the different mascots and I can pick who was the winner. So who am I going to pick,  guys? Come on, Bala Pino, of course. So Bala Pino, I hit submit. That's now updated. If  I could get the website to run, which it is, if I hit refresh now, Bala Pino. Stuck the  landing, so, so. You guys are cruel. You only laugh when I call myself fat and when I failed.  I understand Norway. So that is the bunch of the stuff that I wanted to show you guys  about Azure and the different things that you can do. Now here's the big secret that  I've learned screwing around with all this. Even in that moment of panic, I did not plan  that, I swear. Even in that moment of panic, I felt safe. And the big secret to me to Azure  websites and why you can feel safe goes like this. I'm a chef. I like to cook a lot at  home and whenever I talk to people who are my friends who want to cook, they say, oh,  I don't know how to cook and what if I ruin the meal or whatever. Here's the deal. If  you ruin a meal, it's 20 bucks and you can get pizza and you save the meal. When I was  working on hardware in that back closet, I was always afraid because what if I screwed  up the hardware? It's thousands and thousands of dollars. Let me show you what happens if  you screw up the website and Azure websites. One button, done. I've just deleted the website,  the SQL server, everything gone and I can recreate it in 30 minutes. That's the big  secret. You don't have to be afraid because it's that fast to reset. It's a couple of  bucks, it's a couple of minutes and you can reset yourself. So that is what I wanted to  share with you guys today. I have two minutes for questions if there are any. Awesome. Guys,  thank you very much. I hope to see you tomorrow. Tweet me if you have any more questions.  Thank you.  Thank you.
Nik_Molnar_-_Azure_Web_Sites_Secrets_Exposed_0_7619.png Nik_Molnar_-_Azure_Web_Sites_Secrets_Exposed_7620_10943.png Nik_Molnar_-_Azure_Web_Sites_Secrets_Exposed_10944_12287.png Nik_Molnar_-_Azure_Web_Sites_Secrets_Exposed_12288_12647.png Nik_Molnar_-_Azure_Web_Sites_Secrets_Exposed_12648_13355.png Nik_Molnar_-_Azure_Web_Sites_Secrets_Exposed_13356_14087.png Nik_Molnar_-_Azure_Web_Sites_Secrets_Exposed_14088_20003.png Nik_Molnar_-_Azure_Web_Sites_Secrets_Exposed_20004_20507.png Nik_Molnar_-_Azure_Web_Sites_Secrets_Exposed_20508_27431.png Nik_Molnar_-_Azure_Web_Sites_Secrets_Exposed_27432_27695.png Nik_Molnar_-_Azure_Web_Sites_Secrets_Exposed_27696_33071.png Nik_Molnar_-_Azure_Web_Sites_Secrets_Exposed_33072_37739.png Nik_Molnar_-_Azure_Web_Sites_Secrets_Exposed_37740_38771.png Nik_Molnar_-_Azure_Web_Sites_Secrets_Exposed_38772_39059.png Nik_Molnar_-_Azure_Web_Sites_Secrets_Exposed_39060_39383.png Nik_Molnar_-_Azure_Web_Sites_Secrets_Exposed_39384_40403.png Nik_Molnar_-_Azure_Web_Sites_Secrets_Exposed_40404_41183.png Nik_Molnar_-_Azure_Web_Sites_Secrets_Exposed_41184_41267.png Nik_Molnar_-_Azure_Web_Sites_Secrets_Exposed_41268_43847.png Nik_Molnar_-_Azure_Web_Sites_Secrets_Exposed_43848_46547.png Nik_Molnar_-_Azure_Web_Sites_Secrets_Exposed_46548_46955.png Nik_Molnar_-_Azure_Web_Sites_Secrets_Exposed_46956_47291.png Nik_Molnar_-_Azure_Web_Sites_Secrets_Exposed_47292_47903.png Nik_Molnar_-_Azure_Web_Sites_Secrets_Exposed_47904_48431.png Nik_Molnar_-_Azure_Web_Sites_Secrets_Exposed_48432_48479.png Nik_Molnar_-_Azure_Web_Sites_Secrets_Exposed_48480_48575.png Nik_Molnar_-_Azure_Web_Sites_Secrets_Exposed_48576_51575.png Nik_Molnar_-_Azure_Web_Sites_Secrets_Exposed_51576_51863.png Nik_Molnar_-_Azure_Web_Sites_Secrets_Exposed_51864_51971.png Nik_Molnar_-_Azure_Web_Sites_Secrets_Exposed_51972_52187.png Nik_Molnar_-_Azure_Web_Sites_Secrets_Exposed_52188_52547.png Nik_Molnar_-_Azure_Web_Sites_Secrets_Exposed_52548_52703.png Nik_Molnar_-_Azure_Web_Sites_Secrets_Exposed_52704_52835.png Nik_Molnar_-_Azure_Web_Sites_Secrets_Exposed_52836_53027.png Nik_Molnar_-_Azure_Web_Sites_Secrets_Exposed_53028_53207.png Nik_Molnar_-_Azure_Web_Sites_Secrets_Exposed_53208_53927.png Nik_Molnar_-_Azure_Web_Sites_Secrets_Exposed_53928_54215.png Nik_Molnar_-_Azure_Web_Sites_Secrets_Exposed_54216_55739.png Nik_Molnar_-_Azure_Web_Sites_Secrets_Exposed_55740_56303.png Nik_Molnar_-_Azure_Web_Sites_Secrets_Exposed_56304_56375.png Nik_Molnar_-_Azure_Web_Sites_Secrets_Exposed_56376_59087.png Nik_Molnar_-_Azure_Web_Sites_Secrets_Exposed_59088_59147.png Nik_Molnar_-_Azure_Web_Sites_Secrets_Exposed_59148_60779.png Nik_Molnar_-_Azure_Web_Sites_Secrets_Exposed_60780_62327.png Nik_Molnar_-_Azure_Web_Sites_Secrets_Exposed_62328_65795.png Nik_Molnar_-_Azure_Web_Sites_Secrets_Exposed_65796_65903.png Nik_Molnar_-_Azure_Web_Sites_Secrets_Exposed_65904_67283.png Nik_Molnar_-_Azure_Web_Sites_Secrets_Exposed_67284_67967.png Nik_Molnar_-_Azure_Web_Sites_Secrets_Exposed_67968_71615.png Nik_Molnar_-_Azure_Web_Sites_Secrets_Exposed_71616_71675.png Nik_Molnar_-_Azure_Web_Sites_Secrets_Exposed_71676_72767.png Nik_Molnar_-_Azure_Web_Sites_Secrets_Exposed_72768_72911.png Nik_Molnar_-_Azure_Web_Sites_Secrets_Exposed_72912_75395.png Nik_Molnar_-_Azure_Web_Sites_Secrets_Exposed_75396_76895.png Nik_Molnar_-_Azure_Web_Sites_Secrets_Exposed_76896_77063.png Nik_Molnar_-_Azure_Web_Sites_Secrets_Exposed_77064_80003.png Nik_Molnar_-_Azure_Web_Sites_Secrets_Exposed_80004_80243.png Nik_Molnar_-_Azure_Web_Sites_Secrets_Exposed_80244_80639.png Nik_Molnar_-_Azure_Web_Sites_Secrets_Exposed_80640_81419.png Nik_Molnar_-_Azure_Web_Sites_Secrets_Exposed_81420_82091.png Nik_Molnar_-_Azure_Web_Sites_Secrets_Exposed_82092_82367.png Nik_Molnar_-_Azure_Web_Sites_Secrets_Exposed_82368_84419.png Nik_Molnar_-_Azure_Web_Sites_Secrets_Exposed_84420_84827.png Nik_Molnar_-_Azure_Web_Sites_Secrets_Exposed_84828_84899.png Nik_Molnar_-_Azure_Web_Sites_Secrets_Exposed_84900_85031.png Nik_Molnar_-_Azure_Web_Sites_Secrets_Exposed_85032_85175.png Nik_Molnar_-_Azure_Web_Sites_Secrets_Exposed_85176_85271.png Nik_Molnar_-_Azure_Web_Sites_Secrets_Exposed_85272_85739.png Nik_Molnar_-_Azure_Web_Sites_Secrets_Exposed_85740_85811.png Nik_Molnar_-_Azure_Web_Sites_Secrets_Exposed_85812_89189.png
Alright. Good afternoon everybody. Welcome to room number one. Azure website secrets exposed. My name is Nick Molnar. I'm from New York City. I decided to do something really smart yesterday. I got a horrible cold, so I'm not usually as sultry as this and I've been relying on cough drops to get through the day. It's okay though because I met some people on the internet here in Oslo and they gave me pills that I have labeling that I don't understand because it's not in my language, but they tell me that it should make me feel better and so far so good. But if I kind of like float away, you'll know why. I've been a web developer for a little over 15 years now. I created an open source project with my buddy Anthony called Glimpse that you may or may not have heard of. How many people have heard of or seen Glimpse? Okay, cool. Good number of you. That's great. We won't be talking about that at all today. And then the Glimpse project was sponsored by a company named Redgate that's based in England. So due to their sponsorship, I get to work on open source my baby full time in addition to go and get to speak to great developers like you at conferences around the world. I have become, I've been honored to become an MVP for ASP.net and I'm also an Azure insider. And Azure has become something that's a little bit more part of my world as my day-to-day progresses because even though I see myself as a web developer, I was always kind of the software guy. I would let somebody else go into the closet in the back of the office and they were the ones, they were the server guy. They set up IIS for me, they set up SQL server for me. I never really dealt with that. And then the whole DevOps movement started and I sometimes I'll dabble into DevOps but I feel myself firmly being the dev part of DevOps. And Azure, particularly Azure websites has begun to change the way that I think about myself as being just a developer and becoming a little bit more of a dev op. So if you have any questions after the conference or just want to chat and be online with me, I tweet at nickmd23. So Azure, Azure is huge. It's this monolithic universal thing that we have applied one word which until a few years ago was just a color to me. Azure, as my coworkers like to pronounce it. I know lots of people who are MVPs in Azure and they know lots about different subsections of Azure but I've not met anybody who knows everything about everything. It's just too large now. You can't kind of get a grasp on the whole thing. So what I've decided to do is focus particularly on Azure websites and with that in this talk, I want to really dig into some of the nooks and crannies. Some of the things that maybe aren't as visible to you if you've watched other talks or you play around on the portal. So just a quick show of hands. How many people here have actually deployed an Azure website before? Okay, great. And I'm assuming the rest of you are interested in this technology and that's great. So Azure websites actually aren't that special. At the end of the day, it's infrastructure that you may know. I never knew because I let the guy deal with it in the closet at the end of the hall. I let the ops guy deal with it. But I've been forced to kind of think about it a little bit more. So for those of you who haven't seen it, let me jump in really quick and show you what I'm talking about with Azure websites. So Microsoft Azure, basically everything you do starts in the portal. The portal is this place where you can make new websites, make new databases, make new whatever the thing is that you're trying to create and monitor them and configure them, etc. So this is the new, brand new Microsoft portal. It's in preview. It's at a different URL than maybe you're used to going to. It's at portal.azure.com. And it's pretty fancy. You can click in here and it has nice little alien graphics. It has this concept of things called blades. I can click on this tour and you'll see this new blade pop up and as I work it kind of continues to work horizontally. But here's the problem with preview. It's beta software and it's really slow right now. That's my opinion. And so to save a bunch of time for everybody because it takes much longer to do this talk in the preview portal, I'm going to switch over to the old portal which you may have seen before and that looks like this. So I'm going to really quickly create a website for those of you who haven't seen it and then we're going to dig into some new stuff. So this is actually my personal account or I'm running a couple of different websites that I work on on the side. The Glimpse website is an Azure website as well but it's on a different subscription so you're not seeing it here. But I have a site that I call signatory.io which is for managing contributor license agreements against GitHub and something else called signatory which is a pet project of mine. So I'm going to go ahead and I'm going to say I want to create a new compute website. I'll custom create and we'll just go through the wizard. Let's go ahead and call this NDC demo. I want to create a new SQL database and the code that I'm deploying already is looking for a connection string called data context. So I'm going to make that the default connection string. Context. Great. The source I want to, the code I want to use is already on my GitHub account so I'm going to check that box so that we can publish from source control. Great. Next. Sorry about the water guys. I'm going to need to moisten my throat. So for the database, I don't really like this random name it gives so let's go ahead and just call that DB. It's a little easier to find. We will create it on a new server. I'll create a login and a password. Great. Okay. Now I get to pick where I want to pull my code from. Let's say GitHub. Next. You see this pop up window that was as you're going out to my GitHub account authenticating me. I'm already logged into GitHub so I came back right away and now I get to pick a repository that I want to use. I'm going to use a repository that I have called stack, full stack web perf. This is the actual demo code for my talk tomorrow. It's the second talk of the day where I'm actually going to be taking a look at this specific website and how to improve its performance on the network, on the server, in JavaScript, in CSS. Top to bottom we're going to make this website scream. But we'll just use the demo app for what we're looking at in Azure today. So I go ahead and I press complete and just like that I'm getting a website created. You can see it here being created. Azure usually does these kinds of things pretty quickly within the matter of a couple of seconds. There we go. And so now I can come in and you can see if I go to deployments, a deployment is happening. And so what is going on in the background, you can see that it's fetching changes. It's going to GitHub and it's cloning, it's downloading all of the code that I have on GitHub so that I can get it up and running on the web server. While that's doing that, I'll go ahead and turn on a couple of configuration changes that I like to have. I like to have logging enabled. So I'm going to turn on application logging. This is the logging that comes from my app. This is my trace dot write lines that I put in my code. Let me go ahead and turn that on to verbose. I like to see all of that kind of stuff. I'm also going to turn on web server logging. This is the logging that IIS gives you, the W3C standard log file format. I'll go ahead and hit save. And let's see if we're done deploying yet. Okay, great. We are. I'll browse to it. So a database was created, a website was created. The connection string was automatically put into the config file for me. At this point now, that website is being jitted for the first time. I'm using entity framework migrations in this website. So all of the data is getting populated into the database for this first request. And when all is done, we should see it. Now I'm American, which means a couple of things. I'm fat. A little bit. Self-difficating humor, a little bit. Okay. I love baseball. I'm in New York, but I'm not a Yankees fan. I'm a Miami Marlins fan. So what I decided to do was make and demo application all about baseball. But nobody in Scandinavia cares about baseball. So instead, I've made a website about clowns, essentially. But they're baseball clowns. These are the mascots of minor league baseball. There's 160 minor league baseball teams. And this website shows up their mascot. So if I wanted to, I could go look at the Texas minor league. And I can see all of the mascots that are available there. I can look at the winners of the mascot mania contest that happens every year. This is all the mascots compete and do stupid things, like throw pies in each other's faces. And you can see the winners here. There's some really great ones. Like this guy here, ballapeno. He mixes together jalapenos and baseball. So how can you go wrong with ballapeno? And there's other guys. Like Roscoe the P. Ray Rooster. This is not a guy that I would want to see in a dark alley. I have no clue what wrestling and baseball have to do with each other. But we're American. Why not some gratuitous violence? So this is my website. And so just like that, in a span of a couple of minutes, I have this database of this website up and running. So that's great. If you haven't seen it, that's Azure websites. So let's go ahead and dig into what Azure websites really is. Now, if you've been around the block with Azure a little bit or you've sat in a talk show and you may have heard of something called a web role, websites is not that. Web role, website, two completely different things, unfortunately, that they're named so similarly. Web roles are still around. And I've put a comparison of some of the things that you can do in web roles that you can't do in websites and vice versa. To me, I kind of feel like a web role is really more appropriate when you have something really custom, really enterprise, maybe a legacy code base that you're trying to move into the cloud. That's because of you get elevated startup scripts so you can install things on the machine that is running that website. You can have dedicated IP, virtual networks, things like this. The biggest flaw with web roles to me is deployment can take eight to 15 minutes. That's just too long for me as a developer. And I have to do a little bit more management of the box and I'm the dev half of DevOps, so I'm kind of uncomfortable with that. Websites, on the other hand, really suits me well. Everything runs through my source control and that's a dev friendly thing. And so they're kind of like tacked on ops in the way that a dev wants to do it. That means we're kind of using continuous deployment, basically. Deployment is very fast. Like, yes, that probably took about 30 seconds, but from a hold start, that's not too bad. And the example I just gave, we have some other options that aren't available with web roles like content backup, rollbacks, web jobs. Some of these things are all interesting. But if we stop and think about what really is an Azure website, it's not that different from what the ops guy that I let hang out in the back closet do. It's just like the hardware that you have had in the past. It's a copy of Windows running somewhere with.NET and IIS on it. That's kind of good news because the ops guy can still be quite comfortable. But there's this extra layer on top that is completely open sourced and available on GitHub called Kudu. And so I have the Scott Gu OctoCat here representing Kudu. Now, just to prove that Azure website is nothing special, what I'm going to do is I'm going to use the ops manager's friend here. This is IIS manager. And I'm going to make a change to the website that we just deployed in the cloud. So if I connect to a site, I'm going to type in NDC demo and I'm going to go to port 443 and I'll give it a name of NDC demo. That's arbitrary. My username, my password. Authentication happens. Great. I can name the connection. Finish. Cool. So now what I'm looking at is the standard IIS interface that I would use in my enterprise, but connected to the Azure cloud on that website I just created. So let me prove it to you. There's a whole bunch of things that we can see. Like I can look at application settings and you can see some of the standard NDC settings that are added to your web config. So web pages version, unobtrusive JavaScript enabled, et cetera, et cetera. I'm going to go into this HTTP redirect. I'm going to turn on redirects to my site and we'll just point to something ubiquitous like Google.com. Let me apply that change and now when I come back and I refresh, you'll see that my website redirected me to Google. And let me go ahead and turn that back off because nobody wants to look at Google the rest of the time. Apply that and now if I go back, I can refresh and my site will need to rejit and everything because I restarted the web server, but the site will come back up here in a second. So I show all of that to you just to say what really is websites. Well, it's standard IIS. It's standard.net. It's standard Windows. But this Kudu layer, that's the part I haven't touched. Let's really dig into what that is. You'll notice that I have a diagram here showing Kudu going off to all of these different source control providers. I have Bitbucket on the top and then GitHub and then Dropbox, which I don't understand why we use the word Dropbox when we talk about source control providers, but I've been guilty of using Dropbox as source control, so maybe it makes a little sense. And then Codeplex because everybody uses Codeplex. So Kudu is named after this animal. It's a real animal. It kind of looks like a goat that I wouldn't want to mess with, but he's there. It's interesting. It's a service that is different than most services we interact with today. Today, typically when I think of service, my connotation is a multi-factor service. There is one service that I interact with that might manipulate many different things, but everybody is connecting to the same service. So it's a multi-tenant service. Kudu is a single-tenant service, which means that for every website you create, an instance of the Kudu service is also created to go along with it. It's like a buddy site. These two things go together. And Kudu and that website are linked in a couple of interesting ways. As of right now, this might not always be true, but as of right now, Kudu runs in the exact same process as the website. It runs in the same sandbox as the website, and that means a few different things for you as a user. One, it means that Kudu has access to do anything that your website has access to do. Two, it means that the only thing that Kudu can screw up on that box that you're in is your website. So you can do things in Kudu that break your website. Three, it means that all of your quotas between your website and Kudu are shared. So CPU usage, memory usage, hard drive usage, all of that stuff that you're doing with Kudu is also going along with your website. So you kind of pay for it. So let's take a timeline look at what Kudu does. I basically like to think of Kudu as a very low-level continuous integration server. And I say that because it reminds me of seven, eight, nine, ten years ago when I was working on cruisecontrol.net, if you guys ever played around with that. Basically, cruisecontrol.net would watch some source control provider when the source code changed because you committed or pushed or whatever it was called and whatever flavor of source control you did back then. Whenever that happened, it would pull down those changes and then run some script. So the first thing that we see that Kudu does is it connects to the source control provider and it acquires your source when you change it. The next thing it does is it builds the code that it's received. Now Kudu works with lots of different flavors. I'm a.net guy, so I'll mostly be talking about.net, but it also works with Node and PHP and Java and Python. So if your environment, if your programming environment in Dejure doesn't require build like Node or PHP, it just doesn't build. But for.net, there is a build step, so there is a build. And then the next thing it does is it copies the assets into the WW root, the place that I serve content out on the open internet, whether that's the binaries that have been compiled or it's just the source that run in interpreted languages. And then finally, it does some post-actions. It says, hey, I'm done doing the main thing that I do and there's two flavors of that. There's post-actions, which you see first. These are scripts that you can execute. And the second thing that it does is it uses, I'll use the word technology loosely, it uses webhooks, which are basically the opposite of web APIs. So let me show you what that looks like. First, let's talk about these post-actions. Just a general note, everything that I do today is going to be stuff that you can't do through the portal or mostly can't do through the tools that Microsoft gives you. That's why these are the secrets. So the things that I'm telling you today are available and they're supported, but sometimes they're a little rough around the edges and a lot of it has been me kind of dancing through trying to figure things out or talking to people that work on the Azure team to get this kind of information. You may see in the future that some of these secrets will show up in the portal and it won't be much of a secret anymore because there will be a button that you click and it does the thing that I'm showing you how to do now. But maybe not. So this post thing is an example of that. So let's go ahead and just copy this little thing and cheat a second here. What I'm going to do is I'm going to go back into the portal and on the dashboard I get a URL to an FTPS, a secure FTP location. And a lot of people don't realize this, but Windows Explorer is an FTP client. So I just opened up Windows Explorer. I pasted that FTP address. I hit go. It's going to authenticate me. So once again I'll type in my password and my username was already there. And we are connecting to the site. Cool. I am now just FTPed into that box that I earlier connected to with Internet Information Services Manager, IIS Manager. So I'm connected that same thing via FTP. If I go into the site, I can see all of my content here in the WW root. I can start deleting things and changing things and you're going to see that live on the website. There's a bunch of other files and folders in here though that are not my website like this diagnostics, repository. This is actually where all my Git code lives and you can see my Git attributes and whatnot. But what I'm going to do is I'm going to go into deployments. Kudu stores all of the information about your deployments on disk. So that's kind of cool. But inside of tools I'm going to create a new directory. So new folder and we're going to call it post deployment actions. Cool. And inside of there I can add any number of scripts that I want to. So batch files or cmd files. So let me go ahead and just create a really simple one so you guys get the point. I'm going to say echo hello from post.bat. Let me save this as post.bat. Not nat, bat. Okay, great. And then let me grab that file. What did I stick to? I stuck it on my desktop. Users, Nick desktop. Post.bat. I'm going to copy this file and just, oh, let me copy it. Sorry guys. Copy the file and I'm going to drag it into this FTP window here. Cool. So I just uploaded a file through Windows Explorer over FTP to my website. Now, any time a deployment happens and instead of re-downloading all the code I'll just redeploy what we already have deployed. That script will execute. So I'm going to click on this deployment. I'll say redeploy. Yes, this should happen much faster this time because there's no source code to download. There's been no changes on the repo. So you can see it's deploying. Cool. We're done. If I come through here and look at the logs you will see that I have executed that file and it's saying hello from post.bat. So obviously I just echoed. That's not really anything interesting. But in this scenario any post steps you would make after deploying something you could do. So priming caches, building contents, a CDN provider, anything like that you can all do in these scripts. You can have multiple ones. So you can have one for each different task you're doing. And Kudu will run them in order, the same order that you see them in Windows Explorer. And if one of them errors returns an exit code of zero it will just stop there and the rest of them don't run. But that's kind of cool, nice little hidden trick that you can do to do things after the build has happened. So that's this post action, the one on the top. But there's also this web hook option which is really handy for guys like me who are web developers. I'm not super comfortable getting down into like scripting batch files or whatnot. But web programming I'm all about. So let's take a look at how the web hooks work. What I'm going to do is I'm going to go to this website called Zapier. Zapier is similar to if this then that, if.com if you're familiar with that website. I like to think of it as programming my mother could do. It's very simple like draggy, dropy, point and click kind of thing. So I'm going to make a zap. And the reason why I'm using Zapier is because the Azure website's team has worked with Zapier to have a nice experience specifically for websites. So when I create a new zap which is basically an if then block of code, I can choose what my if is going to be my trigger. And I'll do a search for Azure. And you can see I have Azure websites. So when this happens, either when a web job is run or a site is deployed, that's the one I care about. So when a site is deployed, then what do I want to do? Now I use this all the time for my side project, which I call Glutly. And what I have Glutly do is send me a text message on my phone every time a deployment happens. So that looks something like this. This is literally a screenshot from my phone. You can see there that my last deployment was successful. I have a URL so I can click and go right to that spot. And you can see I fixed the bug resulting from multiple restaurants being added to a database. I'm American and I don't have a SIM card that works here. So we're going to do something a little bit different, but it proves the point of how easy it is to plug and play with something like Zapier. So instead we're going to go to Twitter, because I do have an internet connection here. And we're going to send out a tweet anytime a deployment happens. So that's what I'm going to do. So when there's a new website deployment, I'm going to create a tweet. Like I said, my mom can do this. Now we need to tell Zapier about my website. And so if I say connect to an Azure website account, you'll notice here that it's asking me for a deployment trigger URL. Well, what's that you ask if you go into the portal and you go over here to configure, there is a field that has just that URL. So I'm going to copy it. I'm going to come back to Zapier and I'm going to paste it. And then we'll give a name to this connection. So this is going to be Azure websites. This is for the NDC demo. Great. Continue. And so you can see here the account is working. Zapier and my website are now communicating. And that communication is happening because the Kudu web service is there. I never see it, but that's what's going on there. I can press continue. I'll make this go to my Twitter account, NickMD23. Continue. I can add filtering so I don't always do this. We'll just skip that step because I want to prove the point to you guys. Continue. And so we'll say deployment happened. And I can put in variables. So if I say insert fields, Zapier now goes out to that web service that Kudu is hosting and it will show me all of the fields that I have available in a moment. Hang tight. Can take a minute, apparently. There we go. So you can see I can use the message, the status, the author, the deployer, all of these different things. We'll just go ahead and put the message into the tweet. Continue. And click the button to test. That's fine. And we're good to go. Oh, I need to name this Zap. So we'll also name this NDC demo. Cool. Turn Zap on. And now, anytime I do a deployment, the website will tell Zapier. Zapier will see that anytime a deployment happens, I should be doing a tweet. And you can see that this thing is on Azure websites to Zapier. So what I'll do here is I'll come back to my website. I'll look at my deployments. We will redeploy, just like as we did before. And while that happens, we'll go over to my Twitter stream to see the tweet come through because the tweet will come from me. I'm a big foodie, as I already mentioned. So you might notice that last night I went out to dinner here in Oslo and we decided to have whale meat. This is not something I'm accustomed to in the States. It made me kind of think that I bet Twitter never fails in Oslo because everybody knows the famous fail whale. You guys would eat it. So Twitter just, it's like we're not going to fail in Oslo. We'll kill our beloved mascot. So that deployment should have finished. It has. Let me go ahead and refresh my Twitter stream. All right. We're still waiting for Zapier to send the tweet through. There we go. Deployment happened adding, tracing for Azure demo. So just like that, a tweet has happened. Maybe it's told all of them, everybody who cares about the website that there's a new version. I'm going to go ahead and delete that tweet so my followers don't get irritated with me. So that is using the web hooks that Kudu allows you to use. Now, all of these steps in the pipeline are extremely configurable and this is something I find that nobody really knows about. So let me show you the configuration points. All of them. So the first thing is you can change the way that Kudu interacts with your source control provider using app settings. I've shown you some of the app settings here. There are more available in the documentation which links are provided for at the end of the talk. So in the app settings, which I will show you really quickly in the portal. If I go to configure, here are my app settings. These are just key value pairs. If I use the right named key as shown on this PowerPoint, these app settings, I can change things like the path in which Kudu will clone all my code or it will say not to use a repository which is what happens automatically with Dropbox or the target path. So you can do really interesting things like do in place deployments. So you can have the code copy right from the repository into the wwroot. So if you just want to deploy your assets already built, maybe you handle the building, you can just flip a couple of switches here and it will grab it and just stick it right in wwroot and you're serving it. The next thing up that we have here is this Iini file which is a little archaic but I guess I would prefer that over XML. There's all these other settings that we can use. So one of them is you'll see this SCM post deployment actions path. So I just had the FTP into the site and go into this tools and deployment directory to put that post.bat file there. Well that's kind of a pain in the butt. What if I just wanted that to be in my source control? That's fine. I could have put that script right in the source control as long as I go and I change the setting and I tell Kudu when you're done, don't run the things for the scripts from where you normally get them, run them from this path that I've given you. So you can override basically everything. And then finally kind of the Mac Daddy, blow everything up and change it, this dot command file. Essentially everything that Kudu is doing, you can stop and say, hey Kudu, will you write down your logic for me into a file so I can change it? And so you can do that. Let me show you what that looks like. I am here at the command line. I've already installed the X platform Azure CLI tools and I'm looking at full stack web perf. That is my repository, my directory where I have all of this code for this mascot website. So I'm going to say Azure site deployment script and that takes in some parameters. This is going to fail. Basically that's the command that I tell Azure to say, hey, persist all of your logic. So what I need to do is I need to tell it first of all that it is an ASP web application. I need to point to my project file so that's in the directory structure. Actually let me show you the directory structure. So you can see that I have a folder called demo. I have my PowerPoint slides for that talk. I have a demo script, etc., etc. So I'm going to say that it's an ASP web application that lives in demo slash minor league baseball web. Minor league baseball web, that's my CS project file. The other thing that I need to do is I have to say that there is a solution file at demo slash demo dot solution. If I run this, it already exists, that's okay, I'm going to overwrite it for this. It is just gone and written in two files to that directory. So let me go back to DER and you can see that there is this dot deployment file here and this deploy dot cmd file here. So let me go ahead and open up in notepad that dot deployment file. This is the INI file I mentioned before that we were talking about. You can see here that I'm telling Kudu the command that you run after you've downloaded all of my source code is deploy dot cmd. That's the new file that just got created. So you can create your own, you can override, you can do whatever the heck you want to, you're just overwriting what Kudu does right from this spot. If I open up that deploy cmd file, oh, nope, I have to spell it right. You can see here this is everything that Kudu does. It looks big, especially when I scroll really fast like that. It's not too bad, it's very well commented. You can see here that essentially it goes through and sets up a bunch of environment variables. These are the variables that you can override from app settings. You can go in and change any one of these. So if you want to change the deployment target, you can go into the portal, add that as an app setting and that will override this deployment target because you can see it's checking to see if it's already defined first. So you can define it there. It comes through and here's where it does the meter that work. The first thing it does is restore new get packages, then it builds into the temporary path and then it does the sync. This is where it takes all the built files and moves it over into your wwroot. So that's cool. If you want to change anything about how this works, you can go in there and do it. If you don't want to go hog wild, here's where it's actually calling MSBuild to do the build. You'll notice at the very end of both of these lines, it's passing in this build args. Once again, this is another setting that you could put in your inifile or in your app settings to say these are additional build arguments that I want passed into MSBuild when I build my site. So you don't even have to go this far. I've gone this far in a couple of my sites, that one that I showed you where I was texting myself. Let's go ahead and look at that deploy file. I don't want to run it. I want to edit it. So you can see that in this file, the standard thing, restoring the new get packages, building, blah, blah, blah, I've gone in and I've added unit tests. So my unit tests basically, oh, here we go. This is the unit test. Sorry. Really just change the directories into where my X unit runners are. That's just a package. So if I look at my packages, you can see all of the different packages and there's the X unit runner is in there somewhere. I use this little handy trick of using a star here, which you can use with change directory because I never know what version of the runner is going because that all gets handled through new get. So I change into whatever the version I happen to have is and I run it. And if there's an error, then I error out and I continue and that deployment won't happen. And then I get text and I'm told that there was an error on the deployment. So that's great. So basically I have a CI server, a continuous delivery server, all in one with four lines of code that I downloaded from the end unit website. So that's great. I can create that command file and basically do whatever I want. Now Kudu does a couple of other things besides just this deployment and building that we've talked about so far. Oh, don't go. We're going to miss you. Have a good day. It does a bunch of debugging and diagnostics and makes that information available for you in ways that would kind of be difficult to do on your own because you're in the cloud. And that's what the special star.scm website. So what I'm going to do is I'm going to come back over here to my browser. I'm going to copy the website that we've been using all along. So this is the NDC demo Azure website. I'm going to paste it and all I'm going to do is I'm going to add in.scm into the URL. So every Azure website that you have right now already has this thing enabled. You just don't know about it. And that pulls up this Kudu page which has all kinds of really useful, interesting things. So the first thing that you'll see is environment, which shows you a bunch of information about the system that I'm running on. I am running on a 64-bit system, but I'm not in a 64-bit process. I have one processor, blah, blah, blah, blah. I can see all of the app settings, the connection strings, the environment variables, all kinds of good, useful stuff for when you get into a jam sometimes. There's also this Process Explorer that I can click on. This is actually an HTML version of Process Explorer. If I hit Control-Shift-Escape, this is my normal task manager that I get for my local machine. I'm looking at the exact same thing now. I'm looking at the same thing now for my remote machine, just an HTML version of it. I can dig in. You can see my W3WP, that's IIS is running. I can dig in and look at the properties there. I can see all of the threads. I can look at the properties of a thread, et cetera, et cetera. I really like this handles. So if you ever get a locked file, you can see which process is holding on to that file. You can go in and you can actually kill the process from this UI. So that's kind of cool. There's some other tools too, like you can download a diagnostics dump. If I click on that, it's going to give me a zip file that I can run through with some debugging tools. There is this Log Stream. Now, this is streaming logging. This is showing me all the logging information that's happening on my website. So if I come back to my website, let's go to a split screen here. As I click around, I go into the Appalachian League and you can see that that log happened. I go back to the home page and you'll see there's the home page. I can go see all the winners. I'll see the winners. So I could be watching this log as hundreds and thousands of people hit this website if it was well known and I could see what's happening live on the website. So that's kind of a cool tool. There's a few other things that are interesting. Oh, web hooks. This is funny. So if you didn't want to use Zapier, this is where you could come and configure your own web hook. You'll see that Zapier has already reached back into Kudu and set itself up as a web hook. But I can type in any URL that I want to right here and any time a deployment happens, Kudu will post deployment information to that URL so that could be a local service that you're running in your enterprise to update some dashboard that sits in front of your manager to let him know that a deployment happened. So that's all good stuff. The last thing that I'll show you, I'll show you two more things in this Kudu. All of Kudu exposes a RESTful JSON-based API so that you can get at this information programmatically. So if I wanted to see the app settings for this website, here they all are and, Jason, you can see that I'm just going to API slash settings. If I wanted to see all the deployments that have happened in this website, I can open that up and here's the deployment. I like this files one. This basically gives me the file system that I was looking at at FTP in a JavaScript way and I can just drill through and say, okay, I want to dig into site and I can follow this link that gives me for site. I want to dig into WW root. I can follow this link to get into WW root and boom, there's my packages config, my scripts, my snippets, my views, all that kind of stuff and I can build a whole file browser just using these APIs. And then lastly, Kudu has this debug console. It has a PowerShell version and a command EXE. I told you guys I'm not much of an ops guy so I shy away from PowerShell. I'm trying to tell me this for developers. I'm not buying it. So I'll just use the good old command.exe. If I come into that, I am actually now looking at a terminal on the machine that my website is running on. And so if I go CD into site, not only did I change directories but you'll notice that the top part, this HTML table has changed and it follows along with what I'm doing in the command line or similarly if I click on WW root, you'll notice that the command down here changes WW root. So I can go in there, I can check things out, I can look at the file system, I can do whatever I want to without having to go into FTP. So this is all quite handy and something that Kudu gives us which is nice. Now, everything that I just showed you there might be a little bit scary because I'm giving you a lot of access just by knowing the SCM part of the URL. That's where I want to stop and take a step back. Kudu is interesting. It runs on the same process and the same sandbox and all that stuff but unlike your actual website which is not authenticated by default, everything inside of Kudu is. I was just already authenticated so you guys didn't see the challenge. Now, there's multiple types of credentials that you use in Azure and this is kind of confusing but as far as Kudu is concerned there's two and they're called deployment credentials. So typically when you log into the portal or something you'll use your Microsoft account, right? Kudu doesn't care about your Microsoft account, it doesn't know what that does or follow it. Instead, it uses either user credentials which you know user credentials from the portal because on the dashboard you'll see this thing that says reset your deployment credentials. That is a user credential. You have one. You have one of those for every single one of your Microsoft accounts which means if I change the password there, it's not just changing it for my minor league baseball website, it's also changing it for GitGlimpse website and it's also changing it for that signatory website because that set of credentials is stuck to me. Never give out that set of credentials. They're yours. If you lose control, you go in there and you reset it and it'll reset everywhere. The next one is site credentials. These are ones that are made for you to give out. They're generated for you but they're specific to a website. So I have four sets of site credentials, one for the minor league baseball website, one for signatory, one for GitGlimpse, etc. They're auto generated so you can tell a site credential because it begins with a dollar sign and the username is always dollar sign and then the name of the site that you're using and then the password is some long messed up GUID. You can actually see this because if I went back, you guys remember earlier we had a copy and paste something into Zapier which is that trigger URL. Look at this. You can see the name of my site is NDC demo and you can see dollar sign NDC demo here. That's that automated username and you can see here's my password and Kudu is just using HTTP basic auth when the client makes a request to that. It rips those things out of the URL, sticks it into an auth header and that gets sent off that standard HTTP authentication stuff. But there you can see that. If you download your published profile which is available from the dashboard, reset your published profile credentials, I could download it as well right here, download your published profile. That's just an XML file and if you dug into that XML file you'll find that exact same username and password. And most of the tooling that you'll use that wants to connect to Azure for you will say give me your published profile. So you're giving it a set of site specific credentials and if you lose control you can reset those as well but those are site by site. So everything in Kudu, you're good, it's authenticated using one of those ways. Great. So we've looked at a whole bunch of different things that we can do with Kudu and the process but I want to stop and also think about what are the ways that we can kind of configure Kudu to do additional things. And it's not even just Kudu but IIS and.NET and what is afforded to us. So this diagram I made, parts of it should be pretty recognizable to you. So everything in all the blue circles, that is the standard.NET configuration scheme that we've known since day one, right? There's a machine.config, there's a root web config, those things get merged in and then you can have web configs and directories going down farther and farther, deeper and deeper and they all get merged together into your application. And that makes web config and if you're running an IIS 6 or before, that is the whole story, just the blue, the dark blue, those three. And IIS 7, they added a new configuration file called application host.config. These are IIS specific settings and that file gets merged in along with the web root. So now you have IIS and.NET code intermingling. In Azure there's yet one more layer which is this Azure overrides and these are all of the configuration settings that you've put into the portal. So all of these things come together to give you final configuration, stuff that you've typed into the portal into your web config from the app host. Microsoft gives you an app host. Now you'll notice that these two of these have a little bubble that says xdt. That's the web config transform schema that's available. You probably recognize this from Visual Studio when you create a new project underneath web config, you have web.debug.config and web.release.config and you know you can make changes there so the release mode and the debug mode look different. That's called xdt. That exact same file format schema is available in Kudu to run on your app host so you can change IIS settings. So let me show you what that looks like. I'm going to go into Kudu again. I'm going to go to this, oh I'm already in the debug console. Great. I'm going to upload a file. So I have this outer curve SVG. This is an image, a scalable vector graphic image so I can zoom in forever and it will always look good. Outer curve is the foundation, the open source foundation that Kudu is a part of. I'm going to upload that to the site. I can do that very simply because I'm looking at my ww root right now. If I drag this up to the web browser, like I said it's kind of an FTP client, I can just drop it and that's going to get uploaded and now I have outer curve SVG. So if I go back to my site, now I can say slash outer curve SVG. But I get an error. Well, that's because by default IIS doesn't know what to do with SVG files. It's easy enough to change. You just go in and you add the file extension and the mime type and you're good to go. But we want to do this in a Kudu way, a way that's reusable. So Kudu allows us to, I'm going to go up one directory so I'm looking at site. It allows us to put one of these transform files in. So I have this application host transform file right here. I'm going to upload that to the site. And now that that's there, I need to restart the site. So let me go to the portal. I'm going to stop the site. I'm going to start the site. Okay, great. The site is starting up now. So because Kudu solved that file with that name and that location, when the site restarted, it said, hey, this user wants to change application host.config. I'm going to apply that transformation. And I'm going to show you that transformation in a second. But now if I go back to this page and I refresh, you can see I'm getting my outer curve SVG file served to me because I added that other file in that one spot. So what does that file look like? It's quite simple. This is the entirety of the file. So I'm using the XDT transform. So I'm inserting an element. I'm adding any file that ends in.svg to serve it as a mime type of image SVG plus XML. I'm also going a step further because I care about performance, which you'll hear more about tomorrow. I'm saying that image SVG is I want to do HTTP compression. So that's that whole file and boom, now my whole website can serve SVG files. This is a pretty simple example. And actually, this example I could have just baked right into my web config and checked it in. No big deal. But Kudu goes a step farther. So here's another example that you might want to use. This is increasing the length of the queue that IIS holds. IIS has a queue. It's a number of requests that it will hold on to. And once you go past that queue, it will start issuing 503 responses. It will say service unavailable. I think that that number by default is a thousand. In this example, we are once again doing a change. We're changing an attribute. That's what the set attribute does. I'm changing it to 5,000. So more people will wait longer before they get service unavailable on my site. But notice there's this XDT site name that's surrounded in parentheses. There's a token there. What's cool about these apphost.xdt files that I can upload to Kudu is it will scan them for certain tokens and replace them with runtime variables, which means that this file I can now upload to any website that I want to because the name of the site, which normally would have been hard coded, is now variable. And you can see there's a couple of different things. There's a site name, there's the app pool name, there's an extension path, etc., etc. That one difference, that one thing that Kudu does opens up a really interesting universe to us. So let me show you another file. This file is going to add something that Kudu calls a site extension. What a site extension is is really just us leveraging the power of virtual directories, which I've never really used before. But now I can take this file. You guys can literally copy and paste this from my slides, change these two variables where it says extension name, and we can start to put things into Kudu ourselves that are authenticated. So we can give our administrators a place to add them in the website completely. Stuff that is is specific that I've already showed you in the Kudu website, and stuff that is important for our app. So let me show you some examples of this. Actually, you know what, no, let me make sure that this is really hitting home. So this is Azure website in a architecture diagram. There's the user site that sits on top. There's a buddy site right next to it, right? That's kind of what our site extensions. The site I've already been showing you is actually a Kudu site extension. It's just this virtual directory kind of thing. And Microsoft installs some of them for you by default. So Kudu, we've already looked at. Visual Studio Online, you might have seen. Web Deployer, Web Jobs, you might have seen. Microsoft puts those there. And if you want to partner with Microsoft and call them and have one built in, they allow for that. But we're not going to do that. We're just regular users and we're not trying to change the way Azure works in general. Instead, we can either install an existing one or we can upload our own. So let me go back to Kudu. And I'm going to come over here to site extensions. And you can see that from my site, I'm on the installed tab and I don't have any extensions available. So I can go to the gallery. Now, this morning when I did my run through, there was an additional option here that put in an IIS log analyzer that would tell me where my traffic comes from and how many hits I have and all these kinds of things. It's gone. Which stinks for you guys because it's kind of cool looking. But it's actually a teachable moment because you can kind of see already where Microsoft is going with this. The reason why it's gone and I had to dig through the Kudu source code to figure this out is because all of these things are just Nuget packages. And it's fed by some private Nuget feed somewhere that Microsoft controls. And that was the one I want to show you was a package on there. And they've removed that package from the feed. That's fine. I'll install another one. It's less impressive, but it'll still give you the point. I'm going to install this file counter. The source for this one is available on the Internet. It's the only one that I know that source is available for. I'm going to press install. And you see I get this little thing that says restart the site. There's actually a bug with restarting the site. Both in the portal and on the site extensions. So I'm just going to stop and start. That's kind of the way to make sure that it really restarts. And so now that I've done that, I have this little play button available on file counter. And file counter is amazing. You ready? I press play. Oh, hold on. It's still starting up. Told you it's amazing. Okay. There we go. The world's most amazing file counter. Your site has 539 files. All this is is a tiny little website that knows where it's sitting and it counts all the files that sit inside of my www route. Spits that back. Not very useful, but you can make it do anything that you want to. Let me show you one that's a little bit more useful for our application. And obviously I can come in here and I can uninstall this thing. And you can imagine a world where there's all these admin tools. I'm not a PHP guy, but PHP MyAdmin is very full featured. And if this is a PHP website, that would be kind of cool to show you. So what I've done is on our minor league baseball website here, every year the winner of mascot mania changes. So this year it's this guy here, Lucille from the Columbus Clippers. And you can see that he's kind of the hero of the website. He's the big picture that you see. And the administrators of this website are constantly saying, hey, there was a new mascot. Can we change it? And I have to go in there and I have to change the code. So what I want to do is I want to give them an administrative tool. But there's no authentication on this website. I don't want to build out authentication. I just want them to be able to use the credentials they already have with Azure to log in. So what I've done is I've created this simple little file, default ASPX. And this is like, I've made it really simple and ugly on purpose because I don't want you guys to focus on the code. But essentially what it does is there's an if statement. If it's a get request, I build up an HTML form that has a select or I'm looping through and writing a bunch of options. And if it's a post, I do some updates to the database. What's important to note is because I'm running in context of the website, I can still get the configuration manager to give me the data context. I have access to all the variables that the website is already using, so I don't have to ask for any input. So to install this, I have created this application host XDT. This is the exact same thing that I'm showing you here, except for the word extension name has been replaced by hero. And so I'm going to take these two files, and I'm going to upload them. So I'm going to come back to the Azure portal. I'm going to go to the debug console because that's the easiest way to upload things. And you'll notice that there's a new directory now that I installed the site extension right next to site called site extensions. So that's fine. Once again, this just follows the convention. I'm going to add a new folder called hero. I'm going to go inside of hero. I'm going to upload these two files, drop them. Boom, they're there. Once again, I made a change here. I need to restart the web app. So let me stop it and start it. Okay. So if I go back and look at my mascots, I'm refreshing. It's going to take a little bit because of the jit, but we'll still see Lucille as the main winner of the mascot. Contest. Wow. Come on. Come back up, Azure. They promised me that this restart thing has been fixed in the new portal, but we'll see. Yes, because deployments, the question is could you use deployment stops? And the answer is yes, because the deployment slots are still spinning up and the process is new, and so kudu when it spins up, we'll do all the configuration stuff. Yeah. So since I named this hero, I should be able to go to hero. Okay. Now my website is really dead. Let's see what's going on together. Wow. Really dead. I'm not even getting console. Well, this is fun. I am stopping and starting to write website. Okay. Well, let's do this. I could check the logs, but I'm not going to go splunking through all that stuff with you guys here. So let me try one thing. Let me. Okay. This is good. The fact that I got this far is great. This is a good sign that this is working now. That's not a good sign. I'm wondering if I screwed up something in my file. Come on, guys. This is the big demo. This is the one you're on. You're like the edge of your seat, right? I've never screwed this up before. Oh, man, Azure is really killing me here. Okay. You know what? I have another option. We're going to use all the tools that we've learned about in this talk right here right now. Just pretend that I meant for this to happen and it would be awesome. I'm going to use FTP and see if I can even FTP in. So like I told you earlier, this stuff is rough around the edges right now. I can go into the site. Nope. Oh, interesting. The site is back. Hey, thank you. You can hit it, but I can't. You might be coming up here to finish this demo, buddy. Well, okay. So the point here is what's supposed to happen is can you, oh, you can't hit this URL because you can't authenticate this. Let me try another browser. Good call, Anthony Van Der. Hey, hey, hey, hey. That's what you wanted. Okay. Is this one? Everybody hold your breath. So what we have here now is in Hero. This is the admin thing. This is that super simple page I showed you. I have a drop down of all of the different mascots and I can pick who was the winner. So who am I going to pick, guys? Come on, Bala Pino, of course. So Bala Pino, I hit submit. That's now updated. If I could get the website to run, which it is, if I hit refresh now, Bala Pino. Stuck the landing, so, so. You guys are cruel. You only laugh when I call myself fat and when I failed. I understand Norway. So that is the bunch of the stuff that I wanted to show you guys about Azure and the different things that you can do. Now here's the big secret that I've learned screwing around with all this. Even in that moment of panic, I did not plan that, I swear. Even in that moment of panic, I felt safe. And the big secret to me to Azure websites and why you can feel safe goes like this. I'm a chef. I like to cook a lot at home and whenever I talk to people who are my friends who want to cook, they say, oh, I don't know how to cook and what if I ruin the meal or whatever. Here's the deal. If you ruin a meal, it's 20 bucks and you can get pizza and you save the meal. When I was working on hardware in that back closet, I was always afraid because what if I screwed up the hardware? It's thousands and thousands of dollars. Let me show you what happens if you screw up the website and Azure websites. One button, done. I've just deleted the website, the SQL server, everything gone and I can recreate it in 30 minutes. That's the big secret. You don't have to be afraid because it's that fast to reset. It's a couple of bucks, it's a couple of minutes and you can reset yourself. So that is what I wanted to share with you guys today. I have two minutes for questions if there are any. Awesome. Guys, thank you very much. I hope to see you tomorrow. Tweet me if you have any more questions. Thank you. Thank you.
have heard of. How many people have heard of or part of DevOps. And Azure, particularly Azure websites has begun to change the way that I think about myself as being just a developer and you have something really custom, really Some of these things are all interesting. But if just deployed in the cloud. So if I connect to a It's standard.net. It's standard Windows. But nice experience specifically for websites. So this is going to be Azure websites. This is for irritated with me. So that is using the web hooks can change the way that Kudu interacts with your logging. This is showing me all the logging Web Jobs, you might have seen. Microsoft puts