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

Я играю с 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://docs.microsoft.com/en-us/azure/app-service/webjobs-sdk-how-to#multiple-instances), таймер должен запускаться неявно как одноэлементный, что означает он должен использовать учетную запись хранения Azure для поддержки распределенной блокировки.

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

{
  "AzureWebJobsStorage": "UseDevelopmentStorage=true"
}

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

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


person Sam    schedule 08.03.2019    source источник


Ответы (1)


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

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

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

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

person Sam    schedule 11.03.2019
comment
Вы тестировали это в Функциях Azure? - person MauriR; 30.05.2019