Azure stack deployer

An azure wrapper for faasbenchmark

This golang library deploys azure functions and implements the relevant faasbenchmark interfaces by wrapping the azure az and func CLI tools.

An faasbenchmark stack is a collection of functions and faas provider resources they depend on. As such, an azure stack is made out of azure functions and ARM (Azure Resource Manager) templates specifying all the resources they depend on.

Azure stack folder structure

An azure stack is a collection of the following files and folders:

mystack
├── stack.json
├── deployment1
│   ├── host.json
│   ├── local.settings.json
│   ├── template.json
│   ├── func1
│   │   ├── func-description.txt
│   │   ├── function.json
│   │   └── ... actual function files ...
│   └── ... more functions ...
└── ... more deployments ...

stack.json

This JSON file contains information describing the stack as a whole.

{
  "name": "mystack",
  "location": "eastus", // Azure location to deploy to
  "project": "faastest", // should stay constant
  "stage": "dev" // used for versioning
}

deployment files

• template.json should be a valid ARM template.

• host.json and local.settings.json are generated by the func CLI tool and can be obtained by running func init.

• local.settings.json must specify the deployment runtime in the FUNCTIONS_WORKER_RUNTIME field. If a runtime version is required, it should be specified in this file as well in the right field (e.g WEBSITE_NODE_DEFAULT_VERSION for node)

function files

• func-description.txt should contain a description of the function.

• function.json is the azure configurations file for the function and should be written according to the official documentation.

The function directory name serves as the function name. The function name should be unique in the stack.

More info

One can look at the example stack provided in this repository (in the examplestack folder) for a more complete overview of an azure stack.

Azure deployments

• An azure function requires a functionapp and a resource group.

• Functions with different runtimes can't share the same functionapp.

• functions running on different OSs can't share the same resource group.

• That's why the azure stack deployer introduces the concept of an azure deployment. An azure stack can contain multiple azure deployments, each containing it's own function(s).

• Each deployment defines it's own resources. This way, functions running on different runtimes and OSs can exist in seperate deployments but share the same stack.

Azure deployment epoch

• Azure functionapps names should be globally unique as they are given a public URL.

• In order to increase the odds of the functionapp name not being taken, the current time epoch number is concatenated to it when deploying.

• This also ensures that deploying the same stack twice won't cause naming collisions.