Contents
Introduction to App Services
An App service is a way for you run code but not have to be concerned about managing a server.
An example of this is a Web app. Using a web app is like using a Windows IIS server that someone else has setup and pre configured for you. You don’t have to worry about the setup of the platform, you just manage the code for the website/app.
App Service Plans
Apps need an Apps Service Plan to work. You pay for an App Service Plan and then can run as many Apps as you can fit into that plan.
Setting up an App Service Plan
- Go to Market Place ->App Service Plan -> New
- Set the Subscription and the Resource Group
- Give the App Plan a name
- Select the OS: Windows or Linux (some apps will only run in Linux, some only in Windows)
- Choose a Region close to your target audience
- Pricing Tier: this is where you set the plan you want. Obviously the better the plan the more expensive. Azure uses the term “ACU” (Azure Compute Units) as a measurement of performance for the plans.
There are different options amongst the tiers, such as being able to set your own domain name or SSL certs, backups, automatic scaling
There are 3 classifications of plans:
– Dev/Test
– Production
– Isolated
https://azure.microsoft.com/en-au/pricing/details/app-service/windows/#pricing
You can run as many Web Apps as you can squeeze into your plan.
Web Apps
Creating a Web App:
- Go to “Create a Resource”
- Select Web App
- Select the Subscription and Resource Group
- Name: this has to be unique across Azure. It will initially have the format yourname.azurewebsites.net but if you are on a paid plan you can set up a custom domain.
- Runtime Stack: this is the platform that the code will run. The option you select here will effect whether you can use Windows or Linux as the OS.
- Select the Region
- App Service Plan: select the plan you created previously
- Click create
It will take a few minutes to deploy the Web App
Web App Settings
Once the Web App is deployed, you will get an option to “Go to resource”. From here you will the overview of you Web App. The Web App service is now up and running.
Continuous Deployment
In the Deployment Centre for the Web App, you will see options for Continuous Deployment. From here you can link your Web App to a code repository (Azure Repos, GitHub, Bitbucket, Local Git) and every time you commit a change to code in your repository it can trigger the code to be published to the Web App
Manual Deployment
Using this option you can use FTP to access and copy App files
Configuration Settings
The settings here are similar to Windows IIS settings.
- Application Settings: these are variables that you can set per application.
- Connection Strings: here you can have your database connection strings so you don’t have to put it in your code
- Stack Settings: here you can select you Stack version and start up commands
- Platform settings: Enable/disable FTP, HTTP version, Web sockets
– Always On: if this is set to off Azure may shut down your service if it hasn’t been used for some time. This is to save resources. It does start up pretty quickly again - Debugging Options
- Certificates: require incoming certificates
- Custom Domains setup
- TSL/SSL: require HTTPS
- Networking: you can whitelist connections between your Web App and VMs or other resources on an Azure VNet.
Scaling Web Apps
Scale Up
This means moving to a larger App Service Plan to get more resources. The move is seamless for end users.
Scale Out
You have options here. But if you are on a basic plan you will only have Manual scaling.
- Manual Scale: Here you select to increase your instance count. EG: if you set it to 2 you will then have 2 Web App service plans in place which doubles your resources. There is a Load Balancer in place in front of the App Service Plans. There is a limit to how many instances you can have. This limit depends on your plan. Basic plans have a limit of 3, Premium plans can go up to 10
- Auto Scale: This can be used on Standard or above plans. This option allows you to automatically add another instance if the App hits certain metrics, then remove that instance if the load gets reduced. EG: you can set the metric for if the CPU Percentage averages 80% for 10 mins, then add another instance. Then when the CPU percentage is less than 20% over a ten minute period remove 1 instance.