Feature Request: Azure Functions

[tombuildsstuff]

Requested by @gondar

Looking into this - it appears these can live either within, or outside of an App Service Plan. As such I believe this functionality is blocked behind #1?

I've opened a Github issue on the Azure Rest API Specs repository asking for the Swagger to be added, so that we can generate the Go SDK / add this functionality.

[gondar]

👍

[nbering]

This is a pretty qualitative observation, but I've noted from early on that Azure Functions appears to be implemented in a very glued-on-after sort of way.

In the early releases, even the portal interface didn't look the same as the rest of the services. I suspect there's a lot of pieces sort of slapped together under the hood, so I don't expect this one will be easy to implement or use.

Just my opinion, no hard evidence to cite. There's a few things they've added in the last couple years though that feel like they were tacked onto multiple other services and don't stand very well on their own.

[tombuildsstuff]

@nbering if memory serves they're part of Kudu - but they should still be exposed as an ARM API given the functionality in the portal :)

[mjgpy3]

Can the non-app-service functions be implemented separately? Would they likely be separate resources or the same from a terraform perspective?

[tombuildsstuff]

👋 @mjgpy3

Can the non-app-service functions be implemented separately?

I've updated the issue on the Azure Rest API Specs repository to request support for both App Service Functions and non-App Service Functions :)

Would they likely be separate resources or the same from a terraform perspective?

It depends how the API's represented - based on my experience I'd guess they're separate API Endpoints - and thus would make sense as separate resources. However we're not going to know that for sure until the Swagger/Schema is published - which is requested in the issue above.

Either way I'll be sure to post an update to this once the Swagger's published :)

Thanks!

[benc-uk]

Function apps are created in ARM just like regular web apps, with the kind set to functionapp, that's the only real difference.

They require five extra app settings (under siteConfig.appSettings in ARM) configured in the app, some of which point to a storage account (which Function Apps require to operate) these settings are AzureWebJobsDashboard, AzureWebJobsStorage, WEBSITE_CONTENTAZUREFILECONNECTIONSTRING, WEBSITE_CONTENTSHARE and FUNCTIONS_EXTENSION_VERSION

Functions can be deployed into a regular App Service plan or into a special consumption based one, either way the App Service Plan resource still requires creating. Consumption plans are special they use a different SKU as follows:

"name": "Y1",
"tier": "Dynamic",
"capacity": 0

Creating Function Apps with ARM is trivially easy, I have an example on my GitHub: https://github.com/benc-uk/azure-arm/tree/master/paas-other/function-app-withcode

Hope that helps, I'm very familiar with both ARM and Functions/App Services so I'm happy to help here

[anoff]

hey @tombuildsstuff is the info from Ben helpful in pushing this feature forward? I am pretty new to TF so I don't know if ARM syntax helps at all..

[tombuildsstuff]

👋 hey everybody!

Support for creating Function Apps has been added in #647 which will ship as part of v1.0.1 of the Azure Provider (which should be released tomorrow) :)

Thanks!

[dcherniv]

To resurrect this issue.
Is there an easy way to add site_config section to function_apps, in the same manner as it is done for azurerm_app_service?

[tombuildsstuff]

@dcherniv this has been initially added in #695 - would you mind opening a separate issue if there's other fields you require?

Thanks!

[ghost]

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 👉 hashibot-feedback@hashicorp.com. Thanks!