Terraform-provider-azurerm: Feature Request: Sticky AppSetting and ConectionStrings - azurerm_app_service, azurerm_app_service_slot

[kevinneufeld]

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

Add ability to set an AppSetting and ConnectionString as Sticky:

Currently, we are adding sticky AppSetting and ConnectionStrings via azurerm_template_deployment resource.

resource "azurerm_template_deployment" "sticky_test" {
  name                = "sticky_test"
  resource_group_name = "${azurerm_resource_group.test.name}"
  deployment_mode     = "Incremental"

  template_body = <<DEPLOY
{
  "$schema": "https://schema.management.azure.com/schemas/2015-01-01/deploymentTemplate.json#",
  "contentVersion": "1.0.0.0",
  "parameters": {
      "stickyConnectionStringsNames": {
        "type": "String"
      },
      "stickyAppSettingNames": {
        "type": "String"
      }
      "webAppName": {
          "type": "String"
      }
  },
  "variables": {
    "connectionStringNames": "[split(parameters('stickyConnectionStringsNames'),',')]",
    "appSettingNames": "[split(parameters('stickyAppSettingNames'),',')]"
  },
  "resources": [
      {
        "type": "Microsoft.Web/sites/config",
        "name": "[concat(parameters('webAppName'), '/slotconfignames')]",
        "apiVersion": "2015-08-01",
        "properties": {
          "connectionStringNames": "[variables('connectionStringNames')]",
          "appSettingNames": "[variables('appSettingNames')]"
        }
      }
  ]
}
DEPLOY

  parameters {
    "webAppName"                   = "${azurerm_app_service.msbx_api.name}"
    "webAppCustomHostname"         = "${cloudflare_record.api-cname.hostname}"
    "stickyConnectionStringsNames" = "DBContext"                                #"${join(",",distinct(list(azurerm_app_service.test.connection_string.0.name,azurerm_app_service_slot.test.connection_string.0.name)))}"
    "stickyAppSettingNames"        = "APPSETTING1,APPSETTING2,APPSETTING3"      #"${join(",",distinct(concat(keys(azurerm_app_service.test.app_settings),keys(azurerm_app_service_slot.test.app_settings))))}"
  }

  depends_on = [
    "azurerm_app_service.test",
    "azurerm_app_service_slot.test",
  ]
}

New or Affected Resource(s)

• azurerm_app_service
• azurerm_app_service_slot

Potential Terraform Configuration

Since the arm type targets Microsoft.Web/sites/config it initial makes sense for another argument on azurerm_app_service like sticky_settings or slot_config_names.

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 {
    dotnet_framework_version = "v4.0"
    scm_type                 = "LocalGit"
  }

  app_settings {
    "SOME_KEY1" = "some-value"
    "SOME_KEY2" = "some-value"
  }

  connection_string {
    name  = "Database"
    type  = "SQLServer"
    value = "Server=some-server.mydomain.com;Integrated Security=SSPI"
  }

   slot_config_names {
      app_settings = [
          "SOME_KEY1",
          "SOME_KEY2",
      ]
      connection_string = ["Database"]
  }
}

References

[perbergland]

I would prefer a syntax where the value and stickyness are set in one go instead of having it in two places.
This could be achieved by creating new sections that impose the stickyness and still allow you to set the values by precalculated hashes (for appsettings - no such luck for connection strings)

app_settings_sticky {
"SOME_KEY1" = "some-value"
}
...
app_settings_sticky = "${local.my_hash}"

[Stolpe]

It took me a while to find this feature request. Another term for this (which would have helped me finding this) is _slot setting_.

[gabrieljoelc]

We need this to be able to fully automate our production deployment. We don't currently use slots for non-production environments (it's more affordable and we don't need zero-downtime in non-prod environments). Since I cannot conditionally create/update a resource, I would have to create a slot resource for all non-production environments or exclude the target for all non-production environments (this is annoying since there is no --target-excluded switch).

If app setting slot flag setting was supported, I could set the flag to true every time for every environment regardless of if that environment had a slot setting.

I agree with @perbergland that it'd be nice to configure settings and slot flags together, but it'd be nice if it would be an optional value + flag format:

app_settings {
  Key1 = "value1"
  Key2 = ["value2", true]
}

I also agree with @Stolpe that the title of this issue should be updated to include "slot setting".

[gabrieljoelc]

A co-worker pointed out that I mis-read https://github.com/hashicorp/terraform/issues/15281#issuecomment-308275154. I assumed it was specific to that AWS resource when I couldn't find the count in the Azure App Service documentation, but it is in the general resource docs. This allowed me to have a conditional slot config which solved my problem and I don't need this feature. 😬

[Andreas-Lehmann]

is there any update on this?
Would love to see a native implementation of sticky slot settings in the azure terraform provider.

could look like this for connection strings (backward compatible, no breaking change):

  connection_string {
    name  = "Database"
    type  = "SQLServer"
    value = "Server=some-server.mydomain.com;Integrated Security=SSPI"
    deployment_slot_setting = "true" # optional with default "false"
  }

And this for app settings (backward compatible, no breaking change):

# keep plural element for key/value paired settings as is
 app_settings {
    "SOME_KEY1" = "some-value"
    "SOME_KEY2" = "some-value"
  }
# add new singular repeatable element (like connection_string)
  app_setting {
    name  = "MY_Key"
    value = "my value"
    deployment_slot_setting = "true" # optional with default "false"
  }

This would require an additional validation step to check for duplicate keys and throw an error if found.

[judgewest2000]

I'm guessing there's not been a massive amount of movement on this one?

[simondevolutions]

I would also like to see something like this implemented. We are looking to keep a short-lived pre-prod slot in order to be able to swap our new version without downtime, to prevent having to reprovision the same app settings on the slots, we would like to be able to enable sticky app settings on the production slot and swap with preview and then destroy the slot after the completed swap.

[vsawanny]

I am trying to enable specific app settings for stage and prod slots via terraform for App service .
Please let me know if this feature is enabled or not or please suggest if there is any alternative for the same
Thanks!

[shivanigoyaluk]

function_app_slot is available but it's of not much use as it doesn't have sticky app setting support. Is it going to available anytime soon?

https://www.terraform.io/docs/providers/azurerm/r/function_app_slot.html

[peter-dolkens]

@neil-yechenwei I saw you were active on some of the other azure provider support - any chance you know what's going on with this one?

[elliotchaim]

Any news on this? I think others would agree that this is fundamental functionality when leverage deployment slots and auto-swapping. By no means advanced usage, this is the type of limitation which prohibits some organisations from using terraform altogether.

[Jrc356]

If I could make a suggestion on this, I think it would be the most helpful if we could set sticky settings using the same api as defined now but with the option to provide a map of maps for the settings instead of just a map of strings. For example, if I just wanted to set app settings normally (without slot setting checked off), then it could be:

app_settings = {
  "some_setting" = "some value"
}

and if I wanted to make that sticky then I could change it to:

app settings = {
  {
    "name" = "some_setting"
    "value" = "some value"
    "slot_setting" = true
  }
}

I believe this lines up with how arm handles it as well so it's consistent across that and I would think this prevents breaking the original usage.

[Lucretius]

I took a look in the codebase and found that the Azure SDK representation looks most like the "slot_config_names" suggestion in the original issue.

I can work on a PR for this feature.

[akshaychopra5207]

@Lucretius and all When is this feature coming? any expected date?

[prashdevops2020]

@Lucretius Is this on the road map for this year or next quarter? Any update is appreciated. Thanks!