クイック スタート: マネージド ID を使用してDurable Functionsを構成する

このクイックスタートでは、Durable FunctionsアプリをDurable Task SchedulerのバックエンドまたはAzure Storageプロバイダーのいずれかでアイデンティティベースの接続を使用する設定方法を示しています。 AzureプラットフォームはMicrosoft Entra IDからマネージドIDを管理しており、秘密のプロビジョニングやローテーションは不要です。

このパスは、アプリがすでにDurable Task Schedulerのバックエンドを使用するよう設定されていることを前提としています。 もしあなたのアプリがまだAzure Storageプロバイダーを使用している場合は、この記事のAzure Storageパスを選択してください。

この記事の内容:

Note

マネージド ID は、Durable Functions 拡張機能 バージョン 2.7.0 以降でサポートされています。

Azure アカウントをお持ちでない場合は、開始する前に 無料アカウント を作成してください。

Prerequisites

このクイック スタートを完了するには、次のものが必要です。

  • Azure ポータルで作成された既存のDurable Functions プロジェクト、またはAzureに配置されたローカル Durable Functions プロジェクト。
  • AzureでDurable Functions アプリを実行する知識。

Azureに既存のDurable Functions プロジェクトをデプロイしていない場合は、次のいずれかのクイック スタートから開始することをお勧めします。

ローカル開発のセットアップ

ローカル開発には 2 つのオプションがあります。 ローカルのDurable Task Schedulerエミュレーターを使って、Azureの認証情報なしで素早くテストしてください。 もしアイデンティティベースの接続をライブスケジューラーリソースと比較する必要がある場合は、開発者の認証情報を使ってください。

オプション1:ローカルのDurable Task Schedulerエミュレーターを使用する

ローカル開発時は、Azureの認証情報なしでアプリをテストできるDurable Task Schedulerエミュレーターを使いましょう。 アプリの設定をエミュレーターに向け、デフォルトのタスクハブを使うように設定してください。

{
  "IsEncrypted": false,
  "Values": {
    "FUNCTIONS_WORKER_RUNTIME": "dotnet-isolated",
    "AzureWebJobsStorage": "UseDevelopmentStorage=true",
    "DTS_CONNECTION_STRING": "Endpoint=http://localhost:8080;TaskHub=default;Authentication=None",
    "TASKHUB_NAME": "default"
  }
}

オプション 2: ローカル開発用の ID ベースの接続

厳密には、管理IDはAzureで実行される場合にのみアプリに利用可能です。 しかし、開発者の認証情報を使ってスケジューラーリソースに対して認証することで、ローカルで実行中のアプリをアイデンティティベースの接続に設定することは可能です。 そしてAzureにデプロイすると、アプリは管理されたアイデンティティ設定を使用します。

開発者の認証情報を使うと、接続は以下の場所からトークンを取得しようとします(順は以下の通りです):

  1. Microsoft アプリケーション間で共有されるローカル キャッシュ
  2. Visual Studioの現在のユーザー コンテキスト
  3. Visual Studio Codeの現在のユーザー コンテキスト
  4. Azure CLIの現在のユーザー コンテキスト

これらのオプションのいずれも成功しなかった場合は、アプリが認証トークンを取得できないことを示すエラーが表示されます。 スケジューラーリソースにアクセスできるアカウントで、リストに記載されたツールのいずれかにサインインしているか確認してください。

ローカル開発者 ID を使用するようにランタイムを構成する

  1. ローカル設定でスケジューラエンドポイントを設定し、 Authentication=DefaultAzure を使ってアプリが開発者の認証情報を使うようにしてください。

    {
      "IsEncrypted": false,
      "Values": {
        "FUNCTIONS_WORKER_RUNTIME": "dotnet-isolated",
        "AzureWebJobsStorage": "UseDevelopmentStorage=true",
        "DTS_CONNECTION_STRING": "Endpoint=https://<your-scheduler-name>.<region>.durabletask.io;TaskHub=<your-task-hub>;Authentication=DefaultAzure",
        "TASKHUB_NAME": "<your-task-hub>"
      }
    }
    
  2. 開発者のアイデンティティにスケジューラリソースや特定のタスクハブスコープで Durable Task Data Contributor 役割を与えてください。

Azureにデプロイされたアプリの ID ベースの接続

マネージド ID リソースを有効にする

関数アプリでマネージドIDを有効にしてください。 関数アプリでは、システム割り当てマネージド ID またはユーザー割り当てマネージド ID のいずれかが必要になります。 関数アプリのマネージド ID を有効にし、2 種類の ID の違いについて確認するには、マネージド ID の概要に関するページを参照してください。

マネージド ID にアクセス ロールを割り当てる

Azureポータル内のスケジューラーリソースにアクセスし、マネージドIDにDurable Task Data Contributorロールを割り当てます。 最小権限アクセスの場合は、スケジューラ全体ではなくタスクハブのスコープで役割を割り当ててください。 ユーザー割り当て ID を使用する場合は、マネージド ID を選択し、次に + メンバーの選択 を選択します。

マネージド ID 構成をアプリに追加する

アプリのマネージド ID を使うには、その前にアプリの設定をいくつか変更する必要があります。

  1. Azure ポータルの Settings の関数アプリ リソース メニューで、Environment 変数 を選択します。

  2. アプリのマネージドIDを使ってスケジューラーに接続するように、 DTS_CONNECTION_STRING 設定を追加または更新してください。

    Endpoint=https://<your-scheduler-name>.<region>.durabletask.io;TaskHub=<your-task-hub>;Authentication=ManagedIdentity
    

    ユーザー割り当て管理IDを使用する場合、接続文字列にクライアントIDを含めてください:

    Endpoint=https://<your-scheduler-name>.<region>.durabletask.io;TaskHub=<your-task-hub>;Authentication=ManagedIdentity;ClientID=<your-user-assigned-identity-client-id>
    
  3. TASKHUB_NAME設定を同じタスクハブ名に追加または更新してください。

  4. もしFunctionホストがホストレベルの操作のためにAzure Storageが必要な場合は、別AzureWebJobsStorage設定してください。 スケジューラ バックエンドでは、Durable 状態に AzureWebJobsStorage ではなく DTS 接続文字列を使用します。

構成を確認する

マネージド ID の構成が機能することを確認するには:

  1. Azureポータルで関数アプリに移動し、Durable Functionsのオーケストレーションをトリガーします。
  2. オーケストレーションが正常に完了しているか、ステータスエンドポイントに問い合わせるか、 モニター タブをチェックしてください。
  3. 認証エラーが表示された場合は、次のことを確認します。
    • マネージド ID には、スケジューラ リソースまたはタスク ハブのスコープで Durable Task Data Contributor ロールが付与されています。
    • DTS_CONNECTION_STRINGTASKHUB_NAME設定は正しいです。
    • アプリはAzure上で動作する際に期待されるアイデンティティを使用しています。

ローカル開発のセットアップ

ローカル開発には 2 つのオプションがあります。 資格情報をAzureせずにローカルテストを迅速に行うには Azurite を使用します。 実際のAzure Storage アカウントに対して ID ベースの接続をテストする必要がある場合は、代わりに開発者の資格情報を使用してください。

オプション 1: Azure Storage エミュレーターを使用する

ローカルで開発する場合は、Azure Storageのローカル エミュレーターである Azurite を使用することをお勧めします。 local.settings.jsonで "AzureWebJobsStorage": "UseDevelopmentStorage=true" を指定して、エミュレーター用にアプリを構成します。

オプション 2: ローカル開発用の ID ベースの接続

厳密に言えば、マネージド ID は、Azureで実行する場合にのみアプリで使用できます。 ただし、開発者の資格情報を使用して Azure リソースに対して認証することで、ID ベースの接続を使用するようにローカルで実行されているアプリを構成することもできます。 その後、Azureにデプロイすると、アプリは代わりにマネージド ID 構成を利用します。

開発者の資格情報を使用する場合、接続は次の場所からこの順序でトークンの取得を試みます。

  1. Microsoft アプリケーション間で共有されるローカル キャッシュ
  2. Visual Studioの現在のユーザー コンテキスト
  3. Visual Studio Codeの現在のユーザー コンテキスト
  4. Azure CLIの現在のユーザー コンテキスト

これらのオプションのいずれも成功しなかった場合は、アプリが認証トークンを取得できないことを示すエラーが表示されます。 Azure Storage アカウントにアクセスできるアカウントを使用して、一覧表示されているツールのいずれかにサインインしていることを確認します。

ローカル開発者 ID を使用するようにランタイムを構成する

  1. local.settings.jsonでAzure Storage アカウントの名前を指定します。次に例を示します。

    {
       "IsEncrypted": false,
       "Values": {
          "AzureWebJobsStorage__accountName": "<<your Azure Storage account name>>",
          "FUNCTIONS_WORKER_RUNTIME": "dotnet-isolated"
       }
    }
    
  2. Azure ポータルで、Azure Storage アカウント リソースに移動します。

  3. Access Control (IAM) タブを選択し、ロールの割り当ての追加を選択します。

  4. 次の各ロールを自分に割り当てます。 ロールごとに、+[メンバーの選択 <]/c0> を選択し>Visual Studio、Visual Studio Code、またはAzure CLIにサインインするために使用する電子メールを検索します。

    • ストレージ キュー データ共同作成者
    • ストレージ ブロブ データコントリビューター
    • ストレージ テーブル データ共同作成者

    Note

    これらは、Azureにデプロイするときにマネージド ID に必要な 3 つのロールと同じです。 マネージド ID へのアクセス ロールの割り当てを参照してください。

    Azure ポータルのアクセス制御ページで、ストレージ データ共同作成者ロールをユーザーに割り当てる画面のスクリーンショット。

Azureにデプロイされたアプリの ID ベースの接続

マネージド ID リソースを有効にする

開始するには、アプリケーションのマネージド ID を有効にします。 関数アプリでは、システム割り当てマネージド ID またはユーザー割り当てマネージド ID のいずれかが必要になります。 関数アプリのマネージド ID を有効にし、2 種類の ID の違いについて確認するには、マネージド ID の概要に関するページを参照してください。

マネージド ID にアクセス ロールを割り当てる

Azure ポータルでアプリのAzure Storage リソースに移動し、assign 3 つのロールベースのアクセス制御 (RBAC) ロールをマネージド ID リソースに移動します。

  • ストレージ キュー データ共同作成者
  • ストレージ ブロブ データコントリビューター
  • ストレージ テーブル データ共同作成者

自分の ID リソースを見つけるには、[アクセスの割り当て先] の [マネージド ID] を選んでから、[+ メンバーの選択] を選びます

Azure portal でマネージド ID にストレージ アクセス ロールを割り当てる画面。

マネージド ID 構成をアプリに追加する

アプリのマネージド ID を使うには、その前にアプリの設定をいくつか変更する必要があります。

  1. Azure ポータルの Settings の関数アプリ リソース メニューで、Environment 変数 を選択します。

  2. 設定の一覧で、[AzureWebJobsStorage] を見つけて、[削除] アイコンを選びます。 Azure ポータル関数アプリの設定の AzureWebJobsStorage 環境変数のスクリーンショット。

  3. Azure ストレージ アカウントをアプリケーションにリンクする設定を追加します。

    アプリが実行されているクラウドに応じて、"次のいずれかの方法" を使用します。

    • Azure cloud: アプリが global Azure で実行されている場合は、Azureストレージ アカウント名を識別する設定 AzureWebJobsStorage__accountName を追加します。 値の例: mystorageaccount123

    • 非Azure クラウド: Azure外のクラウドでアプリケーションを実行する場合は、アカウント名ではなくストレージ アカウントの特定のサービス URI (または endpoints) を提供するために、次の 3 つの設定を追加する必要があります。

      • 設定名: AzureWebJobsStorage__blobServiceUri

        値の例: https://mystorageaccount123.blob.core.windows.net/

      • 設定名: AzureWebJobsStorage__queueServiceUri

        値の例: https://mystorageaccount123.queue.core.windows.net/

      • 設定名: AzureWebJobsStorage__tableServiceUri

        値の例: https://mystorageaccount123.table.core.windows.net/

    これらの URI 変数の値は、ストレージ アカウント情報の [エンドポイント] タブから入手できます。

    BLOB、キュー、および Table Service URI を示す [ストレージ アカウント エンドポイント] タブのスクリーンショット。

    Note

    Azure Government またはグローバル Azureとは別の他のクラウドを使用している場合は、ストレージ アカウント名だけでなく、特定のサービス URI を提供するオプションを使用する必要があります。 Azure Government で Azure Storage を使用する方法の詳細については、「Azure Government で Storage API を使用した開発」を参照してください。

  4. マネージド ID の構成を終了します (設定を変更した後、忘れずに [適用] をクリックしてください)。

    • システム割り当て ID を使用する場合は、他の変更は行いません。

    • "ユーザー割り当て ID" を使う場合は、次の設定をアプリの構成に追加します。

      • AzureWebJobsStorage__credential: 「managedidentity」と入力します

      • AzureWebJobsStorage__clientId: この GUID 値はマネージド ID リソースから取得します

    クライアント ID 値を示すユーザー割り当てマネージド ID リソースのスクリーンショット。

    Note

    Durable Functions はユーザー割り当て ID を使用する場合、サポートされませんmanagedIdentityResourceIdclientId を代わりに使用します。

構成を確認する

マネージド ID の構成が機能することを確認するには:

  1. Azure ポータルで、関数アプリに移動し、(HTTP トリガー関数を使用するなどして) Durable Functionsオーケストレーションをトリガーします。
  2. 状態エンドポイントに対してクエリを実行するか、[ 監視 ] タブを確認して、オーケストレーションが正常に完了したことを確認します。
  3. 認証エラーが表示された場合は、次のことを確認します。
    • 3 つのストレージ データ共同作成者ロールはすべて、正しい ID に割り当てられます。
    • AzureWebJobsStorage コネクションストリング設定が削除されます。
    • AzureWebJobsStorage__accountName (またはサービス URI) の設定が正しいです。

次のステップ