Add support for static website to azurerm_storage_account

[hughtopping]

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

Static website hosting for Azure Storage is now in public preview. See here for Azure announcement.

Currently this can be added with the Azure Portal UI, but is missing from the azurerm_storage_account Terraform resource.

New or Affected Resource(s)

• azurerm_storage_account

Potential Terraform Configuration

resource "azurerm_storage_account" "static_website" {
  account_replication_type  = "RAGRS"
  account_tier              = "Standard"
  account_kind              = "StorageV2"
  location                  = "westeurope"
  name                      = "static_website_storage_account"
  resource_group_name       = "static_website_rg"
  enable_https_traffic_only = true

  static_website {
    enabled             = true
    index_document_name = "index.html"
    error_document_path = "error.html"
  }
}

References

• https://azure.microsoft.com/en-us/blog/azure-storage-static-web-hosting-public-preview/

[0x7f]

For those who can not wait until this feature lands in stable terraform and still want to manage their storage with static website hosting enabled via terraform, I have a possible workaround.

First, I tried creating azurerm_template_deployment and enable the static website feature via an ARM template. Unfortunately this is not possible, because static website feature is also not available via arm templates yet, see here. It is only possible via Blob Service REST API since API Version 2018-03-28 which you can use via azure cli.

So the workaround is to run enable static website via azure cli using terraform's local-exec provisioner. Based on your example it could look like:

resource "azurerm_storage_account" "static_website" {
  account_replication_type  = "RAGRS"
  account_tier              = "Standard"
  account_kind              = "StorageV2"
  location                  = "westeurope"
  name                      = "static_website_storage_account"
  resource_group_name       = "static_website_rg"
  enable_https_traffic_only = true

  provisioner "local-exec" {
    command = <<EOF
az extension add --name storage-preview
az storage blob service-properties update \
  --subscription "${var.subscription_id}" \
  --account-name static_website_storage_account \
  --static-website \
  --404-document 404.html \
  --index-document index.html
EOF
  }
}

This will make sure that the static website feature is enabled via cli right after the storage account resource is created.

Downside of this is that the command will never be executed when you import an existing storage account into your tfstate and just want to enable static website later. To allow this, you can move the local-exec into a dedicated resource and let it depend on the storage account resouce, e.g.:

resource "null_resource" "static_website_cmd" {
  provisioner "local-exec" {
    command = <<EOF
az extension add --name storage-preview
az storage blob service-properties update \
  --subscription "${var.subscription_id}" \
  --account-name static_website_storage_account \
  --static-website \
  --404-document 404.html \
  --index-document index.html
EOF
  }

  depends_on = ["azurerm_storage_account.static_website"]
}

This way you are more flexible, e.g. you can taint the null_resource (which manually marks the resource for redeployment in the tfstate) and by that triggers a re-execution of the command. Tainting can be done like this:

$ terraform taint -module my_module null_resource.static_website_cmd
$ terraform apply
...
-/+ module.my_module.null_resource.static_website_cmd (tainted) (new resource required)
      id:                               "123456789123456789" => <computed> (forces new resource)
...

[katbyte]

Hi @hughtopping, @0x7f

I looked at the latest version of the SDK & storage API and I don't see any sign of these properties 🙁 Until they are in the SDK this is unfortunately blocked.

[0x7f]

Hi @katbyte true, the Azure Go SDK does not support it, but there is also the azure-storage-blog-go SDK that actually has support for it, see here. To be honest, I don't know the difference between the two SDKs, especially since both are provided by Azure. Maybe it is possible to use that one instead?

[tombuildsstuff]

@0x7f there's several blocking issues in the new Storage SDK which mean we're unable to migrate over to using them at this time, unfortunately.

[mikaelkrief]

Here the code provided by Microsoft blog using the provisionner

resource "azurerm_storage_account" "webblob" {
  name                     = "${var.dns_name}"
  location                 = "${azurerm_resource_group.demo-rg.location}"
  resource_group_name      = "${azurerm_resource_group.demo-rg.name}"
  account_kind             = "StorageV2"
  account_tier             = "Standard"
  account_replication_type = "LRS"

   provisioner "local-exec" {
    command = "az storage blob service-properties update --account-name ${azurerm_storage_account.webblob.name} --static-website  --index-document index.html --404-document 404.html"
  }
}

source : terraform-jamstack-azure-gatsby-azure-pipelines-git

[kvaes]

Good suggestion! Just tested it and I found a few issues with it...

• The "blob service-properties update" does not exist?

• When the provisioner is added to an existing resource, then the command is not executed. As the provisioner is run after creation...

• When the storage account was just deleted, then the following error occurs (so keep some "cooldown" time in mind) ;

• azurerm_storage_account.storage: Error creating Azure Storage Account "vmsnoozerdev": storage.AccountsClient#Create: Failure sending request: StatusCode=0 -- Original Error: autorest/azure: Service returned an error. Status=404 Code="StorageAccountNotFound" Message="The storage account vmsnoozerdev was not found."

• The "az login" part is quite key. Either do it (as the blog describes) via a prior build step, or within the command itself. Examply by using a service principal ;

resource "azurerm_storage_account" "storage" {
  name                     = "${var.prefix_workload}${var.prefix_environment}"
  resource_group_name      = "${azurerm_resource_group.storage.name}"
  location                 = "${azurerm_resource_group.storage.location}"
  account_tier             = "${var.storage_tier}"
  account_replication_type = "${var.storage_resiliency}"

  provisioner "local-exec" {
    command = "az login  --service-principal -u \"${var.armclientid}\" -p \"${var.armclientsecret}\" --tenant \"${var.armtenantid}\" | az storage blob service-properties update --account-name ${azurerm_storage_account.storage.name} --static-website  --index-document index.html --404-document 404.html"
  }
}

[kvaes]

follow-up ;
Apparently the "blob service-properties update" is only available with the preview extension

[pburkholder]

@pwelch @ykhemani Here's the Azure issue I was up against this week. If this were a native Terraform feature, instead of a local-exec it would make this Microsoft blog, https://cloudblogs.microsoft.com/opensource/2018/11/16/terraform-jamstack-azure-gatsby-azure-pipelines-git/, I lot less janky. cc: @lenisha

[lenisha]

@pburkholder, yes waiting for this feature.

[Djiit]

So does this mean it's being ignored by hashicorp devs ?

[tombuildsstuff]

@Djiit no, unfortunately there's multiple blockers preventing us from adopting the new Storage SDK (as mentioned above) - whilst we're working on a solution for this, unfortunately we don't have a timeline (which is why this is in the Blocked milestone).

[jungopro]

Good suggestion! Just tested it and I found a few issues with it...

• The "blob service-properties update" does not exist?
• When the provisioner is added to an existing resource, then the command is not executed. As the provisioner is run after creation...
• When the storage account was just deleted, then the following error occurs (so keep some "cooldown" time in mind) ;

• azurerm_storage_account.storage: Error creating Azure Storage Account "vmsnoozerdev": storage.AccountsClient#Create: Failure sending request: StatusCode=0 -- Original Error: autorest/azure: Service returned an error. Status=404 Code="StorageAccountNotFound" Message="The storage account vmsnoozerdev was not found."

• The "az login" part is quite key. Either do it (as the blog describes) via a prior build step, or within the command itself. Examply by using a service principal ;

resource "azurerm_storage_account" "storage" {
  name                     = "${var.prefix_workload}${var.prefix_environment}"
  resource_group_name      = "${azurerm_resource_group.storage.name}"
  location                 = "${azurerm_resource_group.storage.location}"
  account_tier             = "${var.storage_tier}"
  account_replication_type = "${var.storage_resiliency}"

  provisioner "local-exec" {
    command = "az login  --service-principal -u \"${var.armclientid}\" -p \"${var.armclientsecret}\" --tenant \"${var.armtenantid}\" | az storage blob service-properties update --account-name ${azurerm_storage_account.storage.name} --static-website  --index-document index.html --404-document 404.html"
  }
}

Hello @kvaes and @tombuildsstuff

I followed up on this and was able to successfully configure the storage account for website hosting.

Were you able to figure out a way to output the URL?
I know I can use the az cli for this as well as documented here but I was wondering if maybe this is already supported natively within the storage account resource in terraform...

Looking at the resource documentation I thought that maybe primary_blob_endpoint was the way to go but this is not the correct endpoint and I couldn't find anything else...

Any ideas?

Thanks
Omer

[hazzik]

Were you able to figure out a way to output the URL?

I'm using "data" "storage_account" "primary_web_endpoint" output attibute.

https://www.terraform.io/docs/providers/azurerm/d/storage_account.html#primary_web_endpoint

[jungopro]

Were you able to figure out a way to output the URL?

I'm using "data" "storage_account" "primary_web_endpoint" output attibute.

https://www.terraform.io/docs/providers/azurerm/d/storage_account.html#primary_web_endpoint

missed that. worked like a charm. thanks!

[StefanSchoof]

Since it looks like this can stay a while open, I created a module to wrap the at CLI command in a reusable way: https://registry.terraform.io/modules/StefanSchoof/static-website/azurerm

[tombuildsstuff]

Upstream issue: tombuildsstuff/giovanni#17

[WillAtHashicorp]

Hi there team. Just wondering if there's any progress on this?

[revelfire]

I'm using Terraform Cloud which does not have the az command available so the workarounds here won't do the job. My only option is to perhaps delegate to a secondary script run somewhere else (such as Azure Devops) which frankly sounds like a total headache and creates invalid state.

Any advice on a better workaround is welcome @WillAtHashicorp

I've tried for a little too long to get az cli working on TF Cloud but there's no standalone install I can pull and configure that'll work on the runner as far as I've been able to manage.

[GarethOates]

I too am eagerly awaiting progress on this issue. What's the latest?

[timja]

This is now unblocked, I added support for it to the upstream library in tombuildsstuff/giovanni#21
Which was released in 0.7.0

Thanks for the review @tombuildsstuff :)

[tombuildsstuff]

@timja thanks again for that PR - I'm going to open a PR shortly to vendor v0.7.0 into this Provider, at which point it should be possible for someone to take a look at this :)

[Paul2e]

Exciting news! Can't wait to use it! 👍

[a11smiles]

@tombuildsstuff So, when will this feature be added to the schema? It appears it was released in provider 1.39.0 but the schema hasn't been updated to allow the configuration.
(https://github.com/terraform-providers/terraform-provider-azurerm/blob/master/azurerm/internal/services/storage/resource_arm_storage_account.go)

[aqche]

Opened a PR to update the schema 👍

[ghost]

This has been released in version 2.0.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 = "~> 2.0.0"
}
# ... other configuration ...

[ghost]

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 👉 hashibot-feedback@hashicorp.com. Thanks!