Zero-downtime deployment of Azure Functions with Terraform

I have an Azure Function App where the necessary cloud infrastructure is scripted by Terraform. The relation to application archive is implemented via azurerm_storage_blob and the app_settings property WEBSITE_RUN_FROM_PACKAGE.

// ...

resource "azurerm_storage_blob" "archive" {
  name                   = "application.zip"
  storage_account_name   = var.storage_account_name
  storage_container_name = var.storage_container_name
  type                   = "Block"
  source                 = "dist/application.zip"
}

resource "azurerm_function_app" "app" {
  name                      = "function-app"
  resource_group_name       = var.resource_group_name
  location                  = var.location
  app_service_plan_id       = var.azurerm_app_service_plan_id
  storage_connection_string = var.storage_connection_string

  app_settings = {
    // ...
    WEBSITE_RUN_FROM_PACKAGE     = "https://${var.storage_account_name}.blob.core.windows.net/${var.storage_container_name}/${azurerm_storage_blob.archive.name}${var.storage_account_sas}"
  }
}

// ...

To deploy a new version of the Function App, I taint the azurerm_storage_blob and run terraform apply. During the execution of the command the Function App isn't avialable for sevaral seconds.

How can I implemented a zero-downtime deployment with Terraform?

I found two approaches but couldn't solve the problem.

1. Terraform's create_before_destroy shouldn't be working because the azurerm_function_app is updated by Terraform.
2. Terraform's azurerm_app_service_slot isn't ready for Function Apps (#1307, #4684)

TL;DR: the azurerm_app_service_slot issues are resolved by PR#6435 and documented by Terraform and Microsoft. This answer doesn't yet cover that completely. To avoid deleting and then recreating your blob, change your blob name when your code changes and add HASH to your app_settings:

resource "azurerm_storage_blob" "archive" {
  name                   = "application.${var.package_version}.zip"
  ...
}

resource "azurerm_function_app" "app" {
  ...
}

resource "azurerm_function_app_slot" "slotStaging" {
  name                       = "stag"
  function_app_name          = azurerm_function_app.app.name
  ...
  app_settings = {
    ...
    HASH = base64encode(filesha256("dist/application.zip"))
  }
}

resource "null_resource" "swapSlots" {
  triggers = {
    HASH = azurerm_function_app.app.app_settings.HASH
  }
  provisioner "local-exec" {
    command = "sleep 1m && az functionapp deployment slot swap -g ${azurerm_resource_group.resourceGroup.name} -n ${azurerm_function_app.functionApp.name} --slot ${azurerm_function_app_slot.slotStaging.name} --target-slot production"
  }
  depends_on = [azurerm_function_app.functionApp]
}

Explanation:
There is a first issue impacting you described at https://github.com/terraform-providers/terraform-provider-azurerm/issues/1990. Basically that Terraform wont detect changes to the content of your zip and needs a mechanism to do so. Making sure the package version name is in the blob name ensure it is updated when a new change happens. It can be any name change, it just seems more elegant to rely on semver.

So long as your code is updated to the bucket and the HASH of it is part of your function's config (as automatically calculated), then Terraform will know to update the function to reload the new code. This will happen as a no downtime configuration change such that the previous code version will be invalidated and a new container will be composed and deployed to your host to handle the next request it is ready to catch.

WIP
The default slot is production. Pushing your updated code into the stag slot followed by the swapping from stag to production

The slot is transitioned with az functionapp deployment slot swap -g MyResourceGroup -n MyUniqueApp --slot staging --target-slot production which can be run in a null_resource.

If I am understanding you correctly in this question, you want to avoid the downtime when you deploy a new version of the Azure function app from a .zip file in the storage account with Terraform.

If there is only one attribute WEBSITE_RUN_FROM_PACKAGE that will change in the code when run terraform apply, I think the Azure function app will be updated in-place. As a workaround, you could use ignore_changes to ignore the websites update first on the first terraform apply. Run the next terraform apply to update the function app after the tainted azurerm_storage_blob has been created.

  lifecycle {
    ignore_changes = [
      app_settings["WEBSITE_RUN_FROM_PACKAGE"]
    ]
  }

Another option, you may create a function app with a new name with a new package. After the new function app provision, you could destroy the old function app. You will use create_before_destroy = true for this. It will generate a new function app URL.

You could refer to this book on page 385, even it talks to the app service, which has the same deployment logic as the function app.