App Service for Linux における Sidecar パターンの Tips

Last updated at 2024-12-09Posted at 2024-11-26

はじめに

この記事では、App Service for Linux において、サイドカーを導入して、下記の観点を確認します。

ログはどう出力されるのか
Web SSH できるのか
再起動はコンテナ単位で行われるのか
環境変数(アプリケーション設定)は反映されるのか
ボリュームはマウントされるのか
VNet 統合はサイドカーコンテナにも適用されるのか
Managed ID は利用できるのか
Dapr は利用できるのか

なお、あくまでも現時点で実際に動作させてみて分かったことベースでの記載となります。
将来的に動作が変わる可能性があることはご承知おきください。

TL;DR

No	確認項目	結果	備考
1	サイドカーのログはどう出力されるのか	▲	各コンテナからの出力がまざる。正直標準のApp Service ログをつかうのは厳しそう
2	サイドカーに対して SSH 接続できるのか	〇	main コンテナを踏み台にして各サイドカーに SSH 接続可能。仕組みからできそうなことは推測はできるがDocは欲しいですね。
3	サイドカーに対して正常性チェックできるのか	×	main コンテナに対する http pingのみ。各コンテナに対する正常性プローブのような機能はない
4	コンテナ単位で再起動できるか	×	全てのコンテナのライフサイクルは同じ
5	サイドカーに環境変数(アプリケーション設定)は反映されるのか	〇	デフォルトでは設定されないが継承可能。これは Doc がないと困る
6	ボリュームはマウントされるのか	〇	通常の App Service と同様に利用可能
7	VNet 統合はサイドカーコンテナにも適用されるのか	〇	通常の App Service と同様に利用可能
8	Managed ID は利用できるのか	〇	通常の App Service と同様に利用可能
9	Dapr は利用できるのか	▲	利用できるが、いろいろ工夫が必要 & Dapr 本来のパワー全てを発揮できなそう

祝 🎉 Sidecars for Azure App Service for Linux GA 🍺

Samples

すぐに動かせるサンプルはすでにいくつか公開されています。

公式ドキュメントとしても以下のチュートリアルページがあります。

動かしてみるだけなら、上記の記事をトレースするだけなので、先に挙げた疑問点を掘り下げていきます。

それ Container Apps でやれるのでは ? という疑問がちらつきますが、せっかくなのでいろいろ試してみます。

お題

Container Apps に寄せてみたいなと思ったので、Envoy と Dapr を使ってみましょう。

リバースプロキシとしてEnvoyコンテナを用意します。
App Serviceのリクエストを受け付けるコンテナとなるため、これを main コンテナとします。
アプリケーションバックエンドとしてNodeアプリを backend コンテナとします。
backend コンテナ用の dapr コンテナを用意して、ConfigStore として、App Configuration を用います。
また、App Service そのものに対しては、SystemManaged Identity を付与、VNet 統合を行い、ついでの BYOS もつけておきます。

Q1.ログがどう出るのか

A. mainコンテナとサイドカーコンテナで混ざります。

各コンテナからの標準/エラー出力は YYYY_MM_DD_<MACHINAME>_default_docker.log にまとめられるようです。
同様に AppServiceConsoleLogs も同様です。

下記、mainコンテナ(Envoy)の出力とバックエンドアプリ(Node,Hono)の出力が1つのファイルにマージされている様子です。正直言ってこれは結構つらいですね。。。

Application Insights については未確認ですが、同じ AI に対して複数のデータソースからデータを入れるということで工夫は可能と考えています。分散トレースとかできそうな予感。

Q2.Web SSH できるのか

A. サイドカーにも SSH 接続できます。ただしちょっとしたセットアップが必要。

Kudu からの Web SSH は main コンテナに対して行われます。
すなわち main コンテナに対しては標準的な sshd のセットアップを行っておけばいつも通り接続できます。

SSH を有効にする

サイドカーコンテナに対しては、main コンテナを踏み台としてそこから SSH することで接続可能です。
そのためには、サイドカーコンテナで sshd が listen するポートを 2222 と被らないようにする必要があります。
下記例では、サイドカーコンテナの sshd は 2223 ポートを利用するように構成してあり、Kudu から一度 main コンテナへ接続後に、ssh コマンドでサイドカーコンテナに接続した様子です。

Q3. Haalth Check は利用できるのか

A. App Serviceのヘルスチェックは利用可能。
すなわち main コンテナに対する http ping のみ。

Container Apps における、正常性プローブに該当する機能はいまのところない。

以下の通り、ポータルには Status という項目があるので将来に期待したいところ。

Q4.コンテナ単位で再起動できるのか

A. コンテナ単位で再起動はできません。

各コンテナは一心同体のようで、どれかだけ一時的な停止や再起動といったことはできなそうです。
ポータルからリソースに対する停止、再起動操作は全てのコンテナに対して行われます。
なお、ポータルからのコンテナ構成更新時は以下の API を呼び出しているようです。

各コンテナの設定を変えたり、Web SSH 経由でプロセスKillしてコンテナを終了させた場合なども、
他のコンテナに対しては SIGTERM が送られることになり、すべてのコンテナが再起動されます。

例えば以下では /crash にリクエストがあった場合に、backendコンテナは終了するようにしています。

そのとき、main コンテナである envoy 側のログとして、SIGTERM が送られていることが確認できます。

Q5. 環境変数(アプリケーション設定)は反映されるのか

A. デフォルトでは main コンテナ以外には設定されません。properties.inheritAppSettingsAndConnectionStrings を true にすると設定されます。

2024/11/20 時点では以下のように書かれていますが、entroypoint.sh で printenvした結果 main コンテナと backend コンテナでは設定されている環境変数に違いが確認できました。

You configure environment variables for the containers like any App Service app, by configuring app settings. The app settings are accessible to all the containers in the app.

確認用の entrypoint.shは以下のとおりです。

main 側

backend 側

APPSETTING_ prefix が付いたものおよび、myEnvVarがサイドカーには設定されていないですね。ただし、IDENTITY_ENDPOINT など一部は設定されているようです。

じゃあどうするのと色々APIを試していった結果、Web Apps - Get Site Container APIの応答に、inheritAppSettingsAndConnectionStringsというパラメータが false で設定されているのが見つかりました。Definition にも記載がないですが名前的にこれっぽいですね。
試しにこれを true にして Create Or Update Site Container| Microsoft Learn　を呼び出してみました。