Azure Functionsでアプリの設定にアクセスする

なぜ Azure Functions ではアプリの設定が重要なのか

ティムはまず、最も基本的な.NETアプリ以上のものを構築する際に、アプリケーション設定がいかに重要であるかを述べる。Azure Functionsのランタイムは、環境変数、JSONベースのlocal.settings.json、またはAzure App Configurationなどのマネージドストアから設定値を取得することを想定しているためです。

開発者が最終的に求める共通の機能のひとつは、設定ファイルへのアクセスです"とティムは0:17で説明する。

API キー、接続文字列、または機能フラグのいずれであっても、設定の柔軟性とセキュリティは最も重要です。

VisualStudioで基盤を作る

1:24で、TimはVisual Studioを使用してコンソールプロジェクトをセットアップし、SettingsDemoAppと名付けています。Azureの開発者は通常、Azure Functions Core Toolsを使用してFunctionsプロジェクトを初期化しますが、Timの方法でコードを足場にして整理することで、シームレスに翻訳できます。 プロジェクトファイルのセットアップとコード構造は、コンソール環境であろうと、分離されたワーカーモデルで分離された Azure Functions アプリの構築であろうと、重要な基礎となります。

必要な NuGet パッケージをインストールする

2:33から、Timは4つの重要なNuGetパッケージのインストールについて説明します：

• Microsoft.Extensions.Configuration（マイクロソフト.エクステンション.コンフィギュレーション

• Microsoft.Extensions.Configuration（マイクロソフト.エクステンション.コンフィギュレーション.Json

• マイクロソフト.エクステンション.コンフィギュレーション.バインダー

• Microsoft.Extensions.Configuration（マイクロソフト.エクステンション.コンフィギュレーション.UserSecrets

これは、裏で同じパッケージに依存しているAzure Functionsで使用されているアプリ構成システムを反映しています。 ティムはモジュール化の価値を強調しています：

.NET Coreは、開発者がNuGet経由で選択できるようにすることで、不要なペイロードを回避しているためだ。

典型的な機能アプリでは、これらのパッケージは事前に参照されるか、構成設定、依存性注入、またはKey VaultやAzure App Configurationのサポートのような高度なユースケースのためのカスタムロジックをサポートするために簡単に追加されます。

JSON設定ファイルを追加して構成する

6:12で、Timはappsettings.jsonという名前の新しいファイルを作成し、Azure Functions開発用のlocal.settings.jsonに見られる構造を模倣している。 彼は、次のようなキーと値のペアを入力します：

{
  "ユーザー"：{
    "FirstName"："Tim"、
    "LastName"："Corey"
  },
  "スターターカウント値": 5
}

ローカル機能では、開発者は、注入されたIConfigurationを介してアプリケーションロジックに値を読み込むために、ほぼ同じフォーマットでlocal.settings.jsonを使用します。 Timはまた、重要なステップとして、ファイルのCopy to Output Directoryを "Copy if newer "に設定することにも注目しています。

手動で構成パイプラインを構築する

Timは、コンフィギュレーション・パイプラインを手動でセットアップするコードを書いていきます：

var ビルダー = 新しい ConfigurationBuilder()
    .SetBasePath(ディレクトリ.GetCurrentDirectory())
    .AddJsonFile("appsettings.json", optional: true, reloadOnChange: true)；

Azure Functionsのランタイムはこのパイプラインを自動的に処理しますが、Tim氏の内訳は、関数プロジェクトがさまざまなソースから値を取り込む方法を明確にしています。 .AddJsonFile()の使用は、開発者がAzureアプリでlocal.settings.jsonを構成する方法を反映し、reloadOnChangeは、開発中に構成設定を動的にリフレッシュする概念を導入している。

型の安全性で値を読み取る

Tim は 11:00 に GetValue() メソッドを使用して設定を読み取る方法を示します:

int count = config.GetValue<int>("StarterCountValue")；

また、ネストされた設定には

string firstName = config.GetValue<string>("User:FirstName")；

Azure Functionsを使用する場合、これらと同じ構文パターンが適用されます。 Timのコロン区切りのキー（"User:FirstName"）は、ダブル・アンダースコア( __)構文を使って環境変数に直接マッピングされています：

ユーザー名=Tim

これは、アプリケーション設定や環境ベースのオーバーライドを使用して実行時に設定を上書きできる、Azure App ServiceへのデプロイやAzureポータル経由での構成時に特に役立ちます。

UserSecretsで秘密を安全に扱う

15:00に、TimはUser Secretsを通してsecrets.jsonパターンを紹介する。これは、APIキーや接続文字列のような機密データを、ソース管理で公開せずに保存するために使われる。 彼は、この行を使ってプロジェクトにUser Secretsストアをアタッチする方法を示しています：

builder.AddUserSecrets<Program>()；

彼は、順序が重要であることを強調しています。ユーザーシークレットは以前の設定ソースを上書きし、最後のものが勝つという原則を強化します。 Azure Functionsはsecrets.jsonを直接使用しませんが、本番のクラウド環境では、Azure Key Vaultを使用し、オプションでマネージドID認証を使用して、同じように安全なオーバーライドを実現します。

ティムは、ローカル開発における秘密は、本番環境で使用しているセキュアなシステムの代用品であると指摘する：

"このsecrets.jsonは、Key Vaultであろうと環境設定であろうと、実際の値を保存するために使っている安全なシステムの代用品です。"

構成の実行と検証

appsettings.jsonとsecrets.jsonの両方を設定した後、Timはサンプルを実行し、secretsが基本値を上書きすることを検証します。 これは、Azure Functionsが複数のソース（local.settings.json、Azure App Configuration、環境変数、またはKey Vault）からのオーバーライドをどのように処理するかを直接反映しています。

コマンドラインからAzure Functions Core Toolsを使用する場合でも、Visual Studioからデプロイする場合でも、アプリ構成のロード順序とレイヤリングは、Timが概説したとおりに動作します。

構成管理のベストプラクティス

Tim氏は最後に、機能フラグ、頻度設定、CORS設定など、頻繁に変更されない設定値をJSONファイルに保持し、接続文字列やシークレットなどの機密データを安全なストアに置くことを推奨している。

これは、Azure Functionsの最新のベストプラクティスに沿ったものです：

• 開発者は、ローカルでlocal.settings.jsonを使用します。

• チームは、アプリケーションの設定に Azure ポータルを使用します。

• 秘密はKey Vaultへ

• Azure App Configurationストアの値は、コードから設定を分離するのに役立ちます。

これらのソースは、アプリケーション・バイナリに触れることなく、依存性注入を使用してランタイムと統合されます。

最終的な考え

Tim の video はコンソール アプリについてですが、彼が教えるすべてのテクニックは、設定ファイルの作成、キーの読み取り、マネージド ID の使用、依存性注入による設定の読み込みに至るまで、Azure Functions アプリにシームレスに拡張されます。 Visual Studio でのデプロイ、azure アカウントの管理、完全なコード例の検索など、彼の洞察は実際のクラウドの実践に直接対応します。