カスタム ドメインのマッピング

Python 2.7/3 |Java 8/11 |PHP 5/7 |Ruby |Go 1.11/1.12 以降 |Node.js

App Engine がアプリに提供するデフォルトのアドレスではなく、カスタム ドメインを使用できます。

カスタム ドメインを使用するには、ドメインをアプリにマッピングしてから、DNS レコードを更新します。example.com のようなネイキッド ドメインや、subdomain.example.com のようなサブドメインをマッピングできます。ワイルドカードを使用してサブドメインをマッピングすることもできます。

デフォルトでは、ドメインをアプリにマッピングすると、App Engine は HTTPS 接続用のマネージド SSL 証明書を発行します。独自の SSL 証明書の使用方法をはじめとするカスタム ドメインでの SSL の使用法の詳細は、SSL によるカスタム ドメインの保護をご覧ください。

カスタム ドメインを使用すると、一部のリージョンで App Engine がアプリのユーザーに送信するレスポンスに、著しいレイテンシが発生することがあります。リージョンは以下のとおりです。

• us-west2
• us-east4
• northamerica-northeast1
• southamerica-east1
• europe-west2
• europe-west3
• asia-south1
• asia-northeast1
• australia-southeast1

始める前に

• ドメインをお持ちでない場合は、ドメインを購入してください。任意のドメイン名登録事業者を使用できますが、Google Domains を使用する場合は、App Engine のドメインが自動的に検証されるため、ドメイン検証プロセスを行う必要はありません。

• Cloud Load Balancing とサーバーレス NEG を使用して App Engine アプリにトラフィックをルーティングする場合は、カスタム ドメインをアプリに直接マッピングするのではなく、ロードバランサにマッピングし、ロードバランサ用に作成された SSL 証明書を使用することを推奨します。これにより、サーバーレス アプリごとに個別の SSL 証明書を管理する必要がなくなります。さらに、Cloud Load Balancing を使用すると、ロードバランサがクライアントとネゴシエートする際に使用する SSL の機能を制御する SSL ポリシーを設定できます。詳しくは次のページをご覧ください。

  • Google マネージド SSL 証明書の使用
  • セルフマネージド SSL 証明書の使用
  • SSL ポリシー

  次の制限に注意してください。

  • Google Cloud によって App Engine サービスに自動的に割り当てられる URL を無効にすることはできません。App Engine サービスのデフォルト URL がすでに割り当てられているユーザーは、ロードバランサをバイパスしてサービス URL に直接アクセスできます。つまり、Google Cloud Armor セキュリティ ポリシー、SSL 証明書、秘密鍵をロードバランサから構成できますが、デフォルト URL を割り当てられたユーザーはこれらのポリシーを回避できます。

カスタム ドメインをアプリにマッピングする

注: ここでは、Google Cloud Console を使用してカスタム ドメインをマッピングする方法について説明します。必要に応じて、gcloud コマンドまたは Admin API を使用できます。

1. Google Cloud Console で、App Engine の [設定] ページの [カスタム ドメイン] タブに移動します。

   [カスタム ドメイン] ページに移動

2. [カスタム ドメインを追加] をクリックします。

3. ドメインがすでに確認済みの場合、[使用するドメインを選択する] セクションにドメインが表示されます。プルダウン メニューからドメインを選択して、[続行] をクリックします。

   まだドメインを確認していない場合は、次の手順を行います。

   1. プルダウン メニューから [新しいドメインの所有権を証明] を選択します。

   2. ネイキッド ドメイン名（「example.com」など）を入力し、[確認] をクリックします。

      「www.example.com」などのサブドメインのみをマッピングする場合でも、ネイキッド ドメイン名を入力して所有権を確認します。

   3. 表示されるウェブマスター セントラル ウィンドウに情報を入力します。ウェブマスター セントラルの使用方法については、ウェブマスター セントラルのヘルプをご覧ください。

   4. ウェブマスター セントラルで手順を完了したら、Google Cloud Console の [新しいカスタム ドメインの追加] ページに戻ります。

4. [Point your domain to [project-ID]] セクションで、マッピングするドメインとサブドメインを指定します。

   ネイキッド ドメインと www サブドメインをマッピングすることをおすすめします。サブドメインは必要に応じて追加できます。

   必要なマッピングをすべて追加したら、[マッピングを保存] をクリックします。

5. ドメインの DNS レコードを確認するには、[続行] をクリックしてください。

   これらのレコードは、App Engine の [設定] ページの [カスタム ドメイン] タブでいつでも取得できます。

6. ドメイン登録事業者のウェブサイトにログインし、前の手順で表示されたレコードを使用して DNS レコードを更新します。

ドメイン登録事業者で DNS レコードを更新する

App Engine でサービスをカスタム ドメインにマッピングしたら、ドメイン登録事業者で DNS レコードを更新する必要があります。利便性のため、入力に必要な DNS レコードは、App Engine によって生成され、表示されます。

1. ドメイン マッピングの DNS レコード情報を取得します。

   Google Cloud Console で、App Engine の [設定] ページの [カスタム ドメイン] タブに移動します。このページには、アプリにマッピングされているすべてのドメインの DNS レコードが一覧表示されます。

2. ドメイン登録事業者のアカウントにログインし、DNS 構成ページを開きます。

3. ドメインの構成ページのホストレコード セクションを見つけ、ドメインをアプリにマッピングしたときに取得した各 DNS レコードを追加します。

   レコード フィールドに次の情報を入力します。

   • レコードタイプ: Google が作成した DNS レコードに表示されるレコードタイプ（A、AAAA、CNAME）を入力します。
   • レコード名:
     • A または AAAA レコードに、@ を入力します。
     • CNAME レコードに、第 3 レベルのドメイン名を入力します。たとえば、www.example.com サブドメインをマッピングするには www と入力します。
   • TTL: 必要に応じて、TTL を指定します。
   • データ: Google が作成した DNS レコードに表示されるレコードデータ（rrdata）を入力します。
     • A または AAAA レコードでは、レコードデータは IP アドレスです。
     • CNAME レコードでは、レコードデータはドメイン名です。

4. ドメインのアカウントの DNS 構成ページで変更を保存します。通常、この変更が反映されるまでに数分しかかかりませんが、登録事業者やドメインの以前の DNS レコードに設定されている有効期間（TTL）によっては、数時間かかることもあります。このオンラインの dig バージョンなどの dig ツールを使用して、DNS レコードが正常に更新されたことを確認できます。

5. 新しい URL（https://www.example.com など）でサービスを閲覧して、成功したかどうかをテストします。自動 SSL 証明書の発行には数分かかる場合があるので注意してください。

他の Google Cloud ユーザーまたはサービス アカウントに所有権を委任する

ドメインの所有権を他のユーザーまたはサービス アカウントに委任する必要がある場合は、ウェブマスター セントラルのページで権限を追加できます。

1. ウェブマスター セントラル確認ページを開きます。

2. [プロパティ] で、ユーザーまたはサービス アカウントを追加するドメインをクリックします。

3. [Verified owners] リストの最後にある [Add an owner] をクリックし、Google アカウントのメールアドレスまたはサービス アカウント ID を入力します。

   サービス アカウントのリストを表示するには、Cloud Console の [サービス アカウント] ページを開きます。

   [サービス アカウント] ページに移動

サブドメインを使用する

カスタム ドメインにワイルドカード サブドメイン マッピングを設定すると、アプリケーションは、一致するサブドメインに対するリクエストを処理します。

• アプリケーションのバージョン名またはサービス名と一致するドメインが参照されると、アプリケーションはそのバージョンを提供します。
• サービス名と一致するドメインが参照されると、アプリケーションはそのサービスを提供します。
• マネージド SSL 証明書には上限（ベースドメインごとに週あたり 20 個）があります。上限に達した場合、App Engine はすべてのリクエストの処理が完了するまで、マネージド証明書を発行しようとし続けます。

ワイルドカード マッピング

ワイルドカードを使用すると、第 3 レベル以降であればどのレベルのサブドメインでもマッピングできます。たとえば、使用するドメインが example.com の場合、ウェブアドレス フィールドにテキストを入力すると次のような結果になります。

• 「*.example.com」と入力すると、example.com のすべてのサブドメインがアプリにマッピングされます。
• 「*.private.example.com」と入力すると、private.example.com のすべてのサブドメインがアプリにマッピングされます。
• 「*.nichol.sharks.nhl.example.com」と入力すると、nichol.sharks.nhl.example.com のすべてのサブドメインがアプリにマッピングされます。
• 「*.excogitate.system.example.com」と入力すると、excogitate.system.example.com のすべてのサブドメインがアプリにマッピングされます。

dispatch.yaml ファイルを使用して、特定のサービスに対するリクエストのルーティングを定義すると、App Engine のサービスでワイルドカード マッピングを使用できます。

注: マネージド SSL 証明書では、ワイルドカード マッピングを使用できません。

sites や mail など、ドメイン内のその他のサブドメインで G Suite を使用する場合、これらのマッピングの優先順位が高くなり、ワイルドカード マッピングが行われる前に最初に照合されます。また、他の App Engine アプリを他のサブドメインにマッピングしている場合にも、これらのマッピングはワイルドカード マッピングよりも優先順位が高くなります。

DNS プロバイダによってはワイルドカード サブドメイン マッピングに対応していないことがあります。特に、CNAME ホストエントリでのワイルドカードの使用が許可されているかどうかに注意が必要です。

ワイルドカード ルーティング ルールは、App Engine のサービス ルーティング ルールに従って、サービス、バージョン、インスタンスのコンポーネントを含む URL に適用されます。

次のステップ

カスタム ドメインを SSL で保護する。