既存のドメインを Azure App Service に移行する

この記事では、ダウンタイムを発生させずにアクティブな DNS 名を Azure App Service に移行する方法について説明します。

ライブ サイトとその DNS ドメイン名を App Service に移行するとき、その DNS 名は既にライブ トラフィックを配信しています。 アクティブな DNS 名を App Service アプリに事前にバインドすることで、移行中の DNS 解決のダウンタイムを回避できます。

DNS 解決のダウンタイムについて心配がない場合は、「 既存のカスタム DNS 名を Azure App Service にマップする」を参照してください。

前提条件

手順を完了するには、 App Service アプリが Free レベルに含まれていないことを確認します。

1. ドメイン検証 ID を取得する

カスタム ドメインを先取りしてバインドする場合は、既存の DNS レコードに変更を加える前に、次の両方を実行します。

• ドメイン プロバイダーにドメイン検証 ID を追加して、ドメインの所有権を確認します。
• App Service アプリでドメイン名を有効にします。

後でカスタム DNS 名を古いサイトから App Service アプリに移行しても、DNS 解決にダウンタイムは発生しません。

1. Azure portal で、App Service アプリの管理ウィンドウを開きます。

2. アプリ ページの左側のウィンドウで、 [カスタム ドメイン] を選択します。

3. [カスタム ドメイン] ウィンドウで、[カスタム ドメイン検証 ID] ボックスの ID をコピーします。 この ID は、後の手順で使用します。

   

2. DNS レコードを作成する

1. ドメイン プロバイダーの Web サイトにサインインします。

   Azure DNS を使用して自社のドメインの DNS レコードを管理したり、Azure App Service のカスタム DNS 名を構成したりできます。 詳細については、「チュートリアル:Azure DNS でドメインをホストする」を参照してください。

2. DNS レコードの管理ページを探します。

   各ドメイン プロバイダーには独自の DNS レコード インターフェイスがあるので、プロバイダーのドキュメントを参照してください。 [ドメイン名] 、 [DNS] 、 [ネーム サーバー管理] というラベルが付いたサイトの領域を探します。

   多くの場合、DNS レコード ページを見つけるには、アカウント情報を表示し、[ マイ ドメイン] などのリンクを探します。 そのページに移動し、 [ゾーン ファイル] 、 [DNS レコード] 、 [詳細構成] のような名前のリンクを探します。

   以下のスクリーンショットは、DNS レコード ページの例です。

   

3. レコードを作成するには、[ 追加] を選択するか、適切なウィジェットを選択します。

注

一部のプロバイダー (GoDaddy など) では、別の [変更を保存] リンクを選択するまで DNS レコードの変更が反映されません。

ドメイン検証用の TXT record を追加します。 TXT recordのホスト名は、マップする DNS レコードの種類によって異なります。 次の表をご覧ください (通常、@ はルート ドメインを表します)。

DNS レコードの例	TXT ホスト	TXT 値
\@ (ルート)	_asuid_	[カスタム ドメイン管理] ウィンドウに表示されるドメイン検証 ID
www (サブ)	_asuid.www_	[カスタム ドメイン管理] ウィンドウに表示されるドメイン検証 ID
\* (ワイルドカード)	_asuid_	[カスタム ドメイン管理] ウィンドウに表示されるドメイン検証 ID

注

ワイルドカード * レコードは、既存の CNAME recordを持つサブドメインを検証しません。 サブドメインごとに TXT record を明示的に作成することが必要になる場合があります。

3. アプリのドメインを有効にする

1. [ カスタム ドメイン ] ウィンドウで、[ カスタム ドメインの追加] を選択します。

   

2. サード パーティのドメインを構成するには、[ ドメイン プロバイダー] で [ その他のすべてのドメイン サービス] を選択します。

3. [TLS/SSL 証明書] で、[後で証明書を追加する] を選択します。 ドメインの移行が完了したら、App Service マネージド証明書を追加できます。

4. [TLS/SSL の種類] で、目的のバインドの種類を選択します。

   設定	説明
   カスタム ドメイン	TLS/SSL バインドを追加するドメイン名。
   プライベート証明書のサムプリント	バインドするための証明書。
   TLS/SSL の種類	SNI SSL: 複数サーバー名表示 (SNI) SSL バインディングが追加される場合があります。 このオプションでは、複数の TLS/SSL 証明書を使用して、同一の IP アドレス上の複数のドメインを保護できます。 最新のブラウザーのほとんど (Inernet Explorer、Chrome、Firefox、Opera など) が SNI をサポートしています (詳細については、「Server Name Indication」を参照してください)。 IP SSL: 追加できる IP SSL バインドは 1 つだけです。 このオプションでは、TLS/SSL 証明書を 1 つだけ使用して、専用のパブリック IP アドレスを保護します。 バインディングを構成した後は、「IP ベースの SSL のレコードを再マップする」の手順に従います。 IP ベースの SSL は、Standard レベル以上でのみサポートされます。

5. 移行する完全修飾ドメイン名と、作成した TXT record に対応するドメイン名を入力します。 例えば: contoso.com、www.contoso.com、または*.contoso.com。

   

6. [検証] を選択します。 このダイアログには、アプリのカスタム ドメインが機能するために必要な 2 つのレコードが表示されますが、検証はドメイン検証 ID ( TXT record) だけで渡されます。

   

7. [ドメイン検証] セクションに緑色のチェック マークが表示されている場合は、ドメイン検証 ID を正しく構成しました。 [追加] を選択します。 赤い X マークが表示されている場合は、ドメイン プロバイダーの Web サイトでエラーを修正します。

   

8. 一覧にカスタム ドメインが表示されます。 バインドがない赤い X が表示される場合もあります。

   後で [証明書の追加] を選択したため、赤い X とバインドなしが表示されます。 ドメインのプライベート証明書を追加し、バインドを構成するまで保持されます。

   

   注

   カスタム ドメインの証明書バインドを構成しない限り、ブラウザーからドメインへの HTTPS 要求は、ブラウザーに応じてエラーまたは警告を受け取ります。

4. アクティブな DNS 名の再マップ

アクティブな DNS レコードを再マップして App Service をポイントします。 この手順が完了するまでは、引き続き古いサイトを指します。

1. A record のみ: App Service アプリの外部 IP アドレスを取得します。 [ カスタム ドメイン ] ウィンドウで、アプリの IP アドレスをコピーします。

   

2. ドメイン プロバイダーの [DNS レコード] ウィンドウで、再マップする DNS レコードを選択します。

3. 次の表の例のように、 A または CNAME record を再マップします。

   FQDN の例	レコード タイプ	ホスト	値
   contoso.com (ルート)	A	@	「アプリの IP アドレスをコピーする」で取得した IP アドレス
   www\.contoso.com (サブ)	CNAME	www	_<app-name>.azurewebsites.net_
   \*.contoso.com (ワイルドカード)	CNAME	_\*_	_<app-name>.azurewebsites.net_

4. 設定を保存します。

DNS の伝播が始まると、すぐに DNS クエリが App Service アプリに解決されるようになります。

よく寄せられる質問

• ライブ ドメインを移行するときに、App Service マネージド証明書を追加できますか?
• 別のアプリからドメインを移行する方法は?

ライブ ドメインを移行するときに、App Service マネージド証明書を追加できますか?

App Service マネージド証明書は、移行されたライブ ドメインに追加できますが、アクティブな DNS 名を再マップした後に限られます。 App Service マネージド証明書を追加するには、「無料のマネージド証明書を作成する」を参照してください。

別のアプリからドメインを移行する方法は?

Azure のアクティブなカスタム ドメインは、サブスクリプション間または同じサブスクリプション内で移行できます。 ただし、ダウンタイムなしで移行を実現するには、ソース アプリとターゲット アプリに特定の時点で同じカスタム ドメインを割り当てる必要があります。 そのため、2 つのアプリが同じ展開単位 (内部的には、Web スペースとして知られています) には展開されないようにする必要があります。 1 つのドメイン名は、展開単位ごとに 1 つのアプリにのみ割り当てできます。

FTP/S URL <deployment-unit>.ftp.azurewebsites.windows.net のドメイン名を確認することで、アプリの展開単位がわかります。 デプロイ ユニットがソース アプリとターゲット アプリで異なっていることを確認します。 アプリの展開単位は、それ自体が含まれている App Service プランによって決まります。 プランの作成時に Azure によってランダムに選択され、変更することはできません。 同じリソース グループと同じリージョンに 2 つのアプリを作成すると、Azure によって同じデプロイ ユニットに配置されます。 ただし、その逆がそうであることを確認する方法はありません。 つまり、異なる展開単位にプランを作成する唯一の方法は、別の展開単位を取得するまで、新しいリソース グループまたはリージョン内にプランを作成し続けることです。

関連コンテンツ

カスタム TLS/SSL 証明書を App Service にバインドする方法について説明します。

• App Service ドメインを購入する
• Azure App Service で TLS バインドを使用してカスタム DNS 名をセキュリティで保護する