Reputation: 3581
I am trying to dockerize azure functions by using the official microsoft/azure-functions-node8
image. I could not find any documentation at all regarding configuring the runtime, and whenever I run the runtime the following errors occur:
The listener for function 'Functions.health' was unable to start.
Microsoft.Azure.WebJobs.Host.Listeners.FunctionListenerException: The listener for function 'Functions.health' was unable to start. ---> System.AggregateException: One or more errors occurred. (Microsoft Azure WebJobs SDK 'Storage' connection string is missing or empty. The Microsoft Azure Storage account connection string can be set in the following ways:
1. Set the connection string named 'AzureWebJobsStorage' in the connectionStrings section of the .config file in the following format <add name="AzureWebJobsStorage" connectionString="DefaultEndpointsProtocol=http|https;AccountName=NAME;AccountKey=KEY" />, or
2. Set the environment variable named 'AzureWebJobsStorage', or
3. Set corresponding property of JobHostConfiguration.)
I google some bits and pieces around and managed to compose the following .config
file, but the runtime still shouts at me.
<?xml version="1.0" encoding="utf-8"?>
<configuration>
<connectionStrings>
<add name="AzureWebJobsStorage" connectionString="myconnectionstring"/>
</connectionStrings>
</configuration>
Is .config
file format documented anywhere?
Upvotes: 3
Views: 955
Reputation: 17790
It was an old tip used to remind us default storage connection AzureWebJobsStorage
is not set correctly, which had been improved to be more intelligible long time ago. See this issue and its fix.
Looks like in docker image, this fix is omitted somehow.
To solve your problem, just set AzureWebJobsStorage
in your Dockerfile.
ENV AzureWebJobsStorage=DefaultEndpointsProtocol=https;AccountName=xxx;AccountKey=xxx==;EndpointSuffix=core.windows.net
Note that if you use name other than AzureWebJobsStorage
, it's required to set the connection
parameter using the name, in function.json
file.
Update
Based on Connor's comment, the fix I mentioned is added to cli tools, which docker image doesn't utilize, so we still see this original runtime error.
Upvotes: 3