Azure-webjobs-sdk: Feature: Ability to configure storage account dynamically

Created on 27 Jun 2019  路  4Comments  路  Source: Azure/azure-webjobs-sdk

In the .NET Framework version of the Webjobs SDK we can do something like this:

var storageConnectionString = code that returns a connection string
var config = new JobHostConfiguration(storageConnectionString)
var host = new JobHost(config);

The only way to configure this using the .net core Webjobs SDK version 3.0.10 is by adding this to the appsettings.json with a structure that matches:

"ConnectionStrings": {
"AzureWebJobsStorage": "connectionstring",
},

I'm running a webjob and I want to get the storage credentials from the new Azure App Configuration Service (https://docs.microsoft.com/en-us/azure/azure-app-configuration/overview).

Currently, I don't know how to explicitly set the storage connection string.

Known workarounds

I found a workaround using the following:

// ConfigureWebJobs already adds the appsettings.json file configuration. 
var host = new HostBuilder()
            .ConfigureWebJobs(x =>
            {
                x.AddAzureStorageCoreServices();
                x.AddAzureStorage();
            })
            .ConfigureAppConfiguration((hostingContext, config) =>
            {
                // Adding config from Azure App Configuration
                var settings = config.Build();
                var appConfigConnection = settings["ConnectionStrings:AppConfig"];
                config.AddAzureAppConfiguration(appConfigConnection);
                // For AzureWebjobs to work, lets add an InMemoryCollection with the proper format
                settings = config.Build();
                var webjobConfigDictionary = new Dictionary<string, string>
                {
                    { "ConnectionStrings:AzureWebJobsStorage", settings["AzureStorageSettings:ConnectionString"] }
                };
                config.AddInMemoryCollection(webjobConfigDictionary);
            })

Adding an InMemoryCollection with the proper convention makes this work, but a way to set it up explicitly would be really helpful.

Feel free to request more information on this, will be more than happy to assist. Thanks!

Most helpful comment

This needs some review. We don't properly expose the Options that we use to configure the internal services with storage. I was going to suggest adding an IConfigureOptions -- but that's not available to you.

All 4 comments

This needs some review. We don't properly expose the Options that we use to configure the internal services with storage. I was going to suggest adding an IConfigureOptions -- but that's not available to you.

A bit dated, but the only post I could find covering the issue I face upgrading from WJSDK 2 to 3.

Was running into issues as well, but was able to get it working with the following:

var builder = new HostBuilder()
    .UseEnvironment(_config.Env)
    .ConfigureWebJobs(b =>
    {
        b.AddAzureStorageCoreServices();
        b.AddAzureStorage();
    })
    .ConfigureAppConfiguration(b => b.AddConfiguration(_configuration))
    .ConfigureServices(services => ConfigureAppServices(services))
    .UseConsoleLifetime();

We use multiple Azure Config Service resources in our environment and apply hierarchically, i.e. appsettings.json, then the global config, then the app config. The _configuration object is an IConfiguration provided to AddConfiguration() has already been setup.

Not sure this is the most elegant, but it seems to be working as expected.

This is kind of ridiculous that we cant set a connection string unless we use a crummy json file, and that it has survived this long without being fixed. This has pretty much solidified never moving to the v3 SDK unless there is something worth moving for (like Webjobs v3 dont mysteriously stop logging for days, or the logging for them is not so hard to read).

@StingyJack -- can you share what you'd like to accomplish? You don't need any json files -- you can add whatever configuration you want using ConfigureAppConfiguration(). This issue is to make that a little bit easier by adding an explicit IOptions<> class that you can configure. But it's still possible by reading the config from anywhere you want.

Was this page helpful?
0 / 5 - 0 ratings

Related issues

christopheranderson picture christopheranderson  路  3Comments

fwd079 picture fwd079  路  5Comments

kamranayub picture kamranayub  路  4Comments

sergey-netdev picture sergey-netdev  路  5Comments

shibayan picture shibayan  路  5Comments