Search code examples
azure-functionsazure-web-app-servicezipdeploy

Trying to use WEBSITE_RUN_FROM_PACKAGE = 1 but ZipDeploy failed with [IOException]: The user name or password is incorrect


My team has FunctionApps running in an Elastic Premium plan. By default, these functions run using Azure Files for storage, but we are trying to run our functions from a package file, so we avoid this dependency.

I'm following this documentation: https://learn.microsoft.com/en-us/azure/azure-functions/run-functions-from-deployment-package#general-considerations

I added WEBSITE_RUN_FROM_PACKAGE = 1 and removed WEBSITE_CONTENTAZUREFILECONNECTIONSTRING/WEBSITE_CONTENTSHARE from the appsettings. I also updated the deployment template to use ZipDeploy instead of MSDeploy. Our deployment happens in two stages, first we deploy the resources (plan, functionapp...) and then we deploy the code (ZipDeploy).

Now, deployment is successful in one of our environments, but for the other one we can deploy the function app with correct appsettings but ZipDeploy fails with: IOException: The user name or password is incorrect. What is weird because the two function apps have exactly the same configuration.

Here is the full error message:

Status: Failed
Error:
Code: TooManyRequests
Message: [IOException]: The user name or password is incorrect.

at System.IO.__Error.WinIOError(Int32 errorCode, String maybeFullPath)
at System.IO.Directory.InternalCreateDirectory(String fullPath, String path, Object dirSecurityObj, Boolean checkHost)
at System.IO.Directory.InternalCreateDirectoryHelper(String path, Boolean checkHost)
at System.IO.Abstractions.DirectoryWrapper.CreateDirectory(String path)
at Kudu.Core.Infrastructure.FileSystemHelpers.EnsureDirectoryIgnoreAccessExceptions(String path)
at Kudu.Services.Web.App_Start.NinjectServices.GetSettingsPath(IEnvironment environment) in C:\__w\1\s\Kudu.Services.Web\App_Start\NinjectServices.cs:line 828
at Kudu.Services.Web.App_Start.NinjectServices.EnsureValidDeploymentXmlSettings(IEnvironment environment) in C:\__w\1\s\Kudu.Services.Web\App_Start\NinjectServices.cs:line 0
at Kudu.Services.Web.App_Start.NinjectServices.RegisterServices(IKernel kernel) in C:\__w\1\s\Kudu.Services.Web\App_Start\NinjectServices.cs:line 157
at Kudu.Services.Web.App_Start.NinjectServices.CreateKernel() in C:\__w\1\s\Kudu.Services.Web\App_Start\NinjectServices.cs:line 132
at Ninject.Web.Common.Bootstrapper.Initialize(Func`1 createKernelCallback)
at Kudu.Services.Web.App_Start.NinjectServices.Start() in C:\__w\1\s\Kudu.Services.Web\App_Start\NinjectServices.cs:line 97
[TargetInvocationException]: Exception has been thrown by the target of an invocation.
at System.RuntimeMethodHandle.InvokeMethod(Object target, Object[] arguments, Signature sig, Boolean constructor)
at System.Reflection.RuntimeMethodInfo.UnsafeInvokeInternal(Object obj, Object[] parameters, Object[] arguments)
at System.Reflection.RuntimeMethodInfo.Invoke(Object obj, BindingFlags invokeAttr, Binder binder, Object[] parameters, CultureInfo culture)
at WebActivatorEx.BaseActivationMethodAttribute.InvokeMethod()
at WebActivatorEx.ActivationManager.RunActivationMethods[T](Boolean designerMode)
at WebActivatorEx.ActivationManager.Run()
[InvalidOperationException]: The pre-application start initialization method Run on type WebActivatorEx.ActivationManager threw an exception with the following error message: Exception has been thrown by the target of an invocation..
at System.Web.Compilation.BuildManager.InvokePreStartInitMethodsCore(ICollection`1 methods, Func`1 setHostingEnvironmentCultures)
at System.Web.Compilation.BuildManager.InvokePreStartInitMethods(ICollection`1 methods)
at System.Web.Compilation.BuildManager.CallPreStartInitMethods(String preStartInitListPath, Boolean& isRefAssemblyLoaded)
at System.Web.Compilation.BuildManager.ExecutePreAppStart()
at System.Web.Hosting.HostingEnvironment.Initialize(ApplicationManager appManager, IApplicationHost appHost, IConfigMapPathFactory configMapPathFactory, HostingEnvironmentParameters hostingParameters, PolicyLevel policyLevel, Exception appDomainCreationException)
[HttpException]: The pre-application start initialization method Run on type WebActivatorEx.ActivationManager threw an exception with the following error message: Exception has been thrown by the target of an invocation..
at System.Web.HttpRuntime.FirstRequestInit(HttpContext context)
at System.Web.HttpRuntime.EnsureFirstRequestInit(HttpContext context)
at System.Web.HttpRuntime.ProcessRequestNotificationPrivate(IIS7WorkerRequest wr, HttpContext context)

Also, if I try KUDO: kudo

I tried to redeploy but no luck.

Did anyone face the same issue trying to use WEBSITE_RUN_FROM_PACKAGE = 1 and have a solution for the problem?


Solution

  • For more context, we were trying to use WEBSITE_RUN_FROM_PACKAGE = 1 because we want to get rid of WEBSITE_CONTENTAZUREFILECONNECTIONSTRING and WEBSITE_CONTENTSHARE.

    That is possible, accordingly to https://learn.microsoft.com/en-us/azure/azure-functions/storage-considerations?tabs=azure-cli

    If the above are properly accounted for, you could create the app without Azure Files. Create the function app without specifying the WEBSITE_CONTENTAZUREFILECONNECTIONSTRING and WEBSITE_CONTENTSHARE application settings. You can avoid these settings by generating an ARM template for a standard deployment, removing the two settings, and then deploying the template.

    I ended up finding the solution of my problem here: https://github.com/projectkudu/kudu/wiki/WEBSITE_RUN_FROM_PACKAGE-and-WEBSITE_CONTENTAZUREFILECONNECTIONSTRING-Best-Practices

    Best Practice

    It is strongly recommended that this setting to be set at app creation time and immutable thru out the lifetime of an app. In fact, there is no scenario that one would need to change this setting occasionally or especially during deployment. Modifying this will cause the deployment and app runtime to behavior incorrectly, guaranteed downtime and data loss perception (deployed files are not where they are expected) - imagine swapping a hard drive while installing a software to a computer.

    TL;DR -> Deleting the resources before redeploying them with the new setting (WEBSITE_RUN_FROM_PACKAGE = 1) fixed the problem.