チュートリアル: Azure App Service でカスタム コンテナーのサイドカー コンテナーを構成する

このチュートリアルでは、OpenTelemetry コレクターをサイドカー コンテナーとして Azure App Service の Linux カスタム コンテナー アプリに追加します。 独自のコードを使用する Linux アプリについては、「チュートリアル: Azure App Service で Linux アプリのサイドカー コンテナーを構成する」を参照してください。

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

サイドカー コンテナーとは？

Azure App Service では、Linux アプリごとに最大 9 つのサイドカー コンテナーを追加できます。 サイドカー コンテナーを使用すると、メイン コンテナー (組み込みまたはカスタム) に緊密に結合することなく、追加のサービスと機能を Linux アプリにデプロイできます。 たとえば、監視、ログ、構成、ネットワーク サービスをサイドカー コンテナーとして追加できます。 OpenTelemetry コレクターのサイドカーは、このような監視例の 1 つです。

サイドカー コンテナーは、同じ App Service プランのメイン アプリケーション コンテナーと共に実行されます。

1.必要なリソースを設定する

最初に、チュートリアルで使用するリソースを作成します。 これらはこの特定のシナリオで使用され、一般的にサイドカー コンテナーには必要ありません。

1. Azure Cloud Shell で次のコマンドを実行します。

   git clone https://github.com/Azure-Samples/app-service-sidecar-tutorial-prereqs
   cd app-service-sidecar-tutorial-prereqs
   azd env new my-sidecar-env
   azd provision
   

2. ダイアログが表示されたら、必要なサブスクリプションとリージョンを指定します。 次に例を示します。

   • [サブスクリプション]: 自分のサブスクリプション。
   • リージョン: "(ヨーロッパ) 西ヨーロッパ"。

   デプロイが完了すると、次の出力が表示されます。

    APPLICATIONINSIGHTS_CONNECTION_STRING = InstrumentationKey=...;IngestionEndpoint=...;LiveEndpoint=...
   
    Open resource group in the portal: https://portal.azure.com/#@/resource/subscriptions/.../resourceGroups/...
    

3. ブラウザー タブでリソース グループのリンクを開きます。この接続文字列は後で使用する必要があります。

   注

   azd provision は、付属のテンプレートを使用して、次の Azure リソースを作成します。

   • my-sidecar-env_group というリソース グループ。
   • 2 つのイメージがデプロイされたコンテナー レジストリ。
     • OpenTelemetry モジュールを含む Nginx イメージ。
     • Azure Monitor にエクスポートするように構成された OpenTelemetry コレクター イメージ。
   • ログ分析ワークスペース
   • Application Insights コンポーネント

2.サイドカー対応アプリを作成する

1. リソース グループの管理ページで、[作成] を選択します。

2. Web アプリを検索し、[作成] で下矢印 選択し、[Web アプリ] を選択します。

   

3. [基本] パネルを次のように構成します。

   • 名前: 一意の名前
   • 公開: コンテナー
   • オペレーティング システム: Linux
   • リージョン: azd provision で選択したのと同じリージョン
   • Linux プラン: 新しい App Service プラン

   

4. [コンテナー] を選択します。 [コンテナー] パネルを次のように構成します。

   • サイドカー サポート: 有効
   • イメージ ソース: Azure Container Registry
   • レジストリ: azd provision によって作成されたレジストリ
   • イメージ: nginx
   • タグ: latest
   • ポート: 80

   

   注

   これらの設定は、サイドカー対応アプリでは異なる方法で構成されます。 詳細については、 サイドカー対応カスタム コンテナーの違いを参照してください。

5. [Review + create](確認と作成) を選択し、次に [作成] を選択します。

6. デプロイが完了したら、[リソースに移動] を選択します。

7. 新しいブラウザー タブで、https://<app-name>.azurewebsites.net に移動し、既定の Nginx ページを表示します。

3.サイドカー コンテナーを追加する

このセクションでは、サイドカー コンテナーをカスタム コンテナー アプリに追加します。

1. アプリの管理ページで、左側のメニューから [デプロイ センター] を選びます。

   デプロイ センターに、アプリ内のすべてのコンテナーが表示されます。 現時点では、メイン コンテナーのみがあります。

2. [追加] を選択し、次のように新しいコンテナーを構成します。

   • 名前: otel-collector
   • イメージ ソース: Azure Container Registry
   • レジストリ: azd provision によって作成されたレジストリ
   • イメージ: otel-collector
   • タグ: latest

3. 適用を選択します。

   

   これで、デプロイ センターに 2 つのコンテナーが表示されます。 メイン コンテナーにはメインのマークが付けられ、サイドカー コンテナーにはサイドカーのマークが付けられます。 各アプリで使用できるメイン コンテナーは 1 つですが、複数のサイドカー コンテナーを持つことができます。

4.環境変数を構成する

サンプル シナリオでは、otel-collector サイドカーは OpenTelemetry データを Azure Monitor にエクスポートするように構成されていますが、環境変数として接続文字列が必要です (「otel-collector イメージ の OpenTelemetry 構成ファイル」参照)。

通常の App Service アプリと同じようにコンテナーの環境変数を構成するには、アプリ設定を構成します。 アプリ設定は、アプリ内のすべてのコンテナーからアクセスできます。

1. アプリの管理ページで、左側のメニューから [環境変数] を選択します。

2. [追加] を選択してアプリ設定を追加し、次のように構成します。

   • 名前: APPLICATIONINSIGHTS_CONNECTION_STRING
   • [値]: azd provision の出力内の接続文字列。 Cloud Shell セッションが失われた場合は、Application Insight リソースの [概要] ページの [接続文字列] で確認することもできます。

3. [適用]、[適用]、[確認] の順に選択します。

   

5.Application Insights での検証

otel-collector サイドカーにより、Application Insights にデータがエクスポートされているはずです。

1. https://<app-name>.azurewebsites.net のブラウザー タブに戻り、ページを数回更新して、いくつかの Web 要求を生成します。

2. リソース グループの概要ページに戻り、Application Insights リソースを選択します。 既定のグラフにいくつかのデータが表示されるはずです。

   

リソースをクリーンアップする

この環境が必要なくなったら、リソース グループ、App Service、およびすべての関連リソースを削除できます。 複製されたリポジトリで、Cloud Shell で次のコマンドを実行するだけです。

azd down

よく寄せられる質問

• サイドカー対応カスタム コンテナーの違いは何ですか?
• サイドカー コンテナーでは内部通信をどのように処理しますか?
• サイドカー コンテナーはインターネット要求を受信できますか?

サイドカー対応カスタム コンテナーの違いは何ですか?

サイドカー対応アプリは、サイドカー対応ではないアプリとは異なる方法で構成します。

サイドカー非対応

• コンテナー名と型は、 LinuxFxVersion=DOCKER|<image-details> を使用して直接構成されます ( az webapp config set --linux-fx-version を参照)。
• メイン コンテナーは、次のようなアプリ設定で構成されます。
  • DOCKER_REGISTRY_SERVER_URL
  • DOCKER_REGISTRY_SERVER_USERNAME
  • DOCKER_REGISTRY_SERVER_PASSWORD
  • WEBSITES_PORT

サイドカー対応

• サイドカー対応アプリは、 LinuxFxVersion=sitecontainers によって指定されます ( az webapp config set --linux-fx-version を参照)。
• メイン コンテナーは 、sitecontainers リソースで構成されます。 これらの設定は、サイドカー対応アプリには適用されません
  • DOCKER_REGISTRY_SERVER_URL
  • DOCKER_REGISTRY_SERVER_USERNAME
  • DOCKER_REGISTRY_SERVER_PASSWORD
  • WEBSITES_PORT

サイドカー コンテナーでは内部通信をどのように処理しますか?

サイドカー コンテナーではメイン コンテナーと同じネットワーク ホストが共有されるため、メイン コンテナー (および他のサイドカー コンテナー) は、localhost:<port> を使用してサイドカー上の任意のポートに到達できます。 例の startup.sh では、localhost:4318 を使用して otel-collector サイドカーのポート 4318 にアクセスします。

[コンテナーの編集] ダイアログの [ポート] ボックスは、現在 App Service では使用されていません。 これは、サイドカーがリッスンしているポートを示すなど、サイドカー メタデータの一部として使用できます。

サイドカー コンテナーはインターネット要求を受信できますか?

いいえ。 App Service は、インターネット要求をメイン コンテナーにのみルーティングします。 コードベースの Linux アプリの場合、組み込みの Linux コンテナーがメイン コンテナーであり、を使用してサイドカー コンテナー (IsMain=false) を追加する必要があります。 カスタム コンテナーの場合、 サイトコンテナー の 1 つを除くすべてのコンテナーに IsMain=falseが必要です。

IsMainの構成の詳細については、Microsoft.Web サイト/サイトコンテナーを参照してください。

ボリューム マウントを使用する方法

ボリューム マウント機能を使用すると、Web アプリ内のコンテナー間で非永続的なファイルとディレクトリを共有できます。

ボリューム サブパス: これは、自動的に作成され、コンテナー内で参照されない論理ディレクトリ パスです。 同じボリューム サブ パスで構成されているコンテナーは、ファイルとディレクトリを相互に共有できます。

コンテナーのマウント パス: これは、コンテナー内で参照するディレクトリ パスに対応します。 コンテナーマウントパスはボリュームサブパスにマップされます。

たとえば、次のボリューム マウントが構成されているとします。

これらの設定に基づいて、次の条件が適用されます。

• Container1 が /container1Vol/myfile.txtを作成する場合、Container2 は /container2Vol/myfile.txtを介してファイルを読み取ることができます。
• Container1 が /container1Vol/directory3/myfile.txtを作成する場合、Container2 は /container2Vol/directory3/myfile.txtを 介してファイルを読み取ることができ、Container3 は /container3Vol/myfile.txtを介してファイルの読み取りと書き込みを行うことができます。
• Container4 は、他のどのコンテナーとも共通のボリューム マウントを共有しません。

その他のリソース

• カスタム コンテナーの構成
• REST API: Web Apps - サイト コンテナーの作成または更新
• コードとしてのインフラストラクチャ: Microsoft.Web サイト/sitecontainers
• GitHub Actions を使用してカスタム コンテナーをデプロイする