このガイドでは、Google Cloud URL マップの構成方法について説明します。URL マップは、受信 HTTP(S) リクエストを特定のバックエンド サービス またはバックエンド バケットにルーティングするための一連のルールです。最小限の URL マップは、受信したすべてのリクエストパス(/*
)と一致します。
このガイドに記載された手順を行う前に、URL マップのコンセプトを十分に理解してください。
URL マップは、次の Google Cloud サービスで使用されます。
グローバル外部アプリケーション ロードバランサ、リージョン外部アプリケーション ロードバランサ、内部アプリケーション ロードバランサ、Cloud Service Mesh で使用される URL マップは、いくつかの高度なトラフィック管理機能もサポートしています。詳細については、URL マップのコンセプト: 高度なトラフィック管理をご覧ください。
URL マップのデフォルト
次の表に示すように、URL マップには 2 つのデフォルトがあります。
デフォルトの種類 | 設定 | 意味 |
---|---|---|
URL マップのデフォルト | gcloud compute url-maps create
|
受信 URL に一致するパスマッチャーやホストルールがない場合、指定したデフォルトのバックエンド サービス またはバックエンド バケット が使用されます。 |
パスマッチャーのデフォルト | gcloud compute url-maps add-path-matcher
|
URL のパスがパスマッチャーと一致しても、指定された --path-rules が一致しない場合、指定したデフォルトのバックエンド サービス またはバックエンド バケット が使用されます。 |
ホストルール
ホストルールでは、リクエストと照合する一連のホストを定義します。
ホストルールでは、ホスト名は完全修飾ドメイン名(FQDN)にする必要があります。ホスト名には IPv4 または IPv6 アドレスを使用できません。例:
- 正常に機能する:
example.com
- 正常に機能する:
web.example.com
- 正常に機能する:
*.example.com
- 正常に機能しない:
35.244.221.250
URL マップを構成する
URL マップにより、トラフィックをバックエンド サービスに送信できます。また、バックエンド バケットにも送信できます。バックエンド バケットは、リージョン外部アプリケーション ロードバランサと内部アプリケーション ロードバランサではサポートされていません。
Console
Google Cloud コンソールを使用して URL マップを追加するには、次の操作を行います。
- [ロード バランシング] ページに移動します。
- ロードバランサの名前をクリックします。
- [ロードバランサの詳細] ページで、選択したロードバランサの [ 編集] をクリックします。
- [ホストとパスのルール] を選択します。
- [ホストとパスのルールを追加] をクリックします。
[ホスト] フィールド、[パス] フィールド、またはその両方を入力して、[バックエンド サービス] または [バックエンド バケット]を選択します。
- 完全修飾のホスト名を入力します(例:
web.example.com
)。 - パスを入力します(例:
/video
)。 - [ホストとパスのルール] ページの [バックエンド] メニューで、使用可能なバックエンド サービス またはバックエンド バケットを選択します。
- 完全修飾のホスト名を入力します(例:
[ホストとパスのルール] の左側の青色のチェックマークを確認して、[更新] ボタンをクリックします。
gcloud
Google Cloud CLI を使用して URL マップを追加するには、url-maps create
コマンドを使用します。
gcloud compute url-maps create URL_MAP_NAME \ (--default-backend-bucket=DEFAULT_BACKEND_BUCKET | --default-service=DEFAULT_SERVICE) \ [--description DESCRIPTION] \ [--global | --region=REGION]
リージョン外部アプリケーション ロードバランサと内部アプリケーション ロードバランサの場合、URL マップの作成時に必ず --region
フラグを指定します。
パスマッチャーを作成するには、gcloud compute url-maps add-path-matcher
コマンドを使用します。
gcloud compute url-maps add-path-matcher URL_MAP_NAME \ (--default-backend-bucket=DEFAULT_BACKEND_BUCKET | --default-service=DEFAULT_SERVICE) \ --path-matcher-name PATH_MATCHER \ [--path-rules="PATH=SERVICE or BUCKET"]
このコマンドには、一致しないリクエストを送信できるデフォルトのバックエンド サービス またはバックエンド バケット が必要です。--path-rules
フラグでは、リクエストパスとバックエンド サービス (バックエンド バケット)の間のマッピングを定義します。次の例では、リクエストパス /video/
および /video/*
が video-service
バックエンド サービスに転送されます。
--path-rules="/video=video-service,/video/*=video-service"
ホストルールを作成するには、gcloud compute url-maps add-host-rule
コマンドを使用します。
gcloud compute url-maps add-host-rule URL_MAP_NAME \ --hosts=[HOSTS] --path-matcher-name=PATH_MATCHER
たとえば、次の --hosts
値は、リクエストを www.example.com
および altostrat.com
のすべてのサブドメインと照合します。
--hosts=[*.altostrat.com,www.example.com]
URL マップのデフォルトのサービス またはデフォルトのバケット を変更するには、url-maps set-default-service
コマンドを使用します。
gcloud compute url-maps set-default-service URL_MAP_NAME (--default-backend-bucket=DEFAULT_BACKEND_BUCKET | --default-service=DEFAULT_SERVICE)[GCLOUD_WIDE_FLAG ...]
Terraform
グローバル URL マップを作成するには、google_compute_url_map リソースを使用します。
リージョン URL マップを作成するには、google_compute_region_url_map リソースを使用します。
URL マップの構成を検証する
URL マップをデプロイする前に、URL マップ構成を検証して、マップが意図したとおりに適切なバックエンドにリクエストをルーティングしていることを確認してください。これを行うには、URL マップの構成にテストを追加します。さまざまな URL マップルールをテストし、必要な回数のテストを実行して、デプロイ時にマップがトラフィックを適切にルーティングすることを確認できます。また、今後、ルールの変更が必要になった場合は、新しい構成を実際に使用する前に変更内容をテストできます。
URL マップの構成を検証するには、gcloud compute url-maps
validate
コマンドを使用します。このコマンドは、指定された構成のみをテストします。テストに合格したかどうかにかかわらず、デプロイされた URL マップに変更は保存されません。この動作は、同じ URL テストを実行する他の URL マップコマンド(edit
、import
)とは異なり、テストに合格すると新しい構成を保存します。デプロイされている URL マップを変更せずに新しいルーティング構成をテストするには、validate
コマンドを使用します。
validate
コマンドを使用すると、ヘッダーとクエリ パラメータに基づくルーティング、HTTP から HTTPS へのリダイレクト、URL の書き換えなどの高度なルート構成をテストできます。
コンソール
Google Cloud コンソールを使用して URL マップの構成を検証することはできません。代わりに gcloud
または REST API を使用してください。
gcloud
URL マップの構成を検証するには、gcloud compute url-maps validate
コマンドを使用します。
グローバル外部アプリケーション ロードバランサの場合:
gcloud compute url-maps validate --source PATH_TO_URL_MAP_CONFIG_FILE \ --load-balancing-scheme=EXTERNAL_MANAGED \ --global
従来のアプリケーション ロードバランサの場合:
gcloud compute url-maps validate --source PATH_TO_URL_MAP_CONFIG_FILE \ --load-balancing-scheme=EXTERNAL \ --global
- PATH_TO_URL_MAP_CONFIG_FILE: 検証用の URL マップ構成を含むファイルのパスに置き換えます。
既存ロードバランサの URL マップに対する変更を検証する
URL マップの変更が必要な既存のロードバランサがある場合は、公開する前にこれらの構成の変更をテストできます。
ロードバランサの既存の URL マップを YAML ファイルにエクスポートします。
gcloud compute url-maps export URL_MAP_NAME \ --destination PATH_TO_URL_MAP_CONFIG_FILE \ --global
新しい構成で YAML ファイルを編集します。たとえば、外部アプリケーション ロードバランサを編集して、パス
/video
を含むすべてのリクエストをvideo-backend-service
という新しいバックエンド サービスに送信する場合は、次のように URL マップ構成にテストを追加できます。1 つのデフォルト
web-backend-service
が設定された既存の URL マップ構成。kind: compute#urlMap name: URL_MAP_NAME defaultService: https://www.googleapis.com/compute/v1/projects/PROJECT_ID/global/backendService/web-backend-service
追加のパスマッチャーを使用した編集された URL マップ構成。デフォルト
web-backend-service
と新しいvideo-backend-service
バックエンド サービス両方のテストを実行します。kind: compute#urlMap name: URL_MAP_NAME defaultService: https://www.googleapis.com/compute/v1/projects/PROJECT_ID/global/backendService/web-backend-service hostRules: - hosts: - '*' pathMatcher: pathmap pathMatchers: - defaultService: https://www.googleapis.com/compute/v1/projects/PROJECT_ID/global/backendService/web-backend-service name: pathmap pathRules: - paths: - /video - /video/* service: https://www.googleapis.com/compute/v1/projects/PROJECT_ID/global/backendService/video-backend-service tests: - description: Test routing to existing web service host: foobar path: / service: https://www.googleapis.com/compute/v1/projects/PROJECT_ID/global/backendService/web-backend-service - description: Test routing to new video service host: foobar path: /video service: https://www.googleapis.com/compute/v1/projects/PROJECT_ID/global/backendService/video-backend-service
新しい構成を検証します。
gcloud compute url-maps validate --source PATH_TO_URL_MAP_CONFIG_FILE
すべてのテストに合格すると、成功を示す次のようなメッセージが表示されます。
Successfully validated [https://www.googleapis.com/compute/v1/projects/PROJECT_ID/global/urlMaps/URL_MAP_CONFIG_FILE_NAME]
テストに失敗すると、エラー メッセージが表示されます。URL マップ構成ファイルに必要な修正を加え、検証を再試行してください。
Error: Invalid value for field 'urlMap.tests': ''. Test failure: Expect URL 'HOST/PATH' to map to service 'EXPECTED_BACKEND_SERVICE', but actually mapped to 'ACTUAL_BACKEND_SERVICE'.
新しい構成が機能し、既存の設定に影響を与えないことを確認できたら、URL マップにインポートできます。この手順では、新しい構成で URL マップもデプロイされます。
gcloud compute url-maps import URL_MAP_NAME \ --source PATH_TO_URL_MAP_CONFIG_FILE \ --global
URL マップにテストを追加する
URL マップに構成テストを追加すると、URL マップがバックエンド サービスまたはバックエンド バケットにリクエストを正しくルーティングしているかどうかを確認できます。
このセクションでは、デプロイ済みの URL マップにテストを追加する方法について説明します。マップを実際にデプロイせずに URL マップの新しい変更をテストする場合は、URL マップ構成を検証するをご覧ください。
URL マップを編集するとテストが実行されます。テストに失敗すると、エラー メッセージが表示されます。
Error: Invalid value for field 'urlMap.tests': ''. Test failure: Expect URL 'HOST/PATH' to map to service 'EXPECTED_BACKEND_SERVICE', but actually mapped to 'ACTUAL_BACKEND_SERVICE'.
URL マップへのテストの追加は任意です。
Console
Google Cloud コンソールからテストを実行するには:
- [ロード バランシング] ページに移動します。
- ロードバランサの名前をクリックします。
- [ロードバランサの詳細] ページで、選択したロードバランサの [ 編集] をクリックします。
- [ルーティング ルール] をクリックします。従来のアプリケーション ロードバランサの場合、これはホストとパスのルールです。
- [構成テストを表示する] をクリックします。
- [構成テストの追加] をクリックします。次のテスト URL とバックエンドを追加します。
- テストホストとパス 1
example.com
とバックエンドwww-service.
- テストホストとパス 2
example.net
とバックエンドwww-service.
- ホストとパスのテスト 3
example.net/web
とバックエンドwww-service.
- テストホストとパス 4
example.com/videos
とバックエンドvideo-service.
- テストホストとパス 5
example.com/videos/browse
とバックエンドvideo-service.
- テストホストとパス 6
example.net/static
とバックエンドstatic-service.
- テストホストとパス 7
example.net/static/images
とバックエンドstatic-service.
- テストホストとパス 1
- [ルーティング ルール] の左側の青色のチェックマークを確認して、[更新] ボタンをクリックします。従来のアプリケーション ロードバランサの場合、[ホストとパスのルール] の横にある青色のチェックマークを探します。
gcloud
Google Cloud CLI を使用して URL マップにテストを追加するには、gcloud compute url-maps edit
コマンドを使用します。
gcloud compute url-maps edit URL_MAP_NAME
これによってテキスト エディタが起動します。外部アプリケーション ロードバランサの場合、テストで次の形式を使用する必要があります。
tests: - host: example.com service: https://www.googleapis.com/compute/v1/projects/PROJECT_ID/global/backendServices/www-service - host: example.net service: https://www.googleapis.com/compute/v1/projects/PROJECT_ID/global/backendServices/www-service - host: example.com path: /videos service: https://www.googleapis.com/compute/v1/projects/PROJECT_ID/global/backendServices/video-service - host: example.com path: /videos/browse service: https://www.googleapis.com/compute/v1/projects/PROJECT_ID/global/backendServices/video-service - host: example.net path: /web service: https://www.googleapis.com/compute/v1/projects/PROJECT_ID/global/backendServices/www-service - host: example.net path: /static service: https://www.googleapis.com/compute/v1/projects/PROJECT_ID/global/backendServices/static-service - host: example.net path: /static/images service: https://www.googleapis.com/compute/v1/projects/PROJECT_ID/global/backendServices/static-service
ホストルールでホストを指定しない場合、すべてのホストの URL(example.com と example.net の両方)が一致する場合があります。ホストルールがある場合は、example.com と example.net の両方に一致するルールを作成する必要があります。
URL マップの一覧表示
Console
Google Cloud コンソールですべての URL マップを一覧表示することはできません。
gcloud
Google Cloud CLI を使用して URL マップのリストを表示するには、url-maps list
コマンドを使用します。
gcloud compute url-maps list
URL マップに関する情報の取得
Console
URL マップに関する情報を取得するには、次の手順を実行します。
- [ロード バランシング] ページに移動します。
- ロードバランサの名前をクリックします。
- [ロードバランサの詳細] ページで、選択したロードバランサの [ 編集] をクリックします。
- ホストとパスのルールを表示します。
gcloud
Google Cloud CLI を使用して単一の URL マップに関する情報を取得するには、url-maps describe
コマンドを使用します。
gcloud compute url-maps describe URL_MAP_NAME
URL マップの削除
URL マップを削除する前に、参照先のすべてのターゲット プロキシを削除する必要があります。詳細については、ターゲット プロキシの削除をご覧ください。
Console
URL マップを削除するには、次の手順を実行します。
- [ロード バランシング] ページに移動します。
- ロードバランサの名前をクリックします。
- [ロードバランサの詳細] ページで、選択したロードバランサの [ 編集] をクリックします。
- [ロードバランサの詳細] ページで、[ホストとパスのルール] を表示します。
- URL マップの右側にある「X」をクリックして削除します。URL マップが表示から消えます。
- [ホストとパスのルール] の左側の青色のチェックマークを確認して、[更新] ボタンをクリックします。
gcloud
Google Cloud CLI を使用して URL マップを削除するには、url-maps delete
コマンドを使用します。URL マップを削除する際は、事前にその URL マップを参照するターゲット HTTP プロキシを削除しておく必要があります。
gcloud compute url-maps delete URL_MAP_NAME [--quiet]
パスマッチャーの削除
Console
パスマッチャーを削除するには、次の手順を実行します。
- [ロード バランシング] ページに移動します。
- ロードバランサの名前をクリックします。
- [ロードバランサの詳細] ページで、選択したロードバランサの [ 編集] をクリックします。
- [ホストとパスのルール] を選択します。
- 既存の URL マップの [パス] フィールドで、パスマッチャーの名前の「x」をクリックします。
- [ホストとパスのルール] の左側の青色のチェックマークを確認して、[更新] ボタンをクリックします。
gcloud
パスマッチャーを削除するには、gcloud compute url-maps remove-path-matcher
コマンドを使用します。
gcloud compute url-maps remove-path-matcher URL_MAP_NAME \ [--path-matcher-name PATH_MATCHER]
ホストルールの削除
Console
ホストルールを削除するには、次の手順を実行します。
- [ホストとパスのルール] ページが表示されていない場合は、[ロード バランシング] ページに移動します。
- ロードバランサの名前をクリックします。
- [ロードバランサの詳細] ページで、選択したロードバランサの [ 編集] をクリックします。
- [ホストとパスのルール] を選択します。
- 既存の URL マップの [ホスト] フィールドで、ホストの名前の「x」をクリックします。
- [ホストとパスのルール] の左側の青色のチェックマークを確認して、[更新] ボタンをクリックします。
gcloud
URL マップからホストルールを削除するには、gcloud compute url-maps remove-host-rule
コマンドを使用します。
gcloud compute url-maps remove-host-rule URL_MAP_NAME --host=HOST
たとえば、ホスト altostrat.com
を含むホストルールを my-map
という名前の URL マップから削除するには、次のコマンドを実行します。
gcloud compute url-maps remove-host-rule my-map --host altostrat.com
トラフィック管理ガイド
すべてのプロダクトで、すべての URL マップ機能が利用できるわけではありません。URL マップは、いくつかの高度なトラフィック管理機能をサポートするためにロードバランサで使用されますが、これらの機能が一部は従来のアプリケーション ロードバランサでサポートされていません。
次の表に、管理作業に使用する URL マップ機能を示します。
プロダクト | URL マップの機能とトラフィック管理ガイド |
---|---|
グローバル外部アプリケーション ロードバランサ | ロードバランサの機能: ルーティングとトラフィック管理 |
従来のアプリケーション ロードバランサ | ロードバランサの機能: ルーティングとトラフィック管理 |
リージョン外部アプリケーション ロードバランサ | ロードバランサの機能: ルーティングとトラフィック管理 |
内部アプリケーション ロードバランサ | ロードバランサの機能: ルーティングとトラフィック管理 |
Cloud Service Mesh | Cloud Service Mesh の機能: ルーティングとトラフィック管理 |
API と gcloud CLI のリファレンス
Google Cloud コンソールに加えて、API と gcloud CLI を使用して URL マップを作成できます。
API
REST API で URL マップを操作するときに使用できるプロパティとメソッドについては、以下をご覧ください。
プロダクト | API ドキュメント |
---|---|
外部アプリケーション ロードバランサ | urlMaps |
内部アプリケーション ロードバランサ | regionUrlMaps |
Cloud Service Mesh | urlMaps |
gcloud CLI
Google Cloud CLI については、以下をご覧ください。
- グローバル:
--global
- リージョン:
--region=[REGION]
高度なトラフィック管理を行うには、YAML ファイルを使用し、gcloud compute url-maps import
コマンドを使用してインポートします。
次のステップ
- URL マップの仕組みを確認する。URL マップの概要をご覧ください。
- 外部アプリケーション ロードバランサでの URL マップの動作を確認する。外部アプリケーション ロードバランサの概要をご覧ください。
- 内部アプリケーション ロードバランサ内の URL マップの動作を確認する。内部アプリケーション ロードバランサの概要をご覧ください。