PinotageTodo — ASP.NET Core 2.0 Web App in an Azure App Service

This is part of a series of articles comparing the experience of developing, deploying and maintaining an ASP.NET Core 2.0 web app on the PaaS offerings from Azure, AWS and Google Cloud Platform. You can find the introduction and contents here .

Articles in this series

1. Introduction
2. Introducing the PinotageToDo App
3. Building an ASP.NET Core Web App in Visual Studio Team Services
4. Hosting an ASP.NET Core Web App in an Azure App Service (this article)

Getting to Grips With Azure App Service Concepts

I’m not going to attempt to explain all the concepts and features of the Azure platform, you can visit azure.com for that, but it is important to understand some of the basics.

When you signup on azure.com you are going to be creating an account. This is essentially the Microsoft account you use to access Azure resources.

Within your account you will have at least one subscription. A subscription is a billing agreement between you and Azure, so this is where you are going to see invoices, set payment methods, spending limits, etc. Every instance of an Azure product or service you use will be used within one subscription.

What we are going to be creating to host our app is an App Service (app). This is the compute resources that the Azure App Service allocates to running our application. Specifically, we are creating a web app. We specify the resources that will be made available and any rules for their scaling up or out in an App Service Plan. It is this App Service Plan that determines how much we are going to have pay for hosting our web app. We can place multiple App Service Apps into a single plan and thus get them to share resources which is a nice way to save some money.

Finally, you are going to see mention of resource groups. These are arbitrary collections of resources (like App Service Apps, App Service Plans, Storage Accounts, etc). You can do some useful stuff with resource groups but for now it is enough to consider them as a way for you to organise your Azure resources in a way that makes sense to you.

Setting up a Web App for PinotageTodo

1. If you haven’t already, get yourself an Azure account at azure.com
2. Head to portal.azure.com and login
3. From the dashboard click on the New option from the left-hand menu, select “Web + Mobile” from the Azure Marketplace and click on “Web App” under featured.

4. The Web App Create Blade will be displayed. Give your app a name. This needs to be unique across Azure as the name will be used as a subdomain of azurewebsites.net. A green tick will appear if the name you entered is valid and available.

5. Choose a subscription. If you have just signed up for an Azure account a default subscription will have been created for you and will be selected by default.

6. Create a new Resource Group. The portal will default the name of this group to the App name you entered which is fine for our purposes.

7. Choose Windows as the OS you wish to run the service on. At the time of writing, .NET Core 2.0 wasn’t supported on Linux App Services otherwise we would have used Linux.

8. An App Service plan/Location will have been generated and selected by default for you, but we wish to customise this, so click on this node to reveal the App Service plan blade.

9. Click on Create New to reveal the New App Service Plan blade.

10. Give your App Service Plan some meaningful name. Remember that you can host multiple web apps within this one plan.

11. Choose your location. For the purpose of this demo I am choosing West Europe.

12. S1 Standard is selected by default as the Pricing tier. For the purpose of our demo this happens to be the tier we wish to use, but click on this field to reveal the available pricing tiers and their estimated monthly costs.

13. Close the Pricing tier blade and click on OK in the New App Service Plan blade. You will be returned to the Web App Create blade and the App Service Plan you created will now be selected.

14. Leave Application Insights off for now.

15. Click on Create. You will return to the Azure Dashboard whilst your services are spun up in the background.

16. When the process is complete you will receive a notification that the deployment succeeded.

17. Click on the button to go to the resource. You will see something like the following.

Our Web App is now setup. If you goto the URL in a browser you will see a default starter page.

We now need to get our todo app built and deployed to our Azure Web App.

Deployment Options for Azure Web Apps

There are a variety of ways that you can deploy an app to an App Service. You can choose the one that best fits your development processes.

1. Directly from Visual Studio
2. Via FTP
3. By syncing from your OneDrive or Dropbox account
4. Continuous deployment whenever you push changes to a branch in GitHub, BitBucket or VSTS.
5. Using a local git repository
6. Using a build and release task from a service like Visual Studio Team Services (VSTS)

We are going to take the artifact created by our build process (see here) and release it to the Azure App Service we created above.

If you are new to VSTS, you may find the following guide to the VSTS web portal useful. https://docs.microsoft.com/en-us/vsts/user-guide/work-web-portal

Releasing a VSTS artifact to an Azure App Service

VSTS provides a template that makes deploying an ASP.NET core web app to an Azure App Service pretty straightforward. A VSTS release takes a published build artifact and releases it to one or more defined environments. We setup our VSTS build here.

1. From within your VSTS project, click on the Build and Release hub.
2. Select the Releases page.
3. Click the + button at the top of the left pane and select “Create release definition”

4. The Select Template dialog will be displayed. Select the “Azure App Service Deployment” and click on the Apply button.

5. A Release Definition will be created and opened in edit mode with the Pipeline page displayed. This page provides a visual overview of your release: basically that you take an artifact and deploy it to one or more environments. We need to define the artifact to deploy, and the tasks necessary to deploy to each environment. In this example we will only use 1 environment, but in my day to day use I have at least a test and production environment.

6. Click on the “Add artifact” option. The “Add artifact” dialog will be displayed.

7. When we setup our build we published our artifact to VSTS, so we choose “Build” as our Source type. The Project dropdown will refresh with all the projects in our VSTS account. Choose your appropriate project and then select the Source (Build definition). Click on the Add button and you’ll see the Artifact part of your pipeline is updated.

8. Now click on the Environment that was created by the template. You can give this a meaningful name in the dialog that appears.

9. The red ! next to Tasks indicates that we have some work to do there. So click on the Tasks option (next to Pipeline). The Process panel will be displayed with the fields requiring attention highlighted.

10. Specify your Azure subscription and then choose the App service name from the available options. We are deploying to a Web App so in Web app kind leave the value as Web App.

11. We are now done, but click on the Deploy Azure App Service task to see the various ways you can customise the deployment if you wish.

12. Your pipeline for the release definition is now complete. You can click on the Save button.

13. Click on the All definitions breadcrumb item to return the main releases page. Your release definition will now be displayed in the left hand pane. Hover over it and click the “…” that appears and select “+ Release”.

14. The Create Release dialog appears. You will see that VSTS has identified the latest Build artifact to deploy and it will automatically deploy the artifact to our AzureTest environment once the release is created.

15. A small message will be displayed informing you the release has been created. You can click on the release id in the message to open the Release details page. This page provides a nice summary of your release, any work items associated and which environments it has been deployed to.

Estimated cost for our minimum requirements

We set out the requirements for our app in the introduction. For our app at this stage (hosted in West Europe and with no data persistence necessary) the S1 instance will cost approximately $73.20 per month (correct as at December 2017, check out https://azure.microsoft.com/en-us/pricing/details/app-service/ for up to date pricing.