.NET構成の進化

巨大なプロジェクト、センサー、メトリック、スイッチの巨大なパネルがあり、すべてを必要に応じて簡単に構成できる場合、すべてのプログラマーは自分自身を飛行機のパイロットとして想像しました。まあ、少なくとも自分でシャーシを手動で持ち上げるために実行していません。メトリックとグラフはどちらも優れていますが、今日は、航空機の動作のパラメーターを変更して構成できる同じタンブラーとボタンについて説明します。



構成の重要性を過小評価することは困難です。誰もがアプリケーションを構成する際にいずれかのアプローチを使用し、原則としてそれについて複雑なことは何もありませんが、それは本当にそれほど単純ですか？構成の「前」と「後」を見て、詳細を理解することを提案します。つまり、機能、新機能、およびそれらを最大限に活用する方法です。.NET Coreでの構成に慣れていない人は基本を学び、慣れている人は日常業務で新しいアプローチについて考え、使用するための知識を得ることができます。

Pre-.NETコア構成

2002年に.NETFrameworkが導入され、XMLの誇大宣伝の時代だったため、Microsoftの開発者は「どこにでも持っていこう」と決心し、その結果、XML構成はまだ生きています。テーブルの先頭には、パラメータ値の文字列表現を取得するための静的ConfigurationManagerクラスがあります。構成自体は次のようになりました。

<?xml version="1.0" encoding="utf-8" ?>
<configuration>
  <appSettings>
    <add key="Title" value=".NET Configuration evo" />
    <add key="MaxPage" value="10" />
  </appSettings>
</configuration>

問題は解決され、開発者はINIファイルよりも優れているが、独自の特性を備えたカスタマイズオプションを入手しました。したがって、たとえば、さまざまなタイプのアプリケーション環境に対するさまざまな設定値のサポートは、構成ファイルのXSLT変換を使用して実装されます。データのグループ化に関してより複雑なものが必要な場合は、要素と属性に対して独自のXMLスキーマを定義できます。キーと値のペアは厳密に文字列タイプであり、数値または日付が必要な場合は、「どうにかして自分でやろう」：

string title = ConfigurationManager.AppSettings["Title"];
int maxPage = int.Parse(ConfigurationManager.AppSettings["MaxPage"]);

2005年に、構成セクションを追加しました。これらのセクションでは、パラメーターのグループ化、独自のスキームの構築、名前の競合の回避が可能でした。 * .settingsファイルとそれらのための特別なデザイナーも紹介しました。







これで、構成データを表す、生成された厳密に型指定されたクラスを取得できます。デザイナを使用すると、値を簡単に編集できます。エディタの列で並べ替えることができます。データは、シングルトン構成オブジェクトを提供する、生成されたクラスのDefaultプロパティを使用して取得されます。

DateTime date = Properties.Settings.Default.CustomDate;
int displayItems = Properties.Settings.Default.MaxDisplayItems;
string name = Properties.Settings.Default.ApplicationName;

また、構成パラメーター値のスコープも追加しました。ユーザー領域はユーザーデータを担当します。ユーザーデータはユーザーが変更したり、プログラムの実行中に保存したりできます。保存は、パス％AppData％\ *アプリケーション名*に沿った別のファイルで行われます。アプリケーションスコープを使用すると、ユーザーが再定義することなくパラメータ値を取得できます。



善意にもかかわらず、全体がより複雑になりました。

• 実際、これらは同じXMLファイルであり、サイズが急速に大きくなり始め、その結果、読み取りが不便になりました。
• 構成はXMLファイルから1回読み取られ、構成データに変更を適用するには、アプリケーションをリロードする必要があります。
• * .settingsファイルから生成されたクラスは、封印された修飾子でマークされていたため、このクラスを継承できませんでした。さらに、このファイルは変更される可能性がありますが、再生が発生すると、自分で作成したものがすべて失われます。
• キー値スキームに従ってのみデータを処理します。構成を操作するための構造化されたアプローチを取得するには、これを自分で追加で実装する必要があります。
• データソースはファイルのみであり、外部プロバイダーはサポートされていません。
• さらに、人的要因があります。プライベートパラメータがバージョン制御システムに入り、公開されます。

これらの問題はすべて、今日まで.NETフレームワークに残っています。

.NETコア構成

.NET Coreでは、構成を再考し、すべてを最初から作成し、静的なConfigurationManagerクラスを削除して、「以前」の問題の多くを解決しました。何が新しくなったのですか？以前と同様に、構成データを生成する段階とこのデータを消費する段階ですが、より柔軟でライフサイクルが延長されます。

構成データの設定と入力

したがって、データ生成の段階では、ファイルだけに限定するのではなく、多くのソースを使用できます。構成は、データソースを追加するための基礎であるIConfgurationBuilderを介して行われます。NuGetパッケージは、さまざまなタイプのソースで利用できます。



各ソースは新しいレイヤーとして追加され、一致するキーでパラメーターをオーバーライドします。これは、ASP.NET Coreアプリテンプレート（バージョン3.1）にデフォルトで付属しているProgram.csの例です。

public static IHostBuilder CreateHostBuilder(string[] args) => 
    Host.CreateDefaultBuilder(args).ConfigureWebHostDefaults(webBuilder => 
        { webBuilder.UseStartup<Startup>(); });

CreateDefaultBuilderに 主な焦点を合わせたいと思います。メソッド内で、ソースの初期構成がどのように行われるかを確認します。

public static IWebHostBuilder CreateDefaultBuilder(string[] args)
{
    var builder = new WebHostBuilder();

    ...

    builder.ConfigureAppConfiguration((hostingContext, config) =>
    {
        IHostingEnvironment env = hostingContext.HostingEnvironment;

        config.AddJsonFile("appsettings.json", optional: true, reloadOnChange: true)
              .AddJsonFile($"appsettings.{env.EnvironmentName}.json", optional: true, reloadOnChange: true);

        if (env.IsDevelopment())
        {
            Assembly appAssembly = Assembly.Load(new AssemblyName(env.ApplicationName));
            if (appAssembly != null)
            {
                config.AddUserSecrets(appAssembly, optional: true);
            }
        }

        config.AddEnvironmentVariables();

        if (args != null)
        {
            config.AddCommandLine(args);
        }
    })
            
    ...

    return builder;
}

したがって、構成全体のベースはappsettings.jsonファイルになります。さらに、特定の環境用のファイルがある場合、そのファイルの優先度が高くなるため、ベースの一致する値が上書きされます。そして、後続の各ソースについても同様です。追加の順序は最終値に影響します。視覚的には、すべてが次のように







なります。注文を使用する場合は、注文をクリアして、必要な方法を定義するだけです。

Host.CreateDefaultBuilder(args)
    .ConfigureWebHostDefaults(webBuilder => { webBuilder.UseStartup<Startup>(); })
    .ConfigureAppConfiguration((context,
                                builder) =>
     {
         builder.Sources.Clear();
         
         //  
     });

各構成ソースには2つの部分があります。

• IConfigurationSourceの実装。構成値のソースを提供します。
• IConfigurationProviderの実装。元のデータを結果のキー値に変換します。

これらのコンポーネントを実装することにより、構成用の独自のデータソースを取得できます。これは、エンティティフレームワークを介してデータベースからパラメータを取得する方法の例です。

データの使用方法と取得方法

設定と構成データの入力ですべてが明確になったので、このデータをどのように使用し、より便利に取得するかを検討することを提案します。プロジェクトを構成するための新しいアプローチは、一般的なJSON形式に大きな偏りをもたらします。これは、データ構造の構築、データのグループ化、および読み取り可能なファイルの作成を同時に行うことができるため、驚くべきことではありません。たとえば、次の構成ファイルを見てみましょう。

{
  "Features" : {
    "Dashboard" : {
      "Title" : "Default dashboard",
      "EnableCurrencyRates" : true
    },
    "Monitoring" : {
      "EnableRPSLog" : false,
      "EnableStorageStatistic" : true,
      "StartTime": "09:00"
    }
  }
}

すべてのデータはフラットなキー値ディクショナリを形成し、構成キーは各値のファイルキー階層全体から形成されます。同様の構造には、次のデータセットがあります。





IConfiguration オブジェクトを使用して値を取得できます。たとえば、パラメータを取得する方法は次のとおりです。

string title = Configuration["Features:Dashboard:Title"];
string title1 = Configuration.GetValue<string>("Features:Dashboard:Title");
bool currencyRates = Configuration.GetValue<bool>("Features:Dashboard:EnableCurrencyRates");
bool enableRPSLog = Configuration.GetValue<bool>("Features:Monitoring:EnableRPSLog");
bool enableStorageStatistic = Configuration.GetValue<bool>("Features:Monitoring:EnableStorageStatistic");
TimeSpan startTime = Configuration.GetValue<TimeSpan>("Features:Monitoring:StartTime");

そして、これはすでにかなり良いです。必要なデータタイプにキャストされたデータを取得するための良い方法がありますが、どういうわけか私たちが望むほどクールではありません。上記のようなデータを受け取った場合、コードが繰り返され、キーの名前を間違えることになります。個々の値の代わりに、完全な構成オブジェクトをアセンブルできます。Bindメソッドを使用してデータをオブジェクトにバインドすると、これに役立ちます。クラスとデータの取得の例：

public class MonitoringConfig
{
    public bool EnableRPSLog { get; set; }
    public bool EnableStorageStatistic { get; set; }
    public TimeSpan StartTime { get; set; }
}

var monitorConfiguration = new MonitoringConfig();
Configuration.Bind("Features:Monitoring", monitorConfiguration);

var monitorConfiguration1 = new MonitoringConfig();
IConfigurationSection configurationSection = Configuration.GetSection("Features:Monitoring");
configurationSection.Bind(monitorConfiguration1);

前者の場合はセクション名でバインドし、後者の場合はセクションを取得してバインドします。このセクションでは、構成の部分的なビューを操作できます。これにより、操作しているデータセットを制御できます。セクションは、標準の拡張メソッドでも使用されます。たとえば、接続文字列を取得するには、「ConnectionStrings」セクションを使用します。

string connectionString = Configuration.GetConnectionString("Default");

public static string GetConnectionString(this IConfiguration configuration, string name)
{
    return configuration?.GetSection("ConnectionStrings")?[name];
}

オプション-型付き構成ビュー

構成オブジェクトを手動で作成してデータにバインドすることは実用的ではありませんが、Optionsを使用するという形で解決策があります。オプションは、構成の厳密に型指定されたビューを取得するために使用されます。ビュークラスは、値を割り当てるためのパラメータとパブリックプロパティのないコンストラクタでパブリックである必要があり、オブジェクトはリフレクションによって埋められます。詳細については、ソースをご覧ください。



オプションの使用を開始するには、クラスに投影するセクションを示すIServiceCollectionのConfigure拡張メソッドを使用して構成タイプを登録する必要があります。

public void ConfigureServices(IServiceCollection services)
{
    services.AddControllers();
    services.Configure<MonitoringConfig>(Configuration.GetSection("Features:Monitoring"));
}

その後、IOptions、IOptionsMonitor、IOptionsSnapshotインターフェイスへの依存関係を挿入することで構成を受け取ることができます。 MonitoringConfigオブジェクトは、Valueプロパティを介してIOptionsインターフェイスから取得できます。

public class ExampleService
{
    private IOptions<MonitoringConfig> _configuration;
    public ExampleService(IOptions<MonitoringConfig> configuration)
    {
        _configuration = configuration;
    }
    public void Run()
    {
        TimeSpan timeSpan = _configuration.Value.StartTime; // 09:00
    }
}

IOptionsインターフェイスの機能は、依存関係インジェクションコンテナで、構成がシングルトンライフサイクルのオブジェクトとして登録されることです。 Valueプロパティによって初めて値が要求されると、オブジェクトは、このオブジェクトが存在する限り存在するデータで初期化されます。 IOptionsはデータの更新をサポートしていません。更新をサポートするためのIOptionsSnapshotおよびIOptionsMonitorインターフェイスがあります。



DIコンテナのIOptionsSnapshotは、スコープ付きライフサイクルに登録されます。これにより、要求に応じて、新しいコンテナスコープで新しい構成オブジェクトを取得できます。たとえば、1つのWebリクエスト中に同じオブジェクトを受け取りますが、新しいリクエストの場合、更新されたデータを含む新しいオブジェクトを受け取ります。



IOptionsMonitorはシングルトンとして登録されますが、各構成が要求時に実際のデータとともに受信されるという唯一の違いがあります。さらに、IOptionsMonitorを使用すると、データ変更イベント自体に応答する必要がある場合に、構成変更イベントハンドラーを登録できます。

public class ExampleService
{
    private IOptionsMonitor<MonitoringConfig> _configuration;
    public ExampleService(IOptionsMonitor<MonitoringConfig> configuration)
    {
        _configuration = configuration;
        configuration.OnChange(config =>
        {
            Console.WriteLine(" ");
        });
    }
    
    public void Run()
    {
        TimeSpan timeSpan = _configuration.CurrentValue.StartTime; // 09:00
    }
}

IOptionsSnapshotとIOptionsMontitorを名前で取得することもできます。これは、1つのクラスに対応する複数の構成セクションがあり、特定のセクションを取得する場合に必要です。たとえば、次のデータがあります。

{
  "Cache": {
    "Main": {
      "Type": "global",
      "Interval": "10:00"
    },
    "Partial": {
      "Type": "personal",
      "Interval": "01:30"
    }
  }
}

投影に使用されるタイプ：

public class CachePolicy
{
    public string Type { get; set; }
    public TimeSpan Interval { get; set; }
}

特定の名前で構成を登録します。

services.Configure<CachePolicy>("Main", Configuration.GetSection("Cache:Main"));
services.Configure<CachePolicy>("Partial", Configuration.GetSection("Cache:Partial"));

次のように値を受け取ることができます：

public class ExampleService
{
    public ExampleService(IOptionsSnapshot<CachePolicy> configuration)
    {
        CachePolicy main = configuration.Get("Main");
        TimeSpan mainInterval = main.Interval; // 10:00
            
        CachePolicy partial = configuration.Get("Partial");
        TimeSpan partialInterval = partial.Interval; // 01:30
    }
}

構成タイプを登録する拡張メソッドのソースコードを見ると、デフォルト名がOptions.Defaultであり、これは空の文字列であることがわかります。したがって、暗黙的に、構成の名前を常に渡します。

public static IServiceCollection Configure<TOptions>(this IServiceCollection services, IConfiguration config) where TOptions : class
            => services.Configure<TOptions>(Options.Options.DefaultName, config);

構成はクラスで表すことができるため、System.ComponentModel.DataAnnotations名前空間の検証属性を使用してプロパティをマークアップすることにより、パラメーター値の検証を追加することもできます。たとえば、Typeプロパティの値が必須である必要があることを指定します。ただし、構成を登録するときに、原則として検証を行う必要があることも示す必要があります。このための拡張メソッドValidateDataAnnotationsがあります。

public class CachePolicy
{
    [Required]
    public string Type { get; set; }
    public TimeSpan Interval { get; set; }
}

services.AddOptions<CachePolicy>()
        .Bind(Configuration.GetSection("Cache:Main"))
        .ValidateDataAnnotations();

このような検証の特徴は、構成オブジェクトを受け取った瞬間にのみ発生することです。これにより、アプリケーションの起動時に構成が無効であることを理解することが困難になります。この問題については、GitHubに問題があります。この問題の1つの解決策は、ASP.NETCoreで厳密に型指定された構成オブジェクトへの検証の追加の記事に示されているアプローチです。

オプションのデメリットとその回避方法

オプションを介した構成にも欠点があります。使用するには、依存関係を追加する必要があり、Value / CurrentValueプロパティにアクセスして値オブジェクトを取得する必要があるたびに。オプションラッパーなしでクリーンな構成オブジェクトを取得することで、よりクリーンなコードを実現できます。この問題の最も簡単な解決策は、純粋な構成タイプの依存関係のコンテナーへの追加登録です。

services.Configure<MonitoringConfig>(Configuration.GetSection("Features:Monitoring"));
services.AddScoped<MonitoringConfig>(provider => provider.GetRequiredService<IOptionsSnapshot<MonitoringConfig>>().Value);

解決策は簡単です。最終的なコードにIOptionsについて認識させることはありませんが、必要に応じて追加の構成アクションの柔軟性を失います。この問題を解決するために、「ブリッジ」パターンを使用できます。これにより、オブジェクトを受け取る前に追加のアクションを実行できる追加のレイヤーを取得できます。



この目標を達成するには、現在のサンプルコードをリファクタリングする必要があります。構成クラスにはパラメーターのないコンストラクターの形式の制限があるため、IOptions / IOptionsSnapshot / IOptionsMontitorオブジェクトをコンストラクターに渡すことはできません。このため、構成の読み取りを最終的なプレゼンテーションから分離します。



たとえば、MonitoringConfigクラスのStartTimeプロパティを、標準形式に適合しない値「09」の分を表す文字列表現で指定するとします。

public class MonitoringConfigReader
{
    public bool EnableRPSLog { get; set; }
    public bool EnableStorageStatistic { get; set; }
    public string StartTime { get; set; }
}

public interface IMonitoringConfig
{
    bool EnableRPSLog { get; }
    bool EnableStorageStatistic { get; }
    TimeSpan StartTime { get; }
}

public class MonitoringConfig : IMonitoringConfig
{
    public MonitoringConfig(IOptionsMonitor<MonitoringConfigReader> option)
    {
        MonitoringConfigReader reader = option.Value;
        
        EnableRPSLog = reader.EnableRPSLog;
        EnableStorageStatistic = reader.EnableStorageStatistic;
        StartTime = GetTimeSpanValue(reader.StartTime);
    }
    
    public bool EnableRPSLog { get; }
    public bool EnableStorageStatistic { get; }
    public TimeSpan StartTime { get; }
    
    private static TimeSpan GetTimeSpanValue(string value) => TimeSpan.ParseExact(value, "mm", CultureInfo.InvariantCulture);
}

クリーンな構成を取得できるようにするには、依存関係インジェクションコンテナに登録する必要があります。

services.Configure<MonitoringConfigReader>(Configuration.GetSection("Features:Monitoring"));
services.AddTransient<IMonitoringConfig, MonitoringConfig>();

このアプローチにより、構成オブジェクトを形成するための完全に別個のライフサイクルを作成できます。独自のデータ検証を追加したり、暗号化された形式で受け取った場合はデータ復号化の段階を追加で実装したりすることができます。

データセキュリティの確保

重要な構成タスクはデータセキュリティです。データは読みやすいクリアテキストで保存されるため、ファイル構成は安全ではありません。多くの場合、ファイルはアプリケーションと同じディレクトリにあります。誤って、データを分類解除できるバージョン制御システムに値をコミットする可能性がありますが、これがパブリックコードであるかどうかを想像してください！状況は非常に一般的であるため、そのようなリークを見つけるための既製のツールであるGitleaksさえあります。統計と開示されたデータの多様性を提供する別の記事があります。



多くの場合、プロジェクトには、環境（リリース/デバッグなど）ごとに個別のパラメーターが必要です。たとえば、ソリューションの1つとして、継続的な統合と配信のツールを使用して最終値の置換を使用できますが、このオプションは開発中にデータを保護しません。ユーザーシークレットツールは、開発者を保護するように設計されています。 .NET Core SDK（3.0.100以降）に含まれています。このツールの主な原則は何ですか？まず、initコマンドで動作するようにプロジェクトを初期化する必要があります。

dotnet user-secrets init

このコマンドは、UserSecretsId要素を.csprojプロジェクトファイルに追加します。このパラメーターを使用すると、通常のJSONファイルを格納するプライベートストレージを取得できます。違いは、プロジェクトディレクトリにないため、現在のコンピューターでのみ使用できることです。 Windowsのパスは％APPDATA％\ Microsoft \ UserSecrets \ <user_secrets_id> \ secrets.jsonであり、LinuxおよびMacOSの場合は〜/ .microsoft / usersecrets / <user_secrets_id> /secrets.jsonです。 setコマンドを使用して、上記の例の値を追加できます。

dotnet user-secrets set "Features:Monitoring:StartTime" "09:00"

使用可能なコマンドの完全なリストは、ドキュメントにあります。



本番環境でのデータセキュリティは、AWS Secrets Manager、Azure Key Vault、HashiCorp Vault、Consul、ZooKeeperなどの専用ストレージを使用して最も確実になります。一部を接続するには、すでに既製のNuGetパッケージがあり、REST APIにアクセスできるため、自分で簡単に実装できるものもあります。

結論

現代の問題には現代的な解決策が必要です。モノリスから動的インフラストラクチャへの移行に伴い、構成アプローチも変更されました。構成データのソースの場所とタイプに関係なく、データの変更に迅速に対応する必要がありました。.NET Coreとともに、あらゆる種類のアプリケーション構成シナリオを実装するための優れたツールを入手しました。