The purpose of this document is to provide a high level guide on how to provision the required infrastructure resources and deploy an Azure Function based on a c# class library using PowerShell, following principals which align with a typical CI pipeline.
A sample project is located in the following repository: https://github.com/dougbrw/AzureFunctionExample which contains an arm template, azure function, and relevant deployment scripts.
This sections describes the files which comprise an Azure function
This file contains global configuration options which are shared between all functions on a given function app, including:
- Polling intervals
- Batch sizes
- Logging level
- Timeout: When using a consumption plan there is a maximum run time of 5 minutes before a function will time out.
This defines any function specific configuration, including:
- Path to the script file or class library
- Input trigger
- Output bindings
- Enabled or disabled state
The following languages are supported:
- Bash (.sh)
- Batch (.bat)
- C# script file (.csx)
- C# class library (.dll)
- F# (.fsx)
- JavaScript (.js)
- Php
- PowerShell (.ps1)
- Python (.py)
Step 1. Provision Infrastructure (ARM Template)
A function requires the following resources which should be provisioned using an ARM template:
- App Service Hosting Plan: This is essentially a container for the function app which defines the region and pricing tier. The most important choice here is between the "Consumption" or "Dedicated" service plan, as this cannot be changed once created.
- Storage Account: A storage account is required for a number of reasons, including logging, and allowing the script runtime to share files when scaling across multiple instances. You can use this same storage account within your function for data storage if required.
- Function App: Multiple functions can be deployed to a single function app. Whilst multiple languages can share a single function app, they must all use the same version of the runtime host. This also provides collective management tools (diagnostics, monitoring, etc).
Once the template has finished deploying then continue to the next step.
Build AzureFunctions.sln using visual studio fom the example repository to proceed to complete this step.
Microsoft have confirmed that the next version of the Visual Studio tooling for Azure Functions will be aimed at using pre-compiled c# class libraries rather than script files. Some advantages when compared to script files are:
- IntelliSense
- Local debugging
- Unit testing
- Improved performance
- Better continuous integration tooling support
When creating a function make sure the scriptFile property within function.json file references the correct path! This must be the relative path to the script file on the remote Azure file system once deployed.
{
"disabled": false,
"scriptFile": ".\\bin\\FunctionsLibraryProject.dll",
"entryPoint": "FunctionsLibraryProject.HelloHttpTrigger.Run",
"bindings": [
{
"authLevel": "function",
"name": "req",
"type": "httpTrigger",
"direction": "in"
},
{
"name": "res",
"type": "http",
"direction": "out"
}
]
}This step would typically be performed by your CI server, but for the purpose of this guide you can create the package using the following command:
nuget pack AzureFunctions.nuspec -version 1.0.0.0The directory structure of the package content is key, Each function should have its own directory containing the function.json and a sub directory named bin containing the code.
If you wish to include a host.json file, then it should be added to the root of the nupkg file. It can be deployed at the same time as a function, or on its own as a seperate step.
Step 4. Deploy NuGet deployment package (Deploy-AzureFunction.ps1)
This step takes the package previously created, and then uses Azure kudu REST API zip endpoint (A nupkg file is really just a zip file with some metadata) to upload the package to the Function App. When successful the function will be displayed in the portal within a couple of seconds.
If your function is not visible in the portal then now is the time to jump to the Kudu diagnostics debug console, and review the contents of the site/wwwroot directory. The function definition file should be located in site/wwwroot/<FunctionName>/function.json and the class library within site/wwwroot/<FunctionName>/bin.
The diagnostic console can be found at: https://<FunctionAppName>.scm.azurewebsites.net/DebugConsole
If you require to perform any configuration transform / substitution at deploy time then you may require some additional steps here:
- Extract the nupkg contents
- Perform modifications
- Re-package into a nupkg file (or create a zip file)
- Run deployment script using the new package
Most of the links are broken could you please update it?