Azure Container Apps のよくあるご質問 (FAQ)

リストは、次の Azure CLI コマンドを実行することで生成できます。

  az provider show \
  --namespace Microsoft.App \
  --query "resourceTypes[?resourceType=='managedEnvironments'].locations"

いいえ。Azure Container Apps では、Kubernetes API への直接アクセスは提供されません。

はい。API Management のコンテキストから Azure Container Apps API をインポートできます。

課金は、CPU、メモリ、要求数などのリソース使用量に基づいています。 詳細については、 課金 ページを参照してください。

はい。 GitHub Actions は、Azure CLI または Azure portal を使用して構成できます。

• Azure CLI を使用して az containerapp github-action -h を実行し、オプションを確認します。

• Azure portal を使って、コンテナー アプリの下にある [継続的デプロイ] ウィンドウに移動します。

Azure Container Apps により URL はデコードされ、URL 混乱攻撃からアプリが保護されます。 http://mysite.com/archive/http%3A%2F%2Fmysite.com%2Farchive%2F123 のようにエンコードされた部分を含む要求 URL は、http://mysite.com/archive/http%3A/mysite.com/archive/123 としてアプリに送信されます。

従量課金のみの環境では、ユーザー定義ルート (UDR) のサポートが制限されています。 ExpressRoute はサポートされていません。 次のように構成すると、限られた UDR サポートを利用できます。

• ルートは、次ホップ = "インターネット" の Azure.<REGION_NAME> サービス タグを使用して定義する必要があります。

• 環境が正しく動作するように、NSG ドキュメントの説明に従ってネットワーク セキュリティ グループ ( NSG ) 規則も構成する必要があります。

これらの制限はワークロード プロファイルには適用されません。また、フル機能の UDR と Express Route のサポートでは、ワークロード プロファイル環境を使用します。

顧客データが、Azure Container Apps によって、デプロイされているリージョンの外部に移動または保存されることはありません。

Azure Container Apps をプロバイダーとして選択して、Azure portal でクォータの増加を要求します。

クォータの引き上げ要求を送信するときは、次の点を考慮してください。

• アプリのスケーリングと環境のスケーリング: 多くの異なるクォータを増やすことができます。 次の説明を使用して、ニーズの特定に役立てます。

  • 環境あたりのアプリ数とコア数の増加: 環境内で実行するアプリの数を増やしたり、より集中型のアプリを実行したりできます。 ワークロードで同じネットワークとセキュリティの境界内にデプロイできる場合に推奨されます。
  • 環境の増加: ワークロードにネットワークまたはセキュリティの境界が必要な場合に推奨されます。 注: 要求に環境レベルのクォータの引き上げが含まれる場合は、詳細なビジネス コンテキストが必要になることがあります。 リージョン環境クォータの変更を要求する場合は、対応するグローバル環境クォータの変更を要求する必要があります。

• リージョン: 増加要求の承認は、Azure リージョンで使用可能なコンピューティング容量によって異なります。

• 特定のコンピューティング要件: プラットフォームでは、コンテナー アプリあたり 4 GB がサポートされます。 メモリ制限のオーバーライドは、ケースごとに評価されます。

• スケーリングのビジネス上の理由: プラットフォームの制限によってワークロード要求がブロックされている場合は、クォータ引き上げ要求の対象になる可能性があります。 スケール制限のオーバーライドは、ケースごとに評価されます。

Dapr の各機能は、徹底的な評価を受けて、お客様による Azure Container Apps 環境でのマイクロサービスの実行によい影響をながら、可能な限り最高のエクスペリエンスを提供することが確認されています。

Dapr のアルファ API の可用性は保証されず、Microsoft でサポートされていません。

Tier 1 コンポーネントは完全にサポートされていますが、Tier 2 コンポーネントはベスト エフォートでサポートされています。 詳細情報。

機能要求は、Azure Container Apps GitHub リポジトリから提出できます。 機能要求のタイトルに必ず "Dapr" を含めてください。

1.13.6-msft.1 は運用リージョンへのロールアウト中であり、ユーザーによってはまだ以前のバージョン (1.12.5 や 1.12.5-msft.6 など) が表示される場合があります。 -msft.<number> サフィックスは、エクスペリエンスを強化するために Azure Container Apps に対して行われた特定のカスタマイズを示します。

Dapr バージョンは、安定性、徹底的なテスト、および顧客への影響の最小化に重点を置いて、ベスト エフォートベースで更新されます。 目標は、破壊的変更を導入することなく、更新プログラムがシームレスに統合されるようにすることです。

Dapr バージョンの更新プログラムは自動的に適用されるため、常に最も安全なバージョンの恩恵を受けることができます。 ただし、Azure Container Apps の Dapr は、新機能の固定リリース スケジュールに従っていません。 代わりに、新機能用の新しい Dapr バージョンのリリースは、Dapr バイナリの優先順位付けと安定性によって異なります。

GitHub の Azure Container Apps で Dapr の更新プログラムとリリースのお知らせを見つけます。

カスタム バージョンの選択はサポートされていません。 代わりに、環境は自動的にアップグレードされ、Azure Container Apps での Dapr のフル マネージドでサーバーレスのオファリングの整合性が維持されます。

Docker を使用しないデプロイでは、コードで Dockerfile を定義せずにアプリケーションをデプロイできます。 その代わりに、Container Apps クラウド ビルド機能では Buildpacks を使用して、ローカル コンピューター上のソース コードをコンテナー イメージに変換します。 このオプションでは、Azure Container Apps の既定のレジストリが使用されます。

Docker レスデプロイで既知の問題が発生しています。 再試行すると、この問題が解決する可能性があります。 この問題が発生した場合は、Microsoft のチームが調査できるように GitHub のイシュー をオープンしてください。

Azure Container Apps 上のすべての .NET アプリに対してデータ保護を有効にする必要があります。 詳細については、「Azure Container Apps での ASP.NET Core アプリのデプロイとスケーリング」を参照してください。

Container Apps では、JDK 8、JDK 11、JDK 17、JDK 21 の 4 つの LTS JDK バージョンがサポートされています。 ソース コード ビルドの場合、既定のバージョンは JDK 17 です。 JAR ファイルのビルドの場合、JDK のバージョンは JAR 内のファイルの場所 META-INF\MANIFEST.MF から読み取られますが、指定されたバージョンを使用できない場合は、既定の JDK バージョン 17 が使われます。

ビルド環境変数を使用して既定のバージョンをオーバーライドするように JDK バージョンを構成できます。

Azure Container Apps では現在、Java ビルド ツールとして Apache Maven がサポートされています。

ビルド環境変数を使用して Java イメージ ビルドをカスタマイズできます。

注: Docker を使用しないコード ベースと組み合わせて containerapp up を使用する場合は、--___location パラメーターを使用して、アプリケーションが米国東部以外の場所で実行されるようにします。

コンテナー イメージに latest などの静的タグを使用しないでください。 静的タグを使用すると、キャッシュの問題が発生し、アプリのトラブルシューティングが困難になる可能性があります。 代わりに、Git ハッシュや日時など、デプロイごとに一意のタグを使用して、更新プログラムが適切に追跡およびデプロイされるようにします。

マネージド エージェントは gRPC のみをサポートします。