Terraform v0.11.10
provider.azurerm v1.22.1
azurerm_app_service_planApp service plan should allow multiple values in kind option:
kind = "functionapp,linux"
this would reflect the behaviour of the ARM templates. Currently it is impossible to create consumption linux plan for functions.
I've been trying to create a linux functionapp with Terraform recently. It's been frustrating 馃槀
As an experiment I created the functionapp manually through the webconsole and then imported the azurerm_app_service_plan and azurerm_function_app so that I could inspect the differences with what terraform was creating.
I believe that the azurerm_app_service_plan.kind should remain as functionapp and the azurerm_function_app.kind field should be allowed to change to functionapp,linux somehow.
Check it out:
$ terraform show
# azurerm_app_service_plan.linuxapptest:
resource "azurerm_app_service_plan" "linuxapptest" {
id = "..."
kind = "functionapp" <-- Still just a functionapp plan
location = "westus"
maximum_number_of_workers = 0
name = "..."
per_site_scaling = false
reserved = true
resource_group_name = "..."
properties {
per_site_scaling = false
reserved = true
}
sku {
capacity = 0
size = "Y1"
tier = "Dynamic"
}
}
# azurerm_function_app.linuxapptest:
resource "azurerm_function_app" "linuxapptest" {
app_service_plan_id = "..."
app_settings = {
"FUNCTIONS_WORKER_RUNTIME" = "python"
"WEBSITE_NODE_DEFAULT_VERSION" = "10.14.1"
}
client_affinity_enabled = false
default_hostname = "....azurewebsites.net"
enable_builtin_logging = false
enabled = true
https_only = false
id = "..."
kind = "functionapp,linux" <-- This seems to be where the magic happens
location = "westus"
name = "..."
outbound_ip_addresses = "..."
possible_outbound_ip_addresses = "..."
resource_group_name = "..."
site_credential = [
{
password = "..."
username = "..."
},
]
storage_connection_string = (sensitive value)
version = "~2"
site_config {
always_on = false
use_32_bit_worker_process = true
websockets_enabled = false
}
}
...
It looks like the azurerm_function_app.kind field is hard-coded. I'm going to try and introduce a new argument azure_function_app.linux that, when true, will result in ,linux being appended to the kind field. This might be less flexible that allowing people to set the kind field directly but it will introduce less opportunities to mess things up too.
I was going crazy trying to get this to work as well. I'm wondering if it's a documentation issue or if it's because consumption plans for Linux just became GA, but it looks like if you set reserved = true and the sku to Y1 on the app service plan, it creates a Linux app service plan that you can deploy Linux consumption based functions to. This is my configuration that seems to work:
resource "azurerm_app_service_plan" "function_app_plan" {
name = "..."
location = "..."
resource_group_name = "..."
kind = "FunctionApp"
reserved = true
sku {
tier = "Dynamic"
size = "Y1"
}
}
resource "azurerm_function_app" "test" {
name = "..."
location = "..."
resource_group_name = "..."
app_service_plan_id = azurerm_app_service_plan.function_app_plan.id
storage_connection_string = "..."
version = "~2"
https_only = true
enabled = true
app_settings = {
FUNCTIONS_WORKER_RUNTIME = "python"
}
}
Most helpful comment
I've been trying to create a linux functionapp with Terraform recently. It's been frustrating 馃槀
As an experiment I created the functionapp manually through the webconsole and then imported the
azurerm_app_service_planandazurerm_function_appso that I could inspect the differences with what terraform was creating.I believe that the
azurerm_app_service_plan.kindshould remain asfunctionappand theazurerm_function_app.kindfield should be allowed to change tofunctionapp,linuxsomehow.Check it out:
It looks like the
azurerm_function_app.kindfield is hard-coded. I'm going to try and introduce a new argumentazure_function_app.linuxthat, whentrue, will result in,linuxbeing appended to thekindfield. This might be less flexible that allowing people to set thekindfield directly but it will introduce less opportunities to mess things up too.