In this post we'll explore how we can use the Azure CLI to deploy an Azure Function App running on the "consumption plan" along with all the associated resources such as a Storage Account and an Application Insights instance.

I'll be using PowerShell as my command prompt, but most of these commands translate very straightforwardly to a Bash shell if you prefer.

Step 1 - Create a Resource Group

As always with the Azure CLI, once we've logged in (with az login) and chosen the correct subscription (with az account set -s "MySub"), we should create a resource group to hold the various resources we're going to create.

Step 2 - Create a Storage Account

A number of features of Azure Functions work with a Storage Account, so it's a good idea to create a dedicated Storage Account to partner with a function app. Storage Accounts do require unique names as it will form part of their domain name, so I'm using a random number to help pick a suitable name, before creating the storage account using the standard LRS pricing tier.

Step 3 - Create an Application Insights instance

Azure Functions offers excellent monitoring via Application Insights, so it makes sense to turn this on for all deployments. Unfortunately, the Azure CLI currently does not support creating Application Insights directly, but we can create one with the az resource create command.

Step 4 - Create a Function App

Normally at this point we'd need to create an App Service Plan, but when we're using the consumption pricing tier there's a shortcut we can use, which is to set the --consumption-plan-location parameter when we create the Function App, and we'll automatically get a consumption App Service Plan created for us (with a name like "WestEuropePlan") in our resource group.

We're going to be using V2 of the Azure Functions Runtime, and so I'll specify that I'm using the dotnet runtime, but you can also set this to node or java.

We're also pointing it at the Application Insights instance we just created with the --app-insights switch.

Step 5 - Deploy our Function App Code

Obviously I'm assuming that we have some functions to deploy to the Function App. If we've created a C# Azure Functions project, we can package it up for release by running a dotnet publish, zipping up the resulting folder, and using az functionapp deployment source config-zip to deploy it.

Step 6 - Configure Application Settings

Optionally at this point, we may wish to configure some application settings, such as connection strings to other services. These can be configured with the az functionapp config appsettings set command (although watch out for some nasty escaping gotchas if your setting values contain certain characters).

Step 7 - Configure a Daily Use Quota

Another optional feature you might want to consider setting up is a daily usage quota. One of the great things about the serverless Azure Functions consumption plan is that it offers near-infinite scale to handle huge spikes in load. But that does also leave you open to a "denial of wallet attack" where due to an external DoS attack or a coding mistake, you end up with a huge bill because your function app scaled out to hundreds of instances. The daily quota allows you to set a limit in terms of "Gigabyte seconds" (GB-s), which you might want to set just to be on the safe side when you're experimenting. For a production system, I'd probably rather leave this quota off (or set very high), and configure alerts instead to tell me when my usage is much higher than normal.

Summary

The Azure CLI provides us with an easy way to deploy and manage our Azure Function apps. Of course, you can also create an ARM template that contains the same resources, and deploy that with the CLI. Personally I find the CLI great when I'm experimenting and prototyping, and when I've got an application that's a bit more stable and ready for production, I might create an ARM template to allow deploying the whole thing in one go.

About Mark Heath

I'm a Microsoft MVP and software developer based in Southampton, England, currently working as a Software Architect for NICE Systems. I create courses for Pluralsight and am the author of several open source libraries. I currently specialize in architecting Azure based systems and audio programming. You can find me on: