🔀

Azure Container Apps (Environment) におけるルールベースのルーティング

に公開
2026/01/15

はじめに

この記事は、Azure Container Apps (Environment) にルールベースのルーティングを設けてみた記録です。

カスタムドメインを用いるパターンは以下で検証しています。

https://zenn.dev/georgeosddev/articles/azure-container-apps-rule-based-routing-2

手順

まずはドキュメントに沿ってやってみます。

https://learn.microsoft.com/ja-jp/azure/container-apps/rule-based-routing?pivots=azure-cli

Env は過去の検証 で用いたものを再利用します。

CONTAINER_APP_1_NAME="my-container-app-1"
CONTAINER_APP_1_IMAGE="mcr.microsoft.com/k8se/quickstart:latest"
CONTAINER_APP_1_TARGET_PORT="80"
CONTAINER_APP_2_NAME="my-container-app-2"
CONTAINER_APP_2_IMAGE="mcr.microsoft.com/dotnet/samples:aspnetapp"
CONTAINER_APP_2_TARGET_PORT="8080"
LOCATION="japaneast"
RESOURCE_GROUP="zenn-aca-without-vnet"
ENVIRONMENT_NAME="aca-env-without-vnet"
ROUTE_CONFIG_NAME="my-route-config"

az containerapp up \
  --name $CONTAINER_APP_1_NAME \
  --resource-group $RESOURCE_GROUP \
  --location $LOCATION \
  --environment $ENVIRONMENT_NAME \
  --image $CONTAINER_APP_1_IMAGE \
  --target-port $CONTAINER_APP_1_TARGET_PORT \
  --ingress external \
  --query properties.configuration.ingress.fqdn

az containerapp up \
  --name $CONTAINER_APP_2_NAME \
  --resource-group $RESOURCE_GROUP \
  --location $LOCATION \
  --environment $ENVIRONMENT_NAME \
  --image $CONTAINER_APP_2_IMAGE \
  --target-port $CONTAINER_APP_2_TARGET_PORT \
  --ingress external \
  --query properties.configuration.ingress.fqdn

az containerapp env http-route-config create \
  --http-route-config-name $ROUTE_CONFIG_NAME \
  --resource-group $RESOURCE_GROUP \
  --name $ENVIRONMENT_NAME \
  --yaml routing.yml \
  --query properties.fqdn

> Command group 'containerapp env http-route-config' is in preview and under development. Reference and support levels: https://aka.ms/CLI_refstatus
> "my-route-config.whitemoss-043fed62.japaneast.azurecontainerapps.io"

実行すると my-route-config.whitemoss-043fed62.japaneast.azurecontainerapps.io という FQDN が構成されます。

ポータル上からは以下のように確認できます。

env-routing-portal

https://my-route-config.whitemoss-043fed62.japaneast.azurecontainerapps.io/app1 => my-container-app-1、
https://my-route-config.whitemoss-043fed62.japaneast.azurecontainerapps.io/app2 => my-container-app-2

それぞれ指定したアプリにルーティングされてアクセスすることが確認できます。

当然アプリ側で UsePathBase のようなことをしていないと、相対パスがずれるので注意。

app2-access

考察など

Envoyのルーティングと似てるようで設定値が違います。

HTTP routing — envoy 1.38.0-dev-6c261a documentation

targets が配列だけど

targets が配列のため複数指定してもエラーになりませんが、先に一致したものが優先されるようです。

以前用意した Nginx イメージが動作する aca-without-vnet-2 をターゲットに追加してみますが、/app2 や / でのアクセスは my-container-app-2 に到達します。

routing2.yml
rules:
  - description: App 1 rule
    routes:
      - match:
          prefix: /app1
        action:
          prefixRewrite: /
    targets:
      - containerApp: my-container-app-1
  - description: App 2 rule
    routes:
      - match:
          path: /app2
        action:
          prefixRewrite: /
      - match:
          path: /
    targets:
      - containerApp: my-container-app-2
      - containerApp: aca-without-vnet-2

ルールにマッチしないパスへのアクセス

bodyなしの 404 が返却されるようです。

rule-not-match

.internal. FQDN は未対応

Env内のアプリから <ルールConfig名>.internal.<Envのサフィックス> でアクセスした場合はアプリが存在しない場合の 404 と同様の応答でした。

internal-404

どんな用途につかうのかちょっとわからず。

リバプロ的に複数のアプリを同一ドメインで配信することが可能になりますが、
個別でリバプロ、Gateway的なアプリを用意してマイクロサービス化するのとどっちがいいんだろうか。

https://zenn.dev/georgeosddev/articles/azure-container-apps-ingress-architecture-patterns

Discussion