1回の展開で2つ以上のWebロールを持つオプションがあります。ただし、各デプロイメントはステージングまたは本番のいずれかになります。つまり、拡張により、そのデプロイメントにアクセスするためのURLは1つだけになります。
この場合、さまざまなWebロールにアクセスする方法を考えると、それらのURLは何になりますか。また、単一のデプロイメントで複数のWebロールを使用するための用途もあります。
1回の展開で2つ以上のWebロールを持つオプションがあります。ただし、各デプロイメントはステージングまたは本番のいずれかになります。つまり、拡張により、そのデプロイメントにアクセスするためのURLは1つだけになります。
この場合、さまざまなWebロールにアクセスする方法を考えると、それらのURLは何になりますか。また、単一のデプロイメントで複数のWebロールを使用するための用途もあります。
単一の展開で複数のWebロールを使用するのはなぜですか?公開されている(顧客向けの)Webサイトと管理用のWebサイト(おそらくポート8000)を備えたアプリケーションについて考えてみます。これを処理する基本的な方法は2つあります。
オプション#1は、2つのロールインスタンス(SLAに必要な最小2つ)で解決できるため、費用効果が高くなります。オプション#2は、独立したスケーリングに適しています。たとえば、顧客のトラフィックが急増した場合、管理Webサイトにアクセスしようとしたときに問題が発生する可能性がありますが、管理Webサイトが独自の役割を果たしている場合は、顧客のトラフィックの影響を受けません。
どちらの場合も、1つのIPアドレスと1つの* .cloudapp.net名を取得します(CNAMEを使用してカスタムドメイン名をそれにマップできます)。
ステージングと本番環境:デプロイメント全体をステージングまたは本番環境のいずれかに公開できます(または、2つの別々の公開として両方に公開できます)。ステージングは外部ユーザー向けではありません。実際には、新しい展開が期待どおりに機能することを確認できるプレライブエリア向けです。次に、本番環境で現在実行中のシステムと仮想IPスワップを実行できます。これにより、ステージングと本番環境の展開が効果的にスワップされます。これにより、顧客のダウンタイムなしでソフトウェアをほぼ瞬時にアップグレードできます。
注意:デプロイメント内のすべてのロールは一緒に維持する必要があります。1つのロールを1つのサービスにデプロイし、もう1つのロールを別のサービスにデプロイすることはできません。これを実行する場合:役割を別々のデプロイメントに分割します。次に、それらを別のURLに公開できます。
本番デプロイメントでは、たとえば、前に定義したプレフィックスが付いたURLからWebロールにアクセスできますmyapp.cloudapp.net
。一方、ステージング展開のWebロールには、たとえば自動生成されたURLからアクセスできます。205521014d8c440a83852b62e0df9db5.cloudapp.net
AppFabricルーターをバイパスして、Webロールインスタンスに直接アクセスする方法はありません。とにかくそれをする必要があるのはなぜですか?
あるWebロールインスタンスから別のインスタンスにアクセスする必要がある場合は、直接通信の代わりにキューまたは分散キャッシュを使用することを検討してください。