ポートバインディング
アプリAにポート解釈マンを同梱させない
たとえばapacheなどのwebサーバーを同梱させない
代わりに、httpリクエストを解釈できるライブラリを使って、Pに来たリクエストをA自身が解釈する
これにより以下の恩恵が得られる
アプリAが軽くなる
アプリAの利用者は「Pに繋げばいい」と単純になる
ルーティングとかも使いやすくなる
というかTCP/UDP的に考えてホスト以外に使えるパラメーターがポートくらいしかないsta.icon
指定ポートPを公開して「俺を使いたいやつはこのポートに繋ぎに来い」とすること
んん?
合ってるかこれ?
アプリがポート持ってるのは当たり前じゃない?
httpsは443。普通はこれ固定になる。だけどそれは不便なので任意ポートをもたせる。それだけでは?明示的にやらなくても勝手にポートバインディングになるのでは?
んん?
sta.icon
わかるようでまだわかってない
Q: Aのポートxxには誰がBからの通信と繋げるの?
Q: ポートxxをポートyyに転送する仕組みって一般的に誰が?どうやって?やってるの?なんかライブラリとかあるん?
refs
WebアプリケーションはWebサーバーコンテナの内部で実行されることがある。例えば、PHPアプリケーションはApache HTTPD内部のモジュールとして実行されるかもしれないし、JavaアプリケーションはTomcatの内部で実行されるかもしれない。Twelve-Factor Appは完全に自己完結 し、Webに公開されるサービスを作成するために、コンテナが実行環境にWebサーバーランタイムを注入することを頼りにしない。Webアプリケーションは ポートにバインドすることでHTTPをサービスとして公開し、 そのポートにリクエストが来るのを待つ。
コンテナの中にwebアプリを置くのはダメ
どうするか
Webアプリケーションは ポートにバインドすることでHTTPをサービスとして公開し、 そのポートにリクエストが来るのを待つ。
わからんので原文
The web app exports HTTP as a service by binding to a port, and listening to requests coming in on that port.
webアプリはHTTPサービスを晒す
あるポートPにバインドすることによって
んで、そのポートPにリクエストが来るのを待つ(リッスン)
もしかしてsta.icon*2
webサーバーの機能をアプリ自身が持つのをやめる
代わりに、(webサーバーの機能が通常解釈する)httpリクエストが外から来ることを前提にしてしまう
んで、そのリクエストが来るポートを一つに絞る(Pにバインドする)
ということ?sta.icon
ローカルの開発環境では、開発者はアプリケーションによって公開されたサービスにアクセスするために、http://localhost:5000/ のようなサービスのURLにアクセスする。本番環境ではルーティング層が、外向きのホスト名からポートにバインドされたWebプロセスへとリクエストをルーティングする。 1: サービスSは 5000 を公開する
2: ルーティングサービスは、ホスト名H:ポート名Pへのアクセスを、サービスSの5000に転送する設定を持つ
これは一般に、依存関係宣言を使ってWebサーバーライブラリをアプリケーションに追加することで実装される。Webサーバーライブラリの例として、PythonにおけるTornado、RubyにおけるThin、Javaやその他のJVMベースの言語におけるJettyなどがある。これは ユーザー空間 すなわちアプリケーションのコード内で完結する。リクエストを処理するための実行環境との契約は、ポートをバインドすることである。
Tornado……とあるが、Djangoみたいなフレームワークだな
要はhttpリクエスト解釈できるライブラリ使えってことだよな。まあそうかsta.icon
例えば Tomcat を実行した時は http://localhost:5000/ で公開される。webアプリケーションは、そのポートにバインドするHTTPDサービスとして公開をする。(ポートにバインドとは、ここでは80/443にアクセスに来た通信を、Tomcatの5000に転送する事である。) このようにすることで、あるアプリケーションが、他のアプリケーションのバックエンドサービスになりえる利点がある。
Apache は起動時に、ローカルマシンのあるポートおよびアドレス に対して接続し、リクエストが来るのを待ちます。 デフォルトではマシンのすべてのアドレスに対して Listen します。 特定のポートか、特定のアドレスのみか、 またはそれらの組み合わせで Listen するように指定したい場合もあります。 異なる IP アドレス、ホスト名、ポートに対して Apache がどのように 応答するかを制御するバーチャルホスト機能と組み合わせてよく使われます。