Support for Logic App (Standard)

[jgrexa]

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

Logic App (Standard) is basically App Service with kind = "functionapp,workflowapp", should be very similar to azurerm_function_app resource.

New or Affected Resource(s)

• azurerm_logic_app

Potential Terraform Configuration

# Copy-paste your Terraform configurations here - for large Terraform configs,
# please use a service like Dropbox and share a link to the ZIP file. For
# security, you can also encrypt the files using our GPG public key.

References

• 0000

[rbev]

are the workflows/etc all published differently in logic app standard as well?

[ShahradGH]

Due to the parameters it can take on the portal for creation - and what can be configured vs the previous iteration - I would say yes. Links included below

The ARM Template comprises of the following resources:

Microsoft.Web/sites Microsoft.Web/sites/config Microsoft.Web/sites/deployments Microsoft.Web/sites/hostNameBindings

Microsoft.Web/sites

• difference between a functionapp/appservice and logicappstandard: "kind": "functionapp,workflowapp", That is if you select workflow, container I assume the template would alter slightly.

https://github.com/Azure/logicapps/tree/master/azure-devops-sample

More explainable reference here: https://techcommunity.microsoft.com/t5/azure-developer-community-blog/azure-logic-apps-announcement-ga-of-single-tenant-standard-sku/ba-p/2382460 https://docs.microsoft.com/en-us/azure/logic-apps/single-tenant-overview-compare

[dylanmorley]

Relevant to my interests. We've been working with Logic Apps over VNETs and wrapped an ARM template up as a terraform module - the ARM looks like so

https://gist.github.com/dylanmorley/21975d7959a688db0f11c627dd76d1d4

In particular, there are some settings and behaviours to be aware of when the application is part of a VNET,

• WEBSITE_CONTENTSHARE. Found we had to create this prior to creating the app, and pass the share in as a parameter. Otherwise, it will attempt to create the share itself and this failed with 403s

• WEBSITE_CONTENTOVERVNET / WEBSITE_VNET_ROUTE_ALL - lots of documentation on this, settings needed to route outbound through VNET

Also, we're then using managed identity from the workflow, so returning the system assigned principal is worth doing, so you can then perform [azurerm_role_assignment] with the generated identifier

Happy to get involved in this one - it's the last piece of my infrastructure that's still using ARM,

[dylanmorley]

Just looking at this, we could create a new resource i.e, azurerm_logic_app_standard, but feels we'd repeat a whole load of logic when logic app standard is actually a type of function app - it's implemented as an extension on top of Azure functions

From a resource perspective, would the preference always be to have a new resource + tests (& therefore a bit of duplication with function apps) as that gives clear usage when creating HCL?

Alternative, passing a parameter to the function_app resource that would allow to create a logic app type, allowing you to do the logic app specific work, e.g.?

if d.Get("enable_logic_app_workflows").(bool) {
  kind = "functionapp,workflowapp"
  appKindPropName := "APP_KIND"
  workflowAppKind := "workflowApp"

  logicAppStandardSettings := []web.NameValuePair{
    {Name: &appKindPropName, Value: &workflowAppKind},
  }
  basicAppSettings = append(basicAppSettings, logicAppStandardSettings...)
}

azurerm_logic_app_standard certainly feels clearer, but the amount of change needed in function app doesn't feel that large. Any thoughts on design approach @tombuildsstuff @katbyte ?

[dylanmorley]

Logic apps standard requires an APP_KIND setting creating, which has a value of workflowApp. Here's an example of using that parameter to control the creation

https://github.com/hashicorp/terraform-provider-azurerm/compare/main...dylanmorley:feature/logic-apps?expand=1

So to create a logic app resource, you'd just set APP_KIND in your settings block like so

resource "azurerm_function_app" "test" {
  name                       = "logic-app-standard"

  app_settings = {
    "APP_KIND" = "workflowApp"
  }  
}

Thoughts? This works and is a super simple change to support logic apps, but does it go against the overall design approach - is an explicitly named resource preferred?

[tombuildsstuff]

@dylanmorley FWIW the entirety of App Service is currently being reworked for 3.0 (see #12132) - as such whilst this'd likely make sense unfortunately at this time this is dependent on that work, which @jackofallops is working through at the moment

[dylanmorley]

Thanks @tombuildsstuff - am happy to create a totally new resource here.

Will be duplication out of the function_app resource into a new resource, but this will remove any coupling so no conflict with @jackofallops or any rework for 3.0. There's enough differences between them that this is warranted (i.e. logic app standard doesn't support deployment slots) & I can put this into the 'logic' package and remove all dependencies on web .

Shouldn't take long to put something together for this - let me know if you'd rather this was left alone until 3.0

[dylanmorley]

This was released @katbyte in 2.79

[tombuildsstuff]

Thanks for the heads up @dylanmorley, closing

[github-actions[bot]]

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 have found a problem that seems similar to this, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further.