次の方法で共有


Application Configuration Service for Tanzu を使用する

Note

BasicStandardEnterprise プランは、2025 年 3 月中旬以降非推奨になり、廃止期間は 3 年間です。 Azure Container Apps に移行することをお勧めします。 詳細については、「Azure Spring Apps の廃止のお知らせ」を参照してください。

Standard 従量課金と専用プランは、2024 年 9 月 30 日以降に非推奨になり、6 か月後に完全にシャットダウンされます。 Azure Container Apps に移行することをお勧めします。 詳細については、「Azure Spring Apps の Standard 従量課金および専用プランを Azure Container Apps に移行する」を参照してください。

この記事の適用対象:❌ Basic または Standard ✔️ Enterprise

この記事では、Azure Spring Apps Enterprise プランで Application Configuration Service for VMware Tanzu® を使用する方法について説明します。

Application Configuration Service for VMware Tanzu は、商用 VMware Tanzu コンポーネントの 1 つです。 それを使うと、1 つまたは複数の Git リポジトリで定義されているプロパティから設定される Kubernetes ネイティブな ConfigMap リソースを管理できます。

Application Configuration Service を使用すると、すべての環境にまたがってアプリケーションの外部プロパティを一元管理できます。 Basic プランおよび Standard プランの Spring Cloud Config Server との違いを理解するには、「Azure Spring Apps Basic または Standard プランのインスタンスを Enterprise プランに移行する」の「外部構成に Application Configuration Service を使用する」セクションを参照してください。

Application Configuration Service は、Gen1 と Gen2 の 2 つのバージョンで提供されます。 Gen1 バージョンは、主に下位互換性のために既存のお客様にサービスを提供し、2024 年 4 月 30 日までのみサポートされます。 新しいサービス インスタンスでは Gen2 を使用する必要があります。 Gen2 バージョンでは、バックエンドとして flux を使用して Git リポジトリと通信し、Gen1 と比較してより優れたパフォーマンスを提供します。

次の表に、サブコンポーネントのリレーションシップを示します。

Application Configuration Service の生成 サブコンポーネント
Gen1 application-configuration-service
Gen2 application-configuration-service
flux-source-controller

次の表に、参照用のベンチマーク データを示します。 ただし、Git リポジトリのサイズは、パフォーマンス データに大きな影響を与える重要な要素です。 Git リポジトリを小さく保つために、必要な構成ファイルのみを格納することをお勧めします。

Application Configuration Service の生成 100 パターン未満の更新期間 250 パターン未満の更新期間 500 パターン未満の更新期間
Gen1 330 秒 840 秒 1500 秒
Gen2 13 秒 100 秒 378 秒

また、Gen2 では、リモート Git リポジトリに接続するときに、より多くのセキュリティ検証が提供されます。 Gen2 では、HTTPS を使用している場合はセキュリティで保護された接続が必要であり、SSH 接続の使用時には正しいホスト キーとホスト アルゴリズムが検証されます。

Azure Spring Apps Enterprise サービス インスタンスを作成するときに、Application Configuration Service のバージョンを選択できます。 既定のバージョンは Gen1 です。 インスタンスの作成後に Gen2 にアップグレードすることもできますが、ダウングレードはサポートされていません。 アップグレードのダウンタイムはゼロですが、運用環境に移行する前にステージング環境でテストすることをお勧めします。

前提条件

Application Configuration Service の設定の管理

Application Configuration Service では、構成ファイルの格納には、Azure DevOps、GitHub、GitLab、および Bitbucket がサポートされています。

サービス設定を管理するには、[設定] セクションを開きます。 このセクションでは、次の重要な側面を構成できます。

  • 世代: サービスの世代をアップグレードします。
  • 更新間隔: サービスがどのくらいの頻度で Git リポジトリからの更新を確認するかを調整します。
  • リポジトリ: 新しいエントリを追加するか、既存のエントリを変更します。 この関数を使用すると、サービス モニターがどのリポジトリを使ってデータをプルするかを制御できます。

[設定] タブが強調表示された [Application Configuration Service] ページを示す Azure portal のスクリーンショット。

現在のサービス世代が Gen1 場合は、Gen2 にアップグレードしてパフォーマンスを向上させることができます。 詳細については、「Gen1 から Gen2 へのアップグレード」セクションを参照してください。

[更新間隔] では、リポジトリ内の更新を確認する頻度 (秒単位) を指定します。 最小値は 0 で、これにより自動更新が無効になります。 最適なパフォーマンスを得るには、この間隔を最小値の 60 秒に設定します。

次の表では、各リポジトリ エントリのプロパティについて説明します。

プロパティ 必須 説明
Name はい 各 Git リポジトリにラベル付けする一意の名前。
Patterns はい Git リポジトリ内で検索するパターン。 パターンごとに、{application}-{profile}.yml ではなく {application}{application}/{profile} などの形式を使います。 パターンはコンマで区切ります。 詳しくは、この記事の「パターン」セクションをご覧ください。
URI はい Git の URI (https://github.com/Azure-Samples/piggymetrics-configgit@github.com:Azure-Samples/piggymetrics-config など)
Label はい Git リポジトリ内で検索するブランチ名。
Search path いいえ Git リポジトリのサブディレクトリを検索するための、コンマで区切られた省略可能な検索パスです。

パターン

構成は、パターンで定義したものを使って、Git バックエンドからプルされます。 パターンは、以下のガイドラインで説明するように、{application}/{profile} の組み合わせです。

  • {application} - 構成を取得するアプリケーションの名前。 値 application は、既定のアプリケーションと見なされ、複数のアプリケーション間で共有される構成情報が含まれます。 それ以外の値は、特定のアプリケーションを参照し、特定のアプリケーションと、既定のアプリケーションの共有プロパティの、両方のプロパティが含まれます。
  • {profile} - 省略可能。 プロパティを取得できるプロファイルの名前。 空の値または値 default は、すべてのプロファイルで共有されているプロパティを含みます。 既定値以外の値では、指定したプロファイルのプロパティと、既定のプロファイルのプロパティが含まれます。

認証

次のスクリーンショットは、Application Configuration Service によってサポートされている 3 種類のリポジトリ認証を示しています。

[認証の種類] メニューが強調表示されている [Application Configuration Service] ページを示す Azure portal のスクリーンショット。

次の一覧では、3 種類の認証について説明します。

  • パブリック リポジトリ。

    パブリック リポジトリを使用する場合、追加の認証構成は一切必要ありません。 [認証] フォームで [パブリック] を選びます。

    次の表では、パブリック Git リポジトリを設定する際に使用できる構成可能なプロパティを示します。

    プロパティ 必須 説明
    CA certificate いいえ Git リポジトリ URL に対して自己署名証明書が使用される場合にのみ必要です。
  • 基本認証を使用したプライベート リポジトリ。

    次の表では、基本認証でプライベート Git リポジトリを設定する際に使用できる構成可能なプロパティを示します。

    プロパティ 必須 説明
    username はい リポジトリへのアクセスに使用するユーザー名。
    password はい リポジトリへのアクセスに使用するパスワード。
    CA certificate いいえ Git リポジトリ URL に対して自己署名証明書が使用される場合にのみ必要です。
  • SSH 認証を使用したプライベート リポジトリ。

    次の表では、SSH でプライベート Git リポジトリを設定する際に使用できる構成可能なプロパティを示します。

    プロパティ 必須 説明
    Private key はい Git ユーザーを識別する秘密キー。 パスフレーズ (暗号化された秘密キー) はサポートされていません。
    Host key いいえ (Gen1 の場合)
    はい (Gen2 の場合)
    Git サーバーのホスト キー。 コマンド ラインで Git を介してサーバーに接続する場合、ホスト キーは ssh/known_hosts ファイルにあります。 アルゴリズム プレフィックスは Host key algorithm で指定するため、含めないでください。
    Host key algorithm いいえ (Gen1 の場合)
    はい (Gen2 の場合)
    hostKey のアルゴリズム: ssh-dssssh-rsaecdsa-sha2-nistp256ecdsa-sha2-nistp384、および ecdsa-sha2-nistp521 いずれかです (Host key を指定する場合は必須)。
    Strict host key checking いいえ 指定された Host key を使用しているときにエラーが発生した場合に、バックエンドを無視するかどうかを示す省略可能な値。 有効値は true または false です。 既定値は true です。

ターゲット URI へのアクセスを検証するには、[検証] を選択します。 検証が正常に完了したら、[適用] を選択して構成設定を更新します。

Gen1 から Gen2 へのアップグレード

Application Configuration Service Gen2 では、多数の構成ファイルがある場合は特に、Gen1 に比べてパフォーマンスが向上します。 特に Gen1 は間もなく廃止されるため、Gen2 を使用することをお勧めします。 Gen1 から Gen2 へのアップグレードではダウンタイムは発生しませんが、運用環境に移行する前にステージング環境でテストすることをお勧めします。

Gen2 では、SSH 認証を使用する場合に Gen1 よりも多くの構成プロパティが必要です。 Gen2 で動作させるには、アプリケーションの構成プロパティを更新する必要があります。 次の表は、SSH 認証を使用する場合に Gen2 で必要なプロパティを示しています。

プロパティ 説明
Host key Git サーバーのホスト キー。 コマンド ラインで Git を介してサーバーに接続する場合、ホスト キーは ssh/known_hosts ファイルにあります。 アルゴリズム プレフィックスは Host key algorithm で指定するため、含めないでください。
Host key algorithm hostKey 用のアルゴリズム: ssh-dssssh-rsaecdsa-sha2-nistp256ecdsa-sha2-nistp384、または ecdsa-sha2-nistp521 いずれかです

Gen1 から Gen2 にアップグレードするには、次の手順に従います。

  1. Azure portal で、Azure Spring Apps サービス インスタンスの [Application Configuration Service] ページに移動します。

  2. [設定] セクションを選択し、[世代] ドロップダウン メニューで [Gen2] を選択します。

    [設定] タブに [世代] メニューが開かれている [Application Configuration Service] ページを示す Azure portal のスクリーンショット。

  3. ターゲット URI へのアクセスを検証するには、[検証] を選択します。 検証が正常に完了したら、[適用] を選択して構成設定を更新します。

    [Application Configuration Service] ページと [検証] ボタンが強調表示されている [設定] タブを示す Azure portal のスクリーンショット。

多言語サポート

Application Configuration Service は、Spring Boot アプリケーションとシームレスに連携します。 サービスによって生成されたプロパティは、Spring Boot により外部構成としてインポートされ、Beans に挿入されます。 追加のカスタム コードを作成する必要はありません。 @Value 注釈を使用して、Spring の環境抽象化によりアクセスして値を使用することも、@ConfigurationProperties 注釈を使用して構造化オブジェクトにバインドすることもできます。

Application Configuration Service では、dotNET、Go、Python などの多言語アプリもサポートされています。 アプリでの多言語アプリのデプロイ時に読み込むように指定する構成ファイルにアクセスするには、AZURE_SPRING_APPS_CONFIG_FILE_PATH などの名前の環境変数を使用して取得できるファイル パスにアクセスします。 そのパスの下にある、目的とするすべて構成ファイルにアクセスできます。 構成ファイル内のプロパティ値にアクセスするには、そのアプリ用の既存の読み取り/書き込みファイル ライブラリを使用します。

更新戦略

Git リポジトリで構成を変更してコミットすると、その変更がアプリケーションに反映される前に、いくつかの手順が実行されます。 これは自動化されたプロセスですが、次に示す個別のステージとコンポーネントが含まれており、それぞれに独自のタイミングと動作があります。

  • Application Configuration Service によるポーリング: Application Configuration Service では、バックエンド Git リポジトリが定期的にポーリングされ、変更が検出されます。 このポーリングは、更新間隔で定義された設定済みの頻度で行われます。 変更が検出されると、Application Configuration Service によって Kubernetes ConfigMap が更新されます。
  • ConfigMap の更新と kubelet キャッシュの操作: Azure Spring Apps では、この ConfigMap が、データ ボリュームとして、関連するアプリケーションにマウントされます。 ただし、このプロセスでは、ConfigMap の変更を認識するためのキャッシュの更新が kubelet によって頻繁に行われるため、自然な遅延が発生します。
  • アプリケーションによる更新済み構成の読み取り: Azure Spring Apps 環境で実行されているアプリケーションは、更新された構成値にアクセスできます。 Spring Context の既存の Beans が、更新された構成を使用するよう自動更新されることはありません。

これらのステージを次の図にまとめます。

Application Configuration Service の更新プロセスのライフサイクルを示す図。

特定のニーズに合わせて、Application Configuration Service のポーリング更新間隔を調整できます。 更新された構成をアプリケーションに適用するには、再起動または更新アクションが必要です。

Spring アプリケーションでは、プロパティが Spring Context 内で保持されるか、Beans として参照されます。 新しい構成を読み込むには、次の方法を使用することを検討してください。

  • アプリケーションを再起動します アプリケーションを再起動すると、常に新しい構成が読み込まれます。

  • 構成クライアントで公開されている /actuator/refresh エンドポイントをSpring Actuator 経由で呼び出します。

    この方法を使用するには、構成クライアントの pom.xml ファイルに次の依存関係を追加します。

    <dependency>
       <groupId>org.springframework.boot</groupId>
       <artifactId>spring-boot-starter-actuator</artifactId>
    </dependency>
    

    また、次の構成を追加することで、アクチュエータ エンドポイントを有効にすることもできます。

    management.endpoints.web.exposure.include=refresh, bus-refresh, beans, env
    

    /actuator/refresh エンドポイントを呼び出してプロパティ ソースを再度読み込むと、注釈 @Value が指定された Bean の @RefreshScope とバインドされている属性が更新されます。

    @Service
    @Getter @Setter
    @RefreshScope
    public class MyService {
       @Value
       private Boolean activated;
    }
    

    次の例に示すように、新しい構成を更新するには、アプリケーション エンドポイントで curl を使います。

    curl -X POST http://{app-endpoint}/actuator/refresh
    
  • FileSystemWatcher を使用して、ファイルの変更を監視し、必要に応じてコンテキストを更新します。 FileSystemWatcherspring-boot-devtools に付属するクラスであり、特定のディレクトリでファイルの変更を監視します。または、同様の機能を持つ別のユーティリティを使用することもできます。 前のオプションでは、ユーザーが更新をアクティブに開始する必要があります。一方、後者ではファイルの変更を監視でき、更新が検出されると、自動的に最新の情報に更新されます。 ファイル パスを取得するには、「多言語サポート」セクションで説明されているように、環境変数 AZURE_SPRING_APPS_CONFIG_FILE_PATH を使用します。

Application Configuration Service の設定を構成する

次の手順を使用して、Application Configuration Service を構成します。

  1. [Application Configuration Service](Application Configuration Service) を選択します。

  2. [概要] を選択して、実行状態と、Application Configuration Service に割り当てられているリソースを表示します。

    [概要] タブが強調表示された [Application Configuration Service] ページを示す Azure portal のスクリーンショット。

  3. [設定] を選択し、Git バックエンド情報を使用して新しいエントリを [リポジトリ] セクションに追加します。

  4. ターゲット URI へのアクセスを検証するには、[検証] を選択します。 検証が正常に完了したら、[適用] を選択して構成設定を更新します。

    [設定] タブと [検証] ボタンが強調表示された [Application Configuration Service] ページを示す Azure portal のスクリーンショット。

Gen2 の自己署名証明書を使用して Git バックエンドにアクセスするために TLS 証明書を構成する

この手順は必須ではありません。 Git バックエンドに自己署名証明書を使用する場合は、Git バックエンドにアクセスするために TLS 証明書を構成する必要があります。

最初に証明書を Azure Spring Apps にアップロードする必要があります。 詳細については、「Azure Spring Apps のアプリケーションで TLS/SSL 証明書を使用する」の「証明書をインポートする」セクションを参照してください。

TLS 証明書を構成するには、次の手順に従います。

  1. サービス リソースに移動し、[Application Configuration Service] を選択します。

  2. [設定] を選択し、Git バックエンド情報を使用して新しいエントリを [リポジトリ] セクションに追加またはアップロードします。

    [設定] タブが表示された [Application Configuration Service] ページを示す Azure portal のスクリーンショット。

アプリケーションで Application Configuration Service を使用する

Git バックエンドで Application Configuration Service を使い、一元的な構成を使うときは、アプリを Application Configuration Service にバインドする必要があります。

アプリケーションで Application Configuration Service を使用するには、次の手順を使用します。

  1. [App binding]\(アプリ バインド\) タブを開きます。

  2. [アプリのバインド] を選択し、ドロップダウンから 1 つのアプリを選択します。 [適用] を選択してバインドします。

    [アプリのバインド] タブが強調表示されている [Application Configuration Service] ページを示す Azure portal のスクリーンショット。

    Note

    バインドとバインド解除の状態を変更したときは、アプリを再起動または再デプロイしてバインドを有効にする必要があります。

  3. ナビゲーション メニューで [アプリ] を選択して、すべてのアプリを一覧表示します。

  4. 対象のアプリを選択して、name 列のパターンを構成します。

  5. ナビゲーション ペインで [構成] を選択し、[全般設定] を選択します。

  6. [構成ファイルのパターン] ドロップダウンで、一覧から 1 つ以上のパターンを選択します。 詳細については、「パターン」を参照してください。

    [全般設定] タブと api-gateway オプションが強調表示されたアプリの [構成] ページを示す Azure portal のスクリーンショット。

  7. [保存] を選択します。

アプリケーションを Application Configuration Service にバインドする

新しいアプリを作成するときに、アプリケーションを Application Configuration Service にバインドすることを選択できるようになりました。

新しいアプリを作成し、Application Configuration Service にバインドするには、次の手順に従います。

  1. ナビゲーション ウィンドウで、[アプリ] を選択して、すべてのアプリを表示します。

  2. [アプリの作成] を選択して、新しいアプリを作成します。

  3. 新しいアプリの名前を入力します。

  4. [バインド] タブを選択し、ドロップダウンから [Application Configuration Service] を選択します。

    [バインド] ドロップダウンが強調表示された [アプリの作成] ページを示す Azure portal のスクリーンショット。

  5. [作成] を選択してアプリの作成を完了し、Application Configuration Service にバインドします。

サービスの作成後に Application Configuration Service を有効化または無効化する

サービスの作成後に、Azure portal または Azure CLI を使用して、Application Configuration Service を有効化または無効化することができます。 Application Configuration Service を無効にする前に、すべてのアプリのバインドを解除する必要があります。

Application Configuration Service を有効化または無効化するには、次の手順に従います。

  1. サービス リソースに移動し、[Application Configuration Service] を選択します。
  2. [管理] を選択します。
  3. [Application Configuration Serviceの有効化] を選択または選択解除し、[保存] を選択します。
  4. [Application Configuration Service] ページで、アプリケーション構成サービス の状態を表示できるようになりました。

ConfigMap で構成ファイルを調べる

次のセクションでは、関連する Kubernetes ConfigMap のアップストリーム Git リポジトリから Application Configuration Service によってプルされた構成ファイルの内容を確認する方法を紹介します。 詳細については、この記事の 「更新戦略」セクションを参照してください。

Azure ロールを割り当てる

まず、Azure ロール Azure Spring Apps Application Configuration Service Config File Pattern Reader Role が割り当てられている必要があります。

次の手順で Azure ロールを割り当てます。

  1. Azure portal を開き、Azure Spring Apps サービス インスタンスに移動してください。

  2. ナビゲーション ウィンドウで [アクセスの制御 (IAM)] を選んでください。

  3. [アクセスの制御 (IAM)] ページで [追加] を選び、[ロールの割り当ての追加] を選んでください。

    [ロールの割り当ての追加] オプションが強調表示されている Azure Spring Apps インスタンスの [アクセス制御 (IAM)] ページを示す Azure portal のスクリーンショット。

  4. [ロールの割り当ての追加] ページの [名前] の一覧で、ターゲット ロールを検索して選び、[次へ] を選んでください。

    Azure Spring Apps Application Configuration Service 構成ファイル パターン閲覧者ロールの名前が強調表示されている、Azure Spring Apps インスタンスの [ロールの割り当ての追加] ページを示す Azure portal のスクリーンショット。

  5. [メンバー] を選び、自分のユーザー名を検索して選んでください。

  6. [レビューと割り当て] を選択します。

Azure CLI を使用して構成ファイルを調べる

次のコマンドを使用して、パターン別に構成ファイルの内容を表示します。

az spring application-configuration-service config show \
    --resource-group <resource-group-name> \
    --service <Azure-Spring-Apps-instance-name> \
    --config-file-pattern <pattern>

このコマンドでは、次の例のような JSON 出力が生成されます。

{
  "configurationFiles": {
    "application.properties": [
      "example.property.application.name: example-service",
      "example.property.cloud: Azure"
    ]
  },
  "metadata": {
    "gitRevisions": "[{\"url\":\"{gitRepoUrl}\",\"revision\":\"{revisionInfo}\"}]"
  }
}

Note

metadata プロパティと gitRevisions プロパティは、Gen1 バージョンの Application Configuration Service では使用できません。

このコマンドを --export-path {/path/to/target/folder} パラメーターと共に使用して、構成ファイルを指定したフォルダーにエクスポートすることもできます。 相対パスと絶対パスの両方をサポートしています。 パスを指定しない場合、コマンドは既定で現在のディレクトリのパスを使用します。

アプリで構成ファイルを調べる

この記事の「アプリケーションで Application Configuration Service を使用する」セクションで説明されているように、アプリを Application Configuration Service にバインドし、アプリのデプロイのパターンを設定した後、パターンの構成ファイルを含む ConfigMap をアプリケーション コンテナーにマウントする必要があります。 アプリのデプロイの各インスタンスの構成ファイルを確認するには、次の手順に従います。

  1. いずれかのアプリケーション インスタンスに接続してください。 詳細については、「トラブルシューティングのためにアプリ インスタンスに接続する」を参照してください。

  2. echo $AZURE_SPRING_APPS_CONFIG_FILE_PATH コマンドを使用して、構成ファイルを含むフォルダーを検索してください。 次の例に示すように、場所の一覧はコンマで区切って表示されます。

      $ echo $AZURE_SPRING_APPS_CONFIG_FILE_PATH
      /etc/azure-spring-cloud/configmap/acs-default-payment-default-e9d46,/etc/azure-spring-cloud/configmap/acs-default-catalog-default-616f4
    
  3. cat などのコマンドを使用して、構成ファイルの内容を確認してください。

Note

Git リビジョン情報は、アプリでは使用できません。

ログを確認する

次のセクションでは、Azure CLI または Azure portal を使用してアプリケーション ログを表示する方法について説明します。

リアルタイム ログ ストリーミングを使用する

Azure CLI を使用して、ログをリアルタイムでストリーミングできます。 詳細については、「Azure Spring Apps のマネージド コンポーネント ログをリアルタイムでストリーミングする」を参照してください。 次の例は、Azure CLI コマンドを使用して、application-configuration-serviceflux-source-controllerの サブコンポーネントに対する新しいログを継続的にストリーミングする方法を示しています。

次のコマンドを使用して、application-configuration-service に対するログをストリーミングします。

az spring component logs \
    --resource-group <resource-group-name> \
    --service <Azure-Spring-Apps-instance-name> \
    --name application-configuration-service \
    --all-instances \
    --follow

次のコマンドを使用して、flux-source-controller に対するログをストリーミングします。

az spring component logs \
    --resource-group <resource-group-name> \
    --service <Azure-Spring-Apps-instance-name> \
    --name flux-source-controller \
    --all-instances \
    --follow

Log Analytics の使用

次のセクションでは、Log Analytics を使用してシステム ログを有効にして表示する方法について説明します。

Log Analytics の診断設定

Application Configuration Service のログを照会する前に、システム ログを有効にして Log Analytics インスタンスにログを送信する必要があります。 Azure portal でシステム ログを有効にするには、次の手順を使用します。

  1. Azure Spring Apps インスタンスを開きます。

  2. ナビゲーション ウィンドウで [診断設定] を選択します。

  3. [診断設定の追加] を選択するか、既存の設定の [設定の編集] を選択します。

  4. [ログ] セクションで、[システム ログ] カテゴリを選択します。

  5. [宛先の詳細] セクションで、[Log Analytics ワークスペースに送信] を選択し、ワークスペースを選択します。

  6. [保存] を選択して設定を更新します。

[Log Analytics] でログを確認する

Azure portal を使用して application-configuration-serviceflux-source-controller についてのログを確認するには、次の手順を使用します。

  1. [システム ログ] をオンにしたことを確認します。 詳細については、「Log Analytics の診断設定」セクションを参照してください。

  2. Azure Spring Apps インスタンスを開きます。

  3. ナビゲーション メニューで [ログ] を選択し、[概要] を選択します。

  4. クエリ編集ウィンドウで、次のサンプル クエリを使用します。 時間範囲を調整し、[実行] を選択してログを検索します。

    • application-configuration-service についてのログを表示するには、次のクエリを使用します。

      AppPlatformSystemLogs
      | where LogType in ("ApplicationConfigurationService")
      | project TimeGenerated , ServiceName , LogType, Log , _ResourceId
      | limit 100
      

      application-configuration-service のログのクエリ結果を示す Azure portal のスクリーンショット。

    • flux-source-controller についてのログを表示するには、次のクエリを使用します。

      AppPlatformSystemLogs
      | where LogType in ("Flux")
      | project TimeGenerated , ServiceName , LogType, Log , _ResourceId
      | limit 100
      

      flux-source-controller のログのクエリ結果を示す Azure portal のスクリーンショット。

Note

Log Analytics でログを使用できるようになるまで、数分の遅延が発生する可能性があります。

構成ファイルの Git リビジョンを調べる

パターン の構成ファイルの Git リビジョンは、Application Configuration Service のログにあります。 次のログ例は、payment/default パターンの構成ファイルが、https://github.com/Azure-Samples/acme-fitness-store-config リポジトリの main ブランチから example-commit-id と共にでプルされることを示しています。 ログに対してクエリを実行する方法については、「ログの確認」セクションを参照してください。

Applied ConfigMap ({config-map-name}) for content (payment/default) from Git repositories https://github.com/Azure-Samples/acme-fitness-store-config@main@sha1:{example-commit-id}

Azure CLI を使用して Git リビジョンを見つけることもできます。 詳細については、「Azure CLI を使用して構成ファイルを調べる」セクションを参照してください。

Note

Git リビジョンは、Gen1 バージョンの Application Configuration Service では使用できません。

既知の問題のトラブルシューティング

最新の変更がアプリケーションに反映されない場合は、「更新戦略」セクションに基づいて、次の項目を確認します。

  • 次の項目を確認して、Git リポジトリが正しく更新されていることを確かめます。
    • 必要な構成ファイルの変更のブランチが更新されていることを確認します。
    • Application Configuration Service で構成されたパターンが、更新された構成ファイルと一致することを確認します。
    • アプリケーションが Application Configuration Service にバインドされていることを確認します。
  • 構成ファイルの Git リビジョンを調べる」セクションの説明に従って、Application Configuration Service が正しい Git リビジョンを使用していることを確認します。
  • この記事の「ConfigMap で構成ファイルを調べる」で説明されているように、アプリケーションで使用されるパターンの構成ファイルを含む ConfigMap が更新されていることを確認します。 更新されていない場合は、チケットを発行します。
  • この記事の「アプリで構成ファイルを調べる」セクションに説明されているように、ConfigMap がファイルとしてマウントされていることを確認します。 ファイルが更新されない場合は、Kubernetes の更新間隔の時間 (1 分) だけ待つか、アプリケーションを再起動して強制的に更新します。

これらの項目を確認したら、アプリケーションで、更新された構成を読み取れるようになるはずです。 アプリケーションがまだ更新されていない場合は、チケットを発行してください。

Azure Spring Apps