Почему TimerTrigger не запрашивает учетную запись хранилища в хост-приложении basic WebJobs SDK v3?

#c# #azure #azure-webjobs #azure-webjobssdk

#c# #azure #azure-webjobs #azure-webjobssdk

Вопрос:

Я играю с WebJobs SDK v3.0.5, используя очень простой консольный проект .NET Core 2.2 следующим образом:

TimerHost.csproj

 <Project Sdk="Microsoft.NET.Sdk">
  <PropertyGroup>
    <OutputType>Exe</OutputType>
    <TargetFramework>netcoreapp2.2</TargetFramework>
    <LangVersion>7.1</LangVersion>
  </PropertyGroup>

  <ItemGroup>
    <PackageReference Include="Microsoft.Azure.WebJobs" Version="3.0.5" />
    <PackageReference Include="Microsoft.Azure.WebJobs.Extensions" Version="3.0.2" />
    <PackageReference Include="Microsoft.Extensions.Logging.Console" Version="2.2.0" />
  </ItemGroup>

  <ItemGroup>
    <None Update="appsettings.json">
      <CopyToOutputDirectory>Always</CopyToOutputDirectory>
    </None>
  </ItemGroup>
</Project>
  

Program.cs

 using System.Threading.Tasks;
using Microsoft.Azure.WebJobs;
using Microsoft.Extensions.DependencyInjection;
using Microsoft.Extensions.Hosting;
using Microsoft.Extensions.Logging;

namespace TimerHost
{
    public class Program
    {
        public static async Task Main()
        {
            var builder = new HostBuilder();
            var host = builder
                .UseEnvironment("Development")
                .ConfigureServices((context, services) =>
                {
                    services.AddSingleton(context.Configuration);
                })
                .ConfigureWebJobs(webJobsBuilder =>
                {
                    webJobsBuilder
                        .AddAzureStorageCoreServices()
                        .AddTimers();
                })
                .ConfigureLogging((context, b) =>
                {
                    b.SetMinimumLevel(LogLevel.Debug);
                    b.AddConsole();
                })
                .UseConsoleLifetime()
                .Build();

            await host.RunAsync();
        }
    }

    public static class Function
    {
        public static void Run([TimerTrigger("*/10 * * * * *")] TimerInfo timer, ILogger logger)
        {
            logger.LogInformation($"Running job for timer. Next 3 runs are: {timer.FormatNextOccurrences(3)}");
        }
    }
}
  

appsettings.json

 {
}
  

Триггер выполняется нормально. Однако, согласно последним документам (https://learn.microsoft.com/en-us/azure/app-service/webjobs-sdk-how-to#multiple-instances ) таймер должен выполняться неявно как одноэлементный, что означает, что он должен использовать учетную запись хранилища Azure для поддержки распределенной блокировки.

При локальном использовании функций Azure я бы ожидал предоставить настройку, подобную этой:

 {
  "AzureWebJobsStorage": "UseDevelopmentStorage=true"
}
  

В противном случае я действительно не могу запустить функцию, я получаю сообщение об ошибке, в котором говорится, что эта настройка обязательна, однако в примере с консольным хостом я вообще не получаю никакой ошибки.

Кто-нибудь может объяснить, почему хост консоли не требует использования учетной записи хранилища по умолчанию? Как таймер поддерживает одноэлементное поведение в этом сценарии?

Ответ №1:

Я потратил некоторое время на отладку исходного кода WebJobs SDK из моего приложения и нашел больше информации о том, что происходит под капотом:

  • Если параметр приложения azurewebjobstorage не определен в конфигурации, то SDK возвращается к использованию диспетчера распределенных блокировок в памяти для таймера и одноэлементных триггеров. С этим резервным вариантом не связано ведение журнала, а менеджер блокировок по умолчанию подходит только для локальной разработки.

  • Вместо этого можно использовать эмулятор хранилища Azure, установив строку подключения, как для функций Azure, просто убедитесь, что вы перестроили свой проект, чтобы файлы appsettings.json распространялись в выходную папку проекта, это меня немного сбило с толку.

  • Если значение AzureWebJobsStorage не является допустимой строкой подключения к локальной или облачной учетной записи хранилища — конфигурация просто автоматически возвращается к менеджеру блокировки в памяти.

Комментарии:

1. Вы тестировали это в Azure Functions?