Using Terraform v0.12.8
provider "azurerm" {
version = "=1.34.0"
}
azurerm_app_serviceresource "azurerm_app_service_plan" "web_asp" {
name = "${local.prefix}-${local.service}-${var.location_short}-asp"
location = "${azurerm_resource_group.web_rg.location}"
resource_group_name = "${azurerm_resource_group.web_rg.name}"
kind = "Windows"
sku {
tier = "Standard"
size = "S2"
}
tags = merge(
local.default_tags
, map("Resource", "web_asp")
)
}
resource "azurerm_app_service" "web_service" {
count = "${length(local.web_app_names)}"
name = "${local.prefix}-${local.service}-${var.location_short}-${local.web_app_names[count.index]}"
location = "${azurerm_resource_group.web_rg.location}"
resource_group_name = "${azurerm_resource_group.web_rg.name}"
app_service_plan_id = "${azurerm_app_service_plan.web_asp.id}"
https_only = true
enabled = true
site_config {
dotnet_framework_version = "v4.0"
virtual_network_name = "${local.vnet}"
min_tls_version = "1.2"
always_on = true
ip_restriction {
virtual_network_subnet_id = "${azurerm_subnet.web_internal_sub.id}"
}
}
logs {
http_logs {
file_system {
retention_in_days = 30
retention_in_mb = 100
}
}
}
tags = merge(
local.default_tags
, map("Resource", "web_service")
)
}
I would expect that this configuration would add the azure app service resource to the VNet specified in "site_config.virtual_network_name" and the subnet specified in "site_config.ip_restriction.virtual_network_subnet_id".
Then all app restrictions from external IPs and internal subnets can be managed by the network security group attached to the specified subnet.
No errors are generated, although in Azure under the "Settings/Networking/VNet Integration" section of the app service there is no configured VNet.
terraform applyThe ip restrictions for a VNet are not the same as a VNet integration. The ip restriction are saying "only allow traffic from the VNet", while the VNet integration allows the app service to access resoruces inside the VNet.. Note: You cannot add an app service to a VNet unless you are using an App Service Environment.
I'm not sure this if the expected behavior is correct.
Thanks for the clarification @edboykin-insight although ASEs seem to be blocked to be added to Terraform and have to be done through ARM templates
Thanks @hbuckle - I look forward to V1.35.0!
@edboykin-insight You can add an app service to a VNet without using an App Service Environment. Even though the feature is in preview and have some restrictrions to it: https://docs.microsoft.com/en-us/azure/app-service/web-sites-integrate-with-vnet
I'm running into similar problem with the association of the virtual network, more based on that the https://www.terraform.io/docs/providers/azurerm/r/app_service.html#virtual_network_name. When setting the name for the virtual_network_name in our code it doesn't connect to the actual network name. No error messages are given, Terraform behaves as it's applied as it should.
If I manually add the VNET to the app service and run terraform plan again. It shows a GUID name that are not equal to the virtual_network_name. Seems like its a GUID_
Terraform (and AzureRM Provider) Version
provider "azurerm" {
version = "~> 1.34"
}
Affected Resource(s)
Terraform Configuration Files
module "webapp_backend" {
source = "git@"
identifier = var.identifier
azurerm_resource_group_name = azurerm_resource_group.rg.name
azurerm_resource_group_location = var.location
environment = var.environment
systemid = var.systemid
systemnickname = var.systemnickname
component = "webapp"
deftags = local.deftags
rgtags = local.rgtags
prefix = local.prefix
saprefix = local.saprefix
#module specific parameters
service_plan_kind = var.service_plan_kind
reserved = var.reserved
capacity = var.capacity
tier = var.tier
service_plan_size = var.service_plan_size
linux_fx_version = var.linux_fx_version
java_version = var.java_version
java_container = var.java_container
java_container_version = var.java_container_version
dotnet_framework_version = var.dotnet_framework_version
slot = var.slot
virtual_network_name = var.virtual_network_name
auth_settings_enabled = var.auth_settings_enabled
}
Expected Behavior
I would expect that this configuration would add the azure app service resource to the VNet specified in var.virtual_network_name
Actual Behavior
No errors are generated, although in Azure under the "Settings/Networking/VNet Integration" section of the app service there is no configured VNet. If I add the VNET manually and then run terraform apply it will generate a change:
~ site_config {
- virtual_network_name = "3cb0ff8b-5225-478f-baf4-a3d153bXXXXX_AppService" -> "var.virtual_network_name"
}
}
Plan: 0 to add, 1 to change, 0 to destroy.
Steps to Reproduce
Reference
@SebRosander attaching App Services which aren't in an App Service Environment to a Virtual Network's gone through a few iterations on the Azure end unfortunately.
After chatting with the service team a while back it appears that the virtual_network_name field exposed in the API is a previous integration attempt which was really only available through the Kudu API's, which has since been superseded by a new integration method which is being added in https://github.com/terraform-providers/terraform-provider-azurerm/pull/4250 which I believe should resolve this
Thanks!
Thanks for clarifying @tombuildsstuff
This has been released in version 1.40.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.40.0"
}
# ... other configuration ...
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!
Most helpful comment
@SebRosander attaching App Services which aren't in an App Service Environment to a Virtual Network's gone through a few iterations on the Azure end unfortunately.
After chatting with the service team a while back it appears that the
virtual_network_namefield exposed in the API is a previous integration attempt which was really only available through the Kudu API's, which has since been superseded by a new integration method which is being added in https://github.com/terraform-providers/terraform-provider-azurerm/pull/4250 which I believe should resolve thisThanks!