WebApps is at the far end of the PaaS abstraction level and has always meant that you don’t touch the VM that is hosting your app. The App Service Plans (prev Web Hosting Plans) had the Free and Shared\u00a0options that ran your app in a truely shared and multi-tenant environment. If you needed to do some basic stuff, like uploading a SSL cert for https to work, or adding host names for a CNAME DNS to work, you had to move to the Basic or Standard plans that were a little more dedicated. The Standard plan was required if you wanted to add the P2S VPN Virtual Network capability, for instance. With an\u00a0SSL cert uploaded you could almost get a\u00a0reliable ip address of your website, although that isn’t really promised or documented.<\/p>\n
The App Service Environment\u00a0takes the plans to a whole new step beyond the Standard plan. It provisions an environment of VMs with the WebApp\/WebSite functionality that is just dedicated for you, and you alone. I’m not going to repeat what\u00a0others have written, so check the references at end for introduction blogs. I will, however, tell you how it works from a WebApps\/VNet perspective.<\/p>\n
First, think of ASE as something that just holds your WebApps (WebSites). It’s like if you previously needed to create a new Standard Hosting Plan before you could use it, ie you had to click New in the portal, or, run a powershell script like Add-AzureWebsiteHostingPlan -Name yada-yada -Type “Standard”. That is what the ASE is.<\/p>\n
ASE Front end and Worker Pools<\/strong><\/p>\n This can be a bit tricky\u00a0at first glance, but the Worker Pools are where you app(s) are\u00a0hosted. Since an ASE can host as many of your\u00a0WebApps as you like to squeeze in, and since they may have\u00a0different scaling requirements, the ASE comes with three different Worker Pools that you can scale independantly. It’s the IaaS equivalent of letting the web servers run on A1\/D1 VMs and the database server running on something more powerful, so to speak.<\/p>\n Currently, you have three Worker Pools and you can decide for each of them what VM size they should have. You don’t have to use all three pools and if this is just a test ASE, you probably will only use one of them and\u00a0scale the other two down to zero VMs.<\/p>\n The Front End pool is nothing you provision stuff to. It’s just a pool of VMs taking the first hit at terminating SSL, etc. Forget it’s even there when you start learning\u00a0ASE.<\/p>\n My Virtual Network<\/strong><\/p>\n In my example, I will use a Virtual Network that looks like below. The app7 subnet will be dedicated to the ASE environment and it is advisable to let an ASE have an entire subnet of its own. Don’t co-hab IaaS VMs in it. In the infra6 subnet I will provision an IIS VM and in the dcnet7 there will be an AD\/DNS server. (Yes, the\u00a0use of the\u00a0suffixes\u00a06 and 7 are inconsequent).<\/p>\n <\/p>\n The IaaS VMs provisioned shows up in the VNey config page, but anything you do with ASE does not show up. Listed below are my AD\/DNS server cljungadwe6 and my IIS VM cljungwswe6. The DNS for the VNet is 10.6.3.4, ie the AD\/DNS server.<\/p>\n If you decide to give ASE a spin, make sure you get all this configured before you create the ASE, since ASE is in preview and don’t pick up changes in your VNet config\u00a0too often.<\/p>\n Creating the App Service Environment<\/strong><\/p>\n When you create the ASE you will get that chance to point it to an existing VNet\/Subnet. You can not have multiple ASEs in one subnet, so make sure you don’t reuse your subnets. Once you press the Create button, Azure will start spinning up the number of VMs you selected for your Worker and Front End Pools. During this provisioning, the VMs will grab info from the VNet, like DNS, so that’s why it’s important that all that is in place before you press create. Also, if your app is layered and requires network segmenting, you will be needing 2 or more ASEs and you will probably need Network Security Groups (NSG) to allow\/deny network traffic between the subnets. I will not do this\u00a0in this post.<\/p>\n Deploy your WebApp<\/strong><\/p>\n The ASE takes currently almost an hour to provision and you just have to wait for it to complete. When it’s done, you can deploy your webapp just like you did previously with Azure WebSites – but with one major difference! You have to create the WepApp (WebSite) inside the new portal (portal.azure.com) and attach it to the ASE.\u00a0It’s that way the WebApp understands that it’s hosting plan isn’t Free, Shared, Basic or Standard. “Attach” is probably the wrong word. What you really do is find the ASE you created under the selection of Location, so instead of selecting West Europe, etc, you select the ASE as the provisioning Location.<\/p>\n I have a powershell script that takes a web deployment package zip file and deploys it to a\u00a0WebSite and that is how I deployed my little debug website below.<\/p>\n What this page does is just checking the environment and making a couple of web calls. The Request sent from IP<\/strong> is just the REMOTE_HOST in the request header so I can see where the browser request comes from. The Internal Server Ip addr<\/strong> is just an enumeration of the IPv4 addresses found on the web servers local NIC(s). Here you can see that the webapp inside a ASE only can find the loopback ip address.<\/p>\n The Outgoing traffic from IP<\/strong> is determind by making a outgoing web request to checkip.dyndns.com and parsing the result. This is handy to determind the webapps external VIP.<\/p>\n The VNet internal traffic from IP<\/strong> is determind from making a web request to the IIS VM on it’s internal VNet ip address. Since both the IIS VM and the WebApp should be in the same VNet, although in different subnets, this call should work. It also tells us that the ip address the webapp has in the VNet is 10.6.1.8\u00a0(The IIS VM checks it’s REMOTE_HOST and returns that in the http response).<\/p>\n Lastly, the DNS Servers<\/strong> shows us that the DNS server the webapp is using is the one that was configured in the VNet. This means that the webapp is a member of the VNet and could use the name resolution of your enterprise.<\/p>\n To prove this, I let the webapp do the internal VNet call using a name only the AD\/DNS server 10.6.3.4 would be able to resolve. The AD domain in my demo\u00a0was named yabbadabbadoo.local<\/em> and the webapp was able to make a call using the name cljungwswe6.yabbadabbadoo.local<\/em>. If your DNS infrastructure in your VNet is connected via a VPN gateway back to on-premises, this would mean that the code running in the webapp would be able to access resources in your local on-premises datacenter. Azure WebApps meets the enterprise.<\/p>\n One thing you still can’t do with your WebApp is making it\u00a0and intranet only website, since it’s not possible to browse to it using the VNet ip adress, like 10.6.1.8 above.<\/p>\n <\/p>\n References<\/strong><\/p>\n MSDN – Introduction to ASE MSDN – How to Create a WebApp in ASE \/\/Build – Program Manager Yochay Kiriaty explains ASE![\"vnet-config\"](\"https:\/\/blog.redbaronofazure.com\/wp-content\/uploads\/2015\/06\/vnet-config.png\")
<\/a><\/p>\n<\/a><\/p>\n<\/a><\/p>\n<\/a><\/p>\n<\/a><\/p>\n
\nhttps:\/\/azure.microsoft.com\/en-us\/documentation\/articles\/app-service-app-service-environment-intro\/<\/a><\/p>\n
\nhttps:\/\/azure.microsoft.com\/en-us\/documentation\/articles\/app-service-web-how-to-create-a-web-app-in-an-ase\/<\/a><\/p>\n
\nhttp:\/\/channel9.msdn.com\/Events\/Build\/2015\/2-633<\/a><\/p>\n