In this tutorial:
- Create the Azure App services
- Add an application to the deployment
- Create a deployment slot for a staging application
- Swap the application from staging to production
Note: You will need an active Azure Tenant or a Trial subscription to complete these tasks, however it is a quick read with snapshots to follow along.
Introduction
Azure App Service is a platform-as-a-service (PaaS) offering that allows you to quickly build, deploy, and scale Web, API, Mobile, and Function apps. The App Service platform supports both Windows and Linux for running applications in a variety of languages and frameworks, such as .NET, .NET Core, Java, Ruby, Node.js, PHP, Python, and Docker containers.
App Service plans are containers for the apps that you deploy in App Service. App Service plans are offered in different tiers, with more functionality provided by higher, more expensive tiers. The following list highlights some of the distinctions between the available tiers:
- Free (Windows only): Run a small number of apps for free
- Shared (Windows only): Run more apps and provides support for custom domains
- Basic: Run unlimited apps and scale up to three instances with built-in load balancing
- Standard: The first tier recommended for production workloads. It scales up to ten (10) instances with Autoscaling support and VNet integration to access resources in your Azure virtual networks without exposing them to the internet
- Premium: Scale up to 20 instances and additional storage over the standard tier
- Isolated: Scale up to 100 instances, runs inside of an Azure Virtual Network isolated from other customers, and supports private access use cases
The most up-to-date information for the features included with each tier is available here and in the Azure Portal as you will see in this Lab Step where you create an App Service plan.
Create App Service Plan
1. In the search bar at the top of the Azure Portal, enter app service plans. Click App Service plans under Services:
2. Click + Add to create a new App Service plan:
3. In the New App Service Plan form, enter the following values and accept the defaults for the rest:
- Resource Group: Create a new resource group in the tenant
- App Service plan: wme-lab-plan (The name must be unique per subscription, but not globally)
- Operating System: Windows
- Location: East US
Go to the new resource
Create the App Service Web App
Azure App Service Web Apps, or simply Web Apps, are the instances of your websites and web applications hosted in Azure App Service. For most scenarios, Web Apps is the best choice for hosting websites and web applications in Azure. Each Web App is deployed into an App Service plan. Web Apps are DevOps-ready and can be deployed using a variety of continuous deployment tools.
In this Lab Step, you will create a Windows-based Web App and learn about the other options available.
Navigate to ‘App Services’ in the console
. In the Web App form, enter the following values and accept the defaults for the rest:
- Resource Group: Select Use existing, then select the Lab’s resource group from the drop-down menu (use the one you created)
- Name: wme-lab-01-#### where you replace #### with random digits. (The name must be globally unique because it is part of the DNS name for the app.)
- Runtime stack: .NET Core 2.x (LTS) (where x is the latest minor version number available)OS: Windows
- Region: East US
- App Service plan/Windows Plan: wme-lab-plan
The properties will reveal the new URL, Browse to the new URL in the App
For this lab , it is https://app-lab-01-1234.azurewebsites.net/ , but your URL will be based on whatever you named the service in the previous properties window.
Add A Deployment slot
Deployment slots allow you to have separate instances of your application that have their own hostnames. This is useful for several reasons:
- You can organize your workflow by having dedicated testing and staging slots in addition to the default production slot.
- Once you have vetted a new release in the staging slot, you can swap it into production to avoid having to warm up the production application.
- By swapping releases into production, the previous release remains in a slot where it can easily be swapped back into production if an issue is found in the new release.
Each deployment slot maintains its own configuration and application settings. Deployment slots are available with the standard and premium App Service plans.
You will create one deployment slot to stage releases in this Lab Step.
Go to the new app service and Deployment>Deployment Slot
As you can see, your new application is running!
Using the Add Slot option
Select Name: staging and do not clone settings
After created you will see both apps
Now that we have a staging version of the application to switch, we can add an application to manage
Key benefits of deployment slots are the ability to swap pre-warmed websites into production, and to easily roll back to the previous version, by repeating the last swap. It is a best practice to use deployment slots when deploying a Web App. There are different types of swaps that you can use depending on the level of confidence you have in a release:
- Auto Swap: As soon as an application is deployed to a slot it automatically swaps into a target slot. This is not the same as deploying directly to the target because the application gets a warm start, and the previous release of the target slot is preserved if a rollback is required.
- Swap: The most basic swap type that requires you to manually trigger the swap operation.
- Swap with preview: This type is similar to a regular swap but allows you to preview the swap before completing it. Because each slot maintains its own configuration and application settings, the web app may not behave exactly as it did in the originating slot, and that is a good thing.
Some settings such as SSL certificates, custom domain names, and scale settings do not swap when you swap deployment slots. Other settings do swap, such as monitoring and diagnostic settings, framework versions, app settings, and connection strings. However, app settings and connection strings can be configured to be sticky and stay with a slot. For example, if you have separate test and production databases, you can configure the database connection string to stick to each slot.
In this Lab, you will deploy a new release to staging and swap into production. You will use a pre-built ASP.NET Core 2 app bundled in a Zip file that is ready to deploy for simplicity. It is better to use a source-controlled deployment method in production. App Services supports deployments via GitHub, BitBucket, Visual Studio Team Services (VSTS), DropBox, and more. You will also see how app settings can be configured to stick to a slot.
Import Testing Application
- Download the pre-built application CALabApp.zip file that you will deploy to the staging slot.
- In the staging app Slot >>Development tools>>Advanced tools
- Click the Go button to Launch Kudo
- Go to tools Zip Push Deploy
- Upload the Zip file provided from step 1 by dragging it into the window
5. Drag the Zip file into the Window provided
Go to the URL for the Website to see application
- Under Application settings for the new application >> New Application Setting
Name: test-setting
Value: blue
- Save the configuration
- See the staging page update
Now we are going to swap the application versions from the staging page to the production version
- Go to the staging properties window and press the swap button on top of the page.
- Source=staging
- Target=production
- Check Perform Swap with Preview
- After reviewing the changes, press swap and validate changes
In this Lab Step, you deployed a Web App to production using Zip file deployment and a staging slot. It is a best practice to use deployment slot swaps to release Web Apps to production with zero downtime and pre-warming. You also saw how slot settings can be used to configure the behavior of Web Apps based on the slot that they occupy.
In the next Part II, we will go through Logging analytics to Monitor and Troubleshoot your application.
