Terraform-provider-azurerm: Support Bring Your Own Storage for Web Apps

[jamesbibby]

Community Note

• Please vote on this issue by adding a 👍 reaction to the original issue to help the community and maintainers prioritize this request
• Please do not leave "+1" or "me too" comments, they generate extra noise for issue followers and do not help prioritize the request
• If you are interested in working on this issue or have submitted a pull request, please leave a comment

Description

Microsoft has announced a new "Bring Your Own Storage" for App Service for Linux deployments. This allows you to have a storage account mounted at a custom mount point in your AppService (including WebApps for Containers). My primary use case is mounting shared storage (for image uploads) that are shared between different WebApp for Containers Deployments. This configuration automatically mounts the storage containers inside my containers at the specified mount point.

New or Affected Resource(s)

I am not sure if this represents a modification to the existing:

• azurerm_app_service

or a new resource named something like:

• azurerm_app_service_storage_account

Potential Terraform Configuration

resource "azurerm_resource_group" "test" {
  name     = "some-resource-group"
  location = "centralus"
}
resource "azurerm_app_service_plan" "test" {
  name                = "some-app-service-plan"
  resource_group_name = "${azurerm_resource_group.test.name}"
  location            = "${azurerm_resource_group.test.location}"
  kind                = "linux"

  sku {
    tier     = "Standard"
    size     = "S1"
    capacity = "1"
  }

  properties {
    per_site_scaling = "false"
    reserved         = "true"
  }
}

resource "azurerm_app_service" "test" {
  name                = "${random_id.server.hex}"
  location            = "${azurerm_resource_group.test.location}"
  resource_group_name = "${azurerm_resource_group.test.name}"
  app_service_plan_id = "${azurerm_app_service_plan.test.id}"

  site_config {
    always_on                 = "true"
    use_32_bit_worker_process = "true"
  }
}

resource "azurerm_storage_account" "test" {
  name                     = "storageaccountname"
  resource_group_name      = "${azurerm_resource_group.test.name}"
  location                 = "${azurerm_resource_group.test.location}"
  account_tier             = "Standard"
  account_replication_type = "GRS"
}

resource "azurerm_storage_container" "test" {
  name                  = "images"
  resource_group_name   = "${azurerm_resource_group.test.name}"
  storage_account_name  = "${azurerm_storage_account.test.name}"
  container_access_type = "blob"
}

resource "azurerm_app_service_storage_mount" "test" {
  name              = "some-storage-mount-name"
  custom_id         = "some-storage-mount"
  resource_group    = "${azurerm_resource_group.test.name}"
  app_service       = "${azurerm_app_service.test.name}"
  storage_type      = "AzureBlob"
  storage_account   = "${azurerm_storage_account.test.name}"
  storage_container = "${azurerm_storage_container.name}"
  access_key        = "${azurerm_storage_account.primary_access_key}"
  mount_path        = "/var/www/html/img"
}

References

Blog Post:
https://blogs.msdn.microsoft.com/appserviceteam/2018/09/24/announcing-bring-your-own-storage-to-app-service/

My initial forum question:
https://social.msdn.microsoft.com/Forums/en-US/0d01e8f8-12a9-4289-b944-2ce6a51edec4/mounting-shared-storage-on-a-web-app-for-containers?forum=windowsazurewebsitespreview

[jamesbibby]

I am happy to help with the go implementation of this feature, but would like to get some guidance on approach, naming, location of the new code.

[tombuildsstuff]

hey @jamesbibby

Thanks for opening this issue :)

Taking a look into this it appears this is available in the next version (v22) of the Azure SDK for Go - via this API method:

func (client AppsClient) UpdateAzureStorageAccounts(ctx context.Context, resourceGroupName string, name string, azureStorageAccounts AzureStoragePropertyDictionaryResource) (result AzureStoragePropertyDictionaryResource, err error) {

With regards to resource design - taking a look at this it appears these can be mounted at both the App Service and the Slot level - such that I think these'd make the most sense as properties within the azurerm_app_service resource, rather than as an independent resource; something like this:

resource "azurerm_app_service" "test" {
  # ...

  storage_mount {
    mount_path = ""
    storage_type = "AzureFiles"
   # ...
  }
}

What do you think?

Thanks!

[SbiCA]

@tombuildsstuff that would be awesome, but I'm not sure if you could somehow infer the storage_type if you define the account as resource as well (would just be a bit less stuff to setup) ?

Besides that I have working example with app_service with linux containers + compose (unfortunately not everthing in tf yet because I had to do the mount part manually)

version: '3.4'

services:
  ravendb:
    image: ravendb/ravendb-nightly
    environment:
    - RAVEN_ARGS='--Setup.Mode=None'
    - RAVEN_Security_UnsecuredAccessAllowed='PrivateNetwork'
    - RAVEN_License_Eula_Accepted=true 
    ports:
    - "80:8080"
    volumes:
    - ravenmount:/opt/RavenDB/Server/RavenData

[hashibot[bot]]

This has been released in version 1.32.0 of the provider. Please see the Terraform documentation on provider versioning or reach out if you need any assistance upgrading. As an example:

provider "azurerm" {
    version = "~> 1.32.0"
}
# ... other configuration ...

[hashibot[bot]]

I'm going to lock this issue because it has been closed for _30 days_ ⏳. This helps our maintainers find and focus on the active issues.

If you feel this issue should be reopened, we encourage creating a new issue linking back to this one for added context. If you feel I made an error 🤖 🙉 , please reach out to my human friends 👉 [email protected]. Thanks!