A powerful feature of app services in Azure is deployment slots. When publishing updates to app services, you need to be confident that your latest changes do not break the existing running application.
Although you should always test changes in lower environments such as a development or test environment first, a final production deployment can still cause unexpected outages. For example, a connection string and configuration may be incorrectly configured.
Whereas development or test deployments of your systems are used to check for functional or user acceptance, final pre-check or staging environments can be used to confirm configuration elements before the final go-live.
The best way to confirm such elements would be to connect your deployment to live systems. Deployment slots allow us to perform this live check without overwriting our running production code.
When you create an additional deployment slot for an app service, one will be the production slot on your main URL and the others (you can create multiple) are given unique URLs. When publishing your code, you can then deploy to one of the non-production slots and then test your newly deployed code on the test URL.
The configuration is considered to release code, and therefore configurations such as database connection strings are the production versions. All your tests are consequently made against the production databases and other services. Once you have validated the deployment, you then swap the slots – the non-production slot becomes production, and the production slot becomes non-production. Therefore, the code you deployed now becomes the live code.
Another critical aspect to consider when building app service solutions is connecting to backend services such as databases or Azure storage accounts. To help with this, you can use a feature called VNet Integration and service endpoints.
App services VNet Integration
App services rarely work independently; they often need to store and retrieve data from storage services as files or database records. Azure storage accounts and Azure SQL databases are great options for these scenarios; however, the connection is made via public endpoints by default.
For some organizations, this is not acceptable, and those services need to be locked down to only allow access from specific services, such as your frontend app service. Many Azure components supporting service endpoints services are direct communication lines between services using the Azure internal backbone instead of public endpoints.
This is achieved in the backend storage component by authorizing specific VNets and subnets in the firewalls view of the service you wish to protect, as we can see in the following example for securing a storage account:
Figure 11.1 – Securing a storage account
This works for VMs that connect natively to VNets, but for app services, you must enable VNet Integration. VNet Integration allows you to connect your app service to a VNet in your subscription, and doing so will let you take advantage of VNet services.
VNet services offer the following benefits:
- Service endpoints: Allow secure, direct communication between Azure services.
- Network security groups: Block and allow specific outbound communications from your deployed apps.
- User-defined routes: Force outbound traffic via specified routes, for example, an Azure Firewall appliance.
By integrating your app services with VNets, you gain greater security and control, which in turn can help you adhere to stricter organization requirements.
We mentioned earlier that app services cover both web apps and API apps. In the next section, we will look into more details about API apps.
Leave a Reply