terraform-provider-azurerm: azurerm_container_app - Cannot deploy container with ingress enabled
Is there an existing issue for this?
- I have searched the existing issues
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
Terraform Version
1.3.8
AzureRM Provider Version
3.43.0
Affected Resource(s)/Data Source(s)
azurerm_container_app
Terraform Configuration Files
# this is just the example script taken from https://registry.terraform.io/providers/hashicorp/azurerm/latest/docs/resources/container_app with the "ingress"-block added
terraform {
required_providers {
}
}
provider "azurerm" {
features {}
}
resource "azurerm_resource_group" "example" {
name = "example-resources"
location = "West Europe"
}
resource "azurerm_log_analytics_workspace" "example" {
name = "acctest-01"
location = azurerm_resource_group.example.location
resource_group_name = azurerm_resource_group.example.name
sku = "PerGB2018"
retention_in_days = 30
}
resource "azurerm_container_app_environment" "example" {
name = "Example-Environment"
location = azurerm_resource_group.example.location
resource_group_name = azurerm_resource_group.example.name
log_analytics_workspace_id = azurerm_log_analytics_workspace.example.id
}
resource "azurerm_container_app" "example" {
name = "example-app"
container_app_environment_id = azurerm_container_app_environment.example.id
resource_group_name = azurerm_resource_group.example.name
revision_mode = "Single"
template {
container {
name = "examplecontainerapp"
image = "mcr.microsoft.com/azuredocs/containerapps-helloworld:latest"
cpu = 0.25
memory = "0.5Gi"
}
}
ingress {
external_enabled = true
target_port = 80
traffic_weight {
percentage = 100
}
}
}
Debug Output/Panic Output
azurerm_container_app.example: Still creating... [9m50s elapsed]
azurerm_container_app.example: Still creating... [10m0s elapsed]
azurerm_container_app.example: Still creating... [10m10s elapsed]
azurerm_container_app.example: Still creating... [10m20s elapsed]
╷
│ Error: creating Container App (Subscription: "7eac1563-570f-4dc5-bcc0-2f057ad0cff0"
│ Resource Group Name: "example-resources"
│ Container App Name: "example-app"): polling after CreateOrUpdate: Code="ContainerAppOperationError" Message="Failed to provision revision for container app 'example-app'. Error details: Operation expired."
│
│ with azurerm_container_app.example,
│ on main.tf line 31, in resource "azurerm_container_app" "example":
│ 31: resource "azurerm_container_app" "example" {
│
│ creating Container App (Subscription: "7eac1563-570f-4dc5-bcc0-2f057ad0cff0"
│ Resource Group Name: "example-resources"
│ Container App Name: "example-app"): polling after CreateOrUpdate: Code="ContainerAppOperationError" Message="Failed to provision revision for container app 'example-app'. Error details: Operation expired."
Expected Behaviour
Container App should be successfully provisioned and be publicly reachable using the FQDN
Actual Behaviour
- Creation of the Container App times out after ~10 minutes.
- Looking at the Portal, the Container App is created but no container is inside.
- Terraform is in a state where it doesn`t know about the already created ContainerApp and cannot even destroy any more (manual cleanup necessary)
Steps to Reproduce
just apply the config above and wait for it to timeout 😃
Important Factoids
No response
References
No response
About this issue
- Original URL
- State: open
- Created a year ago
- Reactions: 65
- Comments: 33 (4 by maintainers)
Commits related to this issue
- FIX: #20435 — committed to jarpsimoes/terraform-provider-azurerm by jarpsimoes a year ago
Hi all,
I can confirm the bug with the configuration stated above. However I was experimenting with some more properties on the ingress and I could manage to get it working with this ingress block:
Befor this setup I only provided the required parameters as in @ggeorgovassilis configuration above. After adding latest_revision parameter it suddenly started working again. Also creation was very fast, 4:50 minutes for the environment and just 16 seconds for each container app.
Same here, to be more precise, in my case, a creation without the ingress part works. And after that if you update your container app with an ingress it works too (no timeout). Timeout occurs when you send for the first time a definition with an ingress.
This should definitely NOT be closed. Latest_revision should not be required to be true - this is a hack. There is a clear bug in the code where the revision suffix is not getting set correctly.
Thanks for taking the time to submit this issue. It looks like this has been resolved as of the suggestion of
latest_revision = true
in theingress
block making it work. As such, I am going to mark this issue as closed.can also confirm this works with traffic_weight block set to:
I can confirm setting
last_revision = true
fixes the above timeout issue for me.Today when I’ve returned to this it’s all working, I’m assuming the “context deadline exceeded” was a temporary issue and adding
latest_revision = true
has solved the issuewow… I have been fighting with some problme from about 4 days now…
I think there are still different problems with this kind of resource… I confirm all has been said and I add a new problem I thought was about VS 2022 but now I think it is about the terraform module.
I cannot deploy my projet in the app container form VS 2022… I get the error
Failed to push the docker image to your azure container registry for use in your azure container app
.But, the image is correctly deployed to the registry but it is not used in the app container.
In fact I can deploy with no problem the image only to the container registry, and I can deploy with no problem to an app container I created manually… only I cannot deploy to the container app created with terraform.
Anyone has the same problem? How do you solve it?
Can also confirm that this issue is happening because of the
ingress
block. Big thanks to @trichling for sharing the fix withlatest_revision = true
.setting latest_revision = true also resolved the issue for me
Thank you for the clarification @stewartbeck. I have reopened this issue. I appreciate the quick response.
Adding a bit more context: Setting LatestRevision = true works and allows it to successfully set the traffic to 100%.
Looking into the code at in the helpers/container_apps.go you see:
if !v.LatestRevision { traffic.RevisionName = pointer.To(fmt.Sprintf("%s--%s", appName, v.RevisionSuffix)) }
that is why setting latest revision works. Seems the client isnt correctly populating the RevisionSuffix after it gets generated.
I can confirm that i’m seeing the behavior. From the logs i see that when it tries to assign the traffic weight, it’s not including the revision hash so it fails trying to find the revision.
If you remove the ingress it’ll succeed in creation. Then you can modify the terraform and put the ingress back and this time it succeeds, but updating the traffic percentage to 100 will still fail.
Here is a screen cap of the logs when it fails:
I got the same issue, with revision mode set to Multiple I do see the container deployed in the Azure Portal, still the revision status is stuck on “In Progress” and terraform timeouts:
I can also confirm the same findings - creation in two steps (without ingress then adding) is fast ~20-30s in all cases, but creating with ingress enabled leads to timeout after around 10-15mins and deployment failure usually with revision ‘unknown’ as the status and the whole azure container apps ui is somewhat unresponsive until the app is deleted. On some occasions I had to delete the app via CLI as the portal wouldn’t load the app state.
This was on a new empty container apps env (created ~1hr previous) and the container apps env had VNET integration via the infrastructure_subnet_id property.
Can confirm what @jpinsolle-betclic wrote. Also these timings may be of interest:
Apart from that i noticed the following (maybe related, maybe different error): When the Container App is up and running with the ingress activated (following @jpinsolle-betclic s procedure), every following “terraform apply” will update the already existing app despite no changes to the terraform code have been made:
This is not the case when the AzApi-provider is used
@ggeorgovassilis: you wrote that “The first fails with a timeout (although the resource is created fine)” - is there really a running container inside your Container App that is reachable from “outside”? The resource itself looks fine for me also at first glance, but in reality doesn`t run anything…
it is not clear to me why if
revision_mode = "Single"
thetraffic_weight
block is mandatory in the Terraform provider.However, when creating a Container App with the portal, inspecting the json object I see:
It seems the traffic block with
latestRevision: true
is there by default in the object created by the portalCc: @lonegunmanb @jiaweitao001
@trichling thanks, that works. @andmos does “… and then adding the block” mean two deployments? For me it worked with a single deployment with the simple change Tobias proposed.
@btbaetwork I spoke hastily and with little knowledge. In fact, the container is created but ingres returns 404.