Few months back azure released a new offering called Application service environment. More details on it can be found here : https://docs.microsoft.com/en-us/azure/app-service/environment/intro
The Azure App Service Environment is an Azure App Service feature that provides a fully isolated and dedicated environment for securely running App Service apps at high scale. This capability can host your web apps, mobile apps, API apps, and functions.
App Service Environment, or ASE, have one new feature which was missing earlier. This is called as Internal ASE, which, allows you to deploy web application with an internet-accessible endpoint or with an IP address in your Virtual Network. This means you can create web apps like before but with no external endpoint.
However, since internal ASE is completed isolated, automated deployments and CI/CD pipelines need bit of work to setup. In Internal ASE, the publishing endpoint isn’t internet accessible. So, what we can do is make a build agent for VSTS in our v-net on the subnet that is internet accessible. And then let this agent, pull the code or build artefacts and deploy to ILB ASE. Since ILB ASE and our custom agent are on the same v-net, agent will be able to communicate to the internal ILB ASE deployment endpoint.
Please refer to below on how to implement this.
- Below is screenshot my test account. 3 main resources to point out here are the ilbasev2 (the ILB ASE environment), ilbasev2appname (the web app where I ll host my demo site) and jumpbox (VM hosted on the DMZ subnet to act as build agent and push to internal endpoint).
- Next we will login to the jump box and create VSTS build agent. I want to connect this agent to my VSTS account to make sure all the build and deployment is happening via this agent. Please refer to below URL on how to setup the agent. Since I will demo using a .net MVC application, I am going to create a windows agent.
Also make sure MSBuild is installed on this VM, so that we can build our MVC solution. https://msdn.microsoft.com/en-us/library/dd393574.aspx
- Once above is done, navigate to Agent queues screen under settings as per the screenshot below in your VSTS account and confirm that agent is setup correctly and connected to VSTS.
- Next we will make our build definition. We will create a simple build definition which will pull our demo MVC application code, restore packages and publish the artefact. The only thing to note here is the MSBuild argument. In case you are using a self-signed certificate for ILB ASE, you may want to add additional argument with MSBuild to make sure you don’t get any certificate related issues during build. The argument to use is ‘AllowUntrustedCertificate’ with value true.
The other way to go around self-signed certificate is to just manually install the certificate in your build agent server trusted certificate folder.
- Once the build definition is setup, we can queue to execute it. Before we do that one important thing is to set the Agent Queue. Make sure it is the build agent that we have setup earlier. That will make sure our build agent is working as expected for later steps. We may use the hosted agent for builds too though for this step.
- Below is what you see if everything is working ok.
- Next we focus on release and deployment to ILB ASE. Below is a simple release definition with more details in next point. MY environment here the Azure ILB ASE that I am targeting the deployment too
- All this release does is deploy our artefact to the azure web app created using ILB ASE. One key thing to point out is the Agent Queue Parameter. Make sure it is pointed to our build agent that we created earlier.
- Create a new release using above release definition and you should be successfully able to move your code to ILB ASE.
- If you don’t use the build agent that we created earlier but use VSTS hosted one, then you should see this error. This is because the VSTS agent could not connect to the internal deployment endpoint of ILB ASE.