Functions disappear from app after arm template deploy

[SanderDeclerck]

Investigative information

Please provide the following:

• Timestamp: 2022-03-02
• Function App version: 4
• Region: West-Europe

Repro steps

Provide the steps required to reproduce the problem:

1. Create a:
   • Linux function app in a consumption plan
   • Set WEBSITE_RUN_FROM_PACKAGE to 1
2. Deploy the code using Azure Pipelines (zip deploy)
   • This changes the WEBSITE_RUN_FROM_PACKAGE setting to https://{storage_account}/azure-pipelines-deploy/{package_name}?{SAS token}
3. Re-deploy the arm template

Expected behavior

The functions should still exist in the function app, and the function app should still work

Actual behavior

The setting WEBSITE_RUN_FROM_PACKAGE is reset to 1 and the functions disappear from the app.

[Ved2806]

Hi @SanderDeclerck , You can find the information related to your issue here. Please let us know if it helps.

[SanderDeclerck]

Thanks for looking into this @Ved2806.

I'm mainly concerned about 2 things that don't seem to be documented:

First: What would be a valid setting for WEBSITE_RUN_FROM_PACKAGE when someone only wants to deploy the infrastructure - and not his app?

• When setting the setting to '1', the function app stops working
• When no specifying the setting, it gets removed, and the function app stops working as well

Second: Since the setting is using a SAS token - with a maximum expiry date of a year. What happens if the app doesn't get deployed for a year and the SAS token expires?

---

I guess most of it comes down to the question: is the function team planning on implementing WEBSITE_RUN_FROM_PACKAGE = 1 for consumption based linux function apps some point in the future? Is there already an open issue for that?

[Ved2806]

Hi @pragnagopa Could you please look into this?

[pragnagopa]

This needs investigation. Tagging @eliaslopezgt @amamounelsayed @kulkarnisonia16 for triage

cc @balag0

[anirudhgarg]

Yes we are working on WEBSITE_RUN_FROM_PACKAGE=1 for Linux Consumption Apps

[SanderDeclerck]

@anirudhgarg Thanks for the update. Is there any issue I can follow to track the status of WEBSITE_RUN_FROM_PACKAGE=1 for Linux Consumption Apps?

Perhaps this issue can be linked to the WEBSITE_RUN_FROM_PACKAGE=1 so it can be closed.

[rstropek]

I have the same problem with Premium plan (EP1):

• Deploy Bicep template (with 'WEBSITE_RUN_FROM_PACKAGE': '1')
• Execute func azure functionapp publish ... -> everything works
• Deploy Bicep template again (e.g. adding another configuration setting) -> all functions are gone, function app does no longer work
• Execute func azure functionapp publish ... -> everything works again

What would be the correct workflow to update infrastructure using ARM/Bicep without losing the deployed function?

[bogedal]

I just hit this issue today - minor bicep change and my function went offline. Reason WEBSITE_RUN_FROM_PACKAGE was removed from app settings. Quite hard to set WEBSITE_RUN_FROM_PACKAGE from bicep since there are several .zip files in my blob storage :)

my to cents would be to leave WEBSITE_RUN_FROM_PACKAGE alone if not present in the bicep script

[grvillic]

I have the same problem with Premium plan (EP1):

• Deploy Bicep template (with 'WEBSITE_RUN_FROM_PACKAGE': '1')
• Execute func azure functionapp publish ... -> everything works
• Deploy Bicep template again (e.g. adding another configuration setting) -> all functions are gone, function app does no longer work
• Execute func azure functionapp publish ... -> everything works again

What would be the correct workflow to update infrastructure using ARM/Bicep without losing the deployed function?

Same here with EP2 plan, if I don't include the WEBSITE_RUN_FROM_PACKAGE in the second bicep deployment, function app starts returning 404s. If I set it to WEBSITE_RUN_FROM_PACKAGE=1 it stops working and returns 503s.

[pankajagrawal16]

I am facing similar issue too and ideally WEBSITE_RUN_FROM_PACKAGE should not be overridden until unless explicitly defined in arm template, although I do understand it will break the consistency.

So there should be a better way of solving this, but the current behavior is not desirable

[smthbh]

I'm using an EP plan, deploying the function from Bicep and then deploying the function code with a release pipeline without issue. What does your bicep file and release deployment step look like?

[piotrczyz]

I have the same problem after applying terraform configuration. It looks like it is similar problem.

I couldn't find any examples how to do it properly. The goal is to create azure functions with terraform (or arm template) and deploy code with github actions.

[jikuja]

Similar discussion within scope of Bicep templating here: https://github.com/Azure/bicep-registry-modules/issues/949

Retaining configuration values is possible but required extra templating and/or extra tools.

[pankajagrawal16]

This is a good workaround for until its fixed somehow in a different way https://stackoverflow.com/a/72946083/4479322. I just tried it in the app and works nicely.

[abouroubi]

Are there any news on this:

I guess most of it comes down to the question: is the function team planning on implementing WEBSITE_RUN_FROM_PACKAGE = 1 for consumption based linux function apps some point in the future? Is there already an open issue for that?

[JaroslawParadysz]

Are there any news?

[jikuja]

Is suggest subscribing also https://github.com/Azure/bicep-registry-modules/issues/949 for a reference. Sadly looks like the issue is being stalled on AVM too.

[abouroubi]

Yes we are working on WEBSITE_RUN_FROM_PACKAGE=1 for Linux Consumption Apps

It's been little bit less than 2 years and still no answer ? Was it an April fool's joke ?

[kurt-mueller-osumc]

I just want to bump this back up. I run into the same error when I run azd provision.

[fwilliamconceicao]

I can confirm this is still happen.

[Dev-Jams]

thats actually crazy, that after 2yrs there's no actual progress on this..

[obrys]

We are also affected. We use Terraform to maintain several Function apps. There was a change in the Application Insight connection string, so it made a minor change in that property of the Function apps. As a side effect, the value WEBSITE_RUN_FROM_PACKAGE was removed. The value contained the SAS URL of the ZIP package with the application.

The terraform plan did not show that change, but I was able to track it down in the Activity log.

Is there any progress here? Is there any cure for that? I am afraid of making any change in the infrastructure because it can silently remove my application from the Function app as a side effect.

[EverybodyKurts]

For those using Azure Bicep to provision infrastructure, a workaround I've used for myself is this:

https://blog.dotnetstudio.nl/posts/2021/04/merge-appsettings-with-bicep/

From the article's introduction:

While this is true for many of the Azure resources, it may not always be true for properties of ARM resources. A few examples are App Service App Settings (Configuration as it’s called in the Azure Portal) and Key Vault Access Policies. In these particular cases the last deployment replaces the complete set of app settings or access policies. This isn’t exactly what you would expect and certainly not what you’d want.

Basically, it merges any new settings you're implementing with the current settings of the app.

[rgrace-puck]

This behavior is absolutely insane, unsafe, and unexpected. We explicitly ignore the WEBSITE_RUN_FROM_PACKAGE setting in Terraform yet the underlying Azure resource decides to silently delete it when other settings are modified?

[jikuja]

This behavior is absolutely insane, unsafe, and unexpected. We explicitly ignore the WEBSITE_RUN_FROM_PACKAGE setting in Terraform yet the underlying Azure resource decides to silently delete it when other settings are modified?

Someone from ACA PG recommended me to open support ticket when I mentioned this issue on an interview.

Flexible consumption function app introduces some changes for function app config but TBH not enough. There should be dedicated sections for IaC driven configs and function app developer driven configs.