何の話かというと
OpenShiftのネットワーク構成について聞かれることが多くなってきたので、ポイントをまとめておきます。
管理アクセスの経路
まず、OpenShiftを構成するサーバ群について、こちらのp.12を参照してください。
この中にある「ブローカー」ノードは、REST APIで、ギアの作成などの管理操作のリクエストを受け付けます。rhcコマンドも裏ではこのREST APIを使用しています。(REST APIの仕様については、公式マニュアルの「REST API Guide」を参照してください。)リクエストを受けたブローカーは、実行ノードに対して、ギアの作成などの指示を出します。
アプリケーションアクセスの経路
一方、ギアの中で起動したWebアプリケーションに対して、Webブラウザからアクセスする際は、実行ノードに対して、直接に接続が行われます。ルーティング用のノードなどは介在しません。アプリケーション実行用のギアを立ち上げると、そのアプリケーション名を含む固有のURL(ドメイン名)が生成されて、そのドメイン名に対して、アプリケーションのギアが稼働する実行ノードのIPアドレスがDNS登録されます。(このためにDDNSのノードがあるわけですね。)
そして、各実行ノードでは、Apacheのmod_proxyがクライアントからのアクセスを受け付けて、URLに応じて、該当のアプリケーションにリクエストを振り分けます。(各アプリケーション自身は、local(127.0.x.x)の特定ポートをListenしています。)図にすると、このような感じになります。
また、オートスケール指定の場合は、上図の「Web Application」の部分は、そのアプリケーション用のロードバランサ(HA Proxy)になります。この場合、HA Proxyとその後ろのWeb Applicationサーバの通信が発生しますが、ギア同士の通信は、各実行ノードのHA Proxyがさばく様になっています。(ギアの中で動くロードバランサ用のHA Proxyとは別物です。ややこしいですね。。。)
各実行ノードのHA Proxyは、その中のギア内のアプリケーション機能にアクセスするためのポートを外部に公開します。他のギアは、このポートを指定して該当のギアと通信を行います。これは、WebアプリケーションとバックエンドDBの通信などでも利用されています。図にすると、このような感じです。
WebSocketsのサポートについて
詳細はすっとばしますが、WebSocketsに対応するには、クライアントからのリクエストをさばく実行ノード上のReverse Proxyの対応と、そこから転送されたリクエストを受け取るカートリッジ内のWebアプリケーションの対応が必要になります。
前者については、現行のApache(mod_proxy)では対応しきれないので、Node.jsで新たにProxyServerを書き起こして対応する方向で開発が進んでいます。OpenShift Orignでは、すでにコードはできており、OpenShift Onlineでは、Preview機能として利用可能になっています。(カートリッジ側については、個別に対応が進んでいるようです。)
現在は、後方互換のために、既存のmod_proxyとはポートを分けて、WebSocketsを使用する場合は、8000番ポートと8443番ポートを使用するようになっています。将来的には、mod_proxyは廃止して、WebSockets対応の独自Proxy Serverが標準になる予定とのことです。