Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support for Session Affinity in Azure Container Apps #24757

Open
1 task done
CocoDico78 opened this issue Feb 2, 2024 · 6 comments
Open
1 task done

Support for Session Affinity in Azure Container Apps #24757

CocoDico78 opened this issue Feb 2, 2024 · 6 comments

Comments

@CocoDico78
Copy link

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 and review the contribution guide to help.

Description

Session Affinity is GA since August 16, 2023.

I'd like to enable or disable Session Affinity in the ingress block of an azurerm_container_app with terraform, but I can't find anything in the docs.

New or Affected Resource(s)/Data Source(s)

azurerm_container_app

Potential Terraform Configuration

resource "azurerm_container_app" "example" {
  ## ...

  template {
    ## ...
  }

  ingress {
    target_port              = 80
    session_affinity_enabled = "true" ## <- this is the proposed additional option

    traffic_weight {
      percentage = 100
    }
  }
}

References

https://learn.microsoft.com/en-us/azure/container-apps/sticky-sessions
https://azure.microsoft.com/en-us/updates/generally-available-session-affinity-for-azure-container-apps/
https://registry.terraform.io/providers/hashicorp/azurerm/latest/docs/resources/container_app

@bPhysicist
Copy link
Contributor

bPhysicist commented Feb 5, 2024

I also ran into this issue.
The AzureRM provider is already using the 2023-05-01 version of the containerapps API which supports this feature. However, I would propose using the following syntax in order to be forward compatible with the Azure resource manager API.

resource "azurerm_container_app" "example" {
  #...
  template {
    ## ...
  }

  ingress {
    target_port              = 80
    sticky_sessions = { # New property
      affinity = "sticky"
    }
    traffic_weight {
      percentage = 100
    }
  }
}

Where affinity can only be "sticky" or "none" at the moment. This is compatible with the REST API and the go-azure-sdk. This way we can handle further sticky session settings in the future. For instance it is reasonable to assume that there will be more options for sticky_sessions in the future like duration specifications once containerapps evolve further.

I would love to implement this change and create a PR if this sounds reasonable.

Regards

bPhysicist added a commit to bPhysicist/terraform-provider-azurerm that referenced this issue Feb 9, 2024
bPhysicist added a commit to bPhysicist/terraform-provider-azurerm that referenced this issue Feb 9, 2024
bPhysicist added a commit to bPhysicist/terraform-provider-azurerm that referenced this issue Feb 9, 2024
@bPhysicist
Copy link
Contributor

I added the support in my commit here:
main...bPhysicist:terraform-provider-azurerm:feature/containerapps/sticky-sessions

However some post-test destorys are flaky for me (They work sometimes). For instance

make acctests SERVICE=containerapps TESTARGS='-run=TestAccContainerAppResource*' TESTTIM
EOUT='60m'

Runs inconsistently

=== CONT  TestAccContainerAppResource_withSystemAndUserAssignedIdentity
--- PASS: TestAccContainerAppResource_ipSecurityRulesUpdate (2300.96s)
=== CONT  TestAccContainerAppResource_completeVolumeEmptyDir
--- PASS: TestAccContainerAppResource_scaleRulesUpdate (2318.93s)
=== CONT  TestAccContainerAppResource_complete
=== NAME  TestAccContainerAppResource_completeWithMultipleContainers
    testing_new.go:90: Error running post-test destroy, there may be dangling resources: exit status 1
        
        Error: deleting Storage (Subscription: abc"
        Resource Group Name: "acctestRG-CAEnv-240209131900131862"
        Managed Environment Name: "acctest-CAEnv240209131900131862"
        Storage Name: "testacc-caes-240209131900131862"): managedenvironmentsstorages.ManagedEnvironmentsStoragesClient#Delete: Failure responding to request: StatusCode=400 -- Original Error: autorest/azure: Service returned an error. Status=400 Code="ManagedEnvironmentStorageDeleteInUse" Message="Cannot delete Managed environment storage 'testacc-caes-240209131900131862' because it's still in use."
        
        deleting Storage (Subscription: "abc"
        Resource Group Name: "acctestRG-CAEnv-240209131900131862"
        Managed Environment Name: "acctest-CAEnv240209131900131862"
        Storage Name: "testacc-caes-240209131900131862"):
        managedenvironmentsstorages.ManagedEnvironmentsStoragesClient#Delete: Failure
        responding to request: StatusCode=400 -- Original Error: autorest/azure:
        Service returned an error. Status=400
        Code="ManagedEnvironmentStorageDeleteInUse" Message="Cannot delete Managed
        environment storage 'testacc-caes-240209131900131862' because it's still in
        use."
--- FAIL: TestAccContainerAppResource_completeWithMultipleContainers (227.66s)

I can't consistently run the acceptance tests for containerapps for that reason (Even apart from my changes). Also I am running into total number of container_app_environment limits on my Azure account when I run the whole containerapp acceptance test suite.
I am trying to debug the issue above and appreciate ideas on why these post-destroys are flaky.

@CocoDico78
Copy link
Author

Is there any news on this?

@gaelgoth
Copy link

gaelgoth commented Jul 8, 2024

Workaround using azapi:

resource "azurerm_container_app" "example" {
  name                         = "ca-exemple"
  ...
  template {
    http_scale_rule {
      concurrent_requests = "10"
      name                = "http-scaler"
    }

    max_replicas = 1
    min_replicas = 10
  }

  ingress {
    allow_insecure_connections = false
    external_enabled           = true
    target_port                = "8080"
    transport                  = "auto"
    traffic_weight {
      percentage = 100
      latest_revision = true
    }
  }
}

# Patch Sticky sessions
resource "azapi_resource_action" "sticky_session" {
  type        = "Microsoft.App/containerApps@2023-11-02-preview"
  resource_id = azurerm_container_app.example.id
  method      = "PATCH"
  body = jsonencode({
    properties = {
      configuration = {
        ingress = {
          stickySessions = {
            affinity = "sticky"
          }
        }
      }
    }
  })

  depends_on = [
    azurerm_container_app.example,
  ]
}

@ffroliva
Copy link

ffroliva commented Jul 29, 2024

about this workaround what would be the else side of it? Let say you have a module with

variable "sticky_sessions_affinity" {
  description = "The sticky session affinity boolean to enable or disable sticky session."
  type        = bool
  default     = false
}
resource "azapi_resource_action" "sticky_session" {
  count = var.sticky_sessions_affinity ? [1] : [0]
  type        = "Microsoft.App/containerApps@2023-11-02-preview"
  resource_id = azurerm_container_app.example.id
  method      = "PATCH"
  body = jsonencode({
    properties = {
      configuration = {
        ingress = {
          stickySessions = {
            affinity = "sticky"
          }
        }
      }
    }
  })

  depends_on = [
    azurerm_container_app.container_app,
  ]
}

what value should affinity have if the var.sticky_sessions_affinity is false?

@gaelgoth
Copy link

@ffroliva Based on documentation; True is 'sticky' and False is 'none'.

https://learn.microsoft.com/en-us/azure/templates/microsoft.app/2023-11-02-preview/containerapps?pivots=deployment-language-bicep#ingressstickysessions

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

5 participants