LISTENするポートを環境変数H2O_PORT経由で変更できるようにしてあります。runする際に、環境変数にてポートを指定します。kazeburo/h2oH2O_PORTはスペースで区切ることで複数のポートを書く事ができます。デフォルトは80と443をLISTENします。0.0.0.0を書かないと、h2oがIPv6もbindしようとするので、エラーとなります。コメント(View)Tengineはアジア最大級のECサイト「淘宝網」が公開しているWebサーバです。Serveralibaba/tengineNginxをベースにいくつかの機能拡張を行い、また開発も続いていて最新のstableバージョンに追従しているようです。主な機能拡張は上記のサイトにも上がっていますが、興味があるところを上げると、nginx-1.6.2をベース。nginxと100%互換性があるダイナミックなモジュールの読み込みをサポート。v3をサポートupstreamの負荷分散方式の追加。plusにしかないとか)少し不満に思うところが強化されています。このエントリではupstreamのヘルスチェックを試してみます。checkを試すまず、Tengineをビルドします。環境はVagrant上のubuntu/trustyです。linkしていますが、システムのライブラリを使っても問題ありません。proxyを行うように設定しました。check用のhtmlを置きます。html8082/live.htmlそして、tengineを起動します。起動プログラム名はnginxのままです。127.0.0.1:8081さっそく何やらでてきました。チェックを行い、upstreamが2つ有効になったようです。ちなみに、上の設定では初期状態がダウンで、2回成功して初めてupstreamのサーバが有効になります。有効になる前にアクセスすると、502になってしまいます。check_statusを設定したpathでupstreamの状態を取得できます。jsonをサポートし、デフォルトはhtmlです。両方とも”up”となっています。残念ながらstatusを操作することはできないようです。起動がちゃんとできているので、upstreamを一つ無効にしてみましょう。check用のlive.htmlをrenameしてみます。127.0.0.1:8082いくつかエラーが表示され、3回失敗しところで8082がdisableとなりました。127.0.0.1:8082と表示され、再び8082が有効となりました。check機能は落ちたサーバを安全に切り離すのに使えるほか、デプロイ時にリクエストを取りこぼさないようにアプリケーションを再起動するのにも使えます。JVMなサーバを運用している場合はうれしいのではないでしょうか。plusと同じようにAPIで状態を操作できたら最高ですねtengine、nginxのかゆいところに手が届く系のプロダクトとして覚えておくとよいかもしれません。その1」のその2です。Deployを実現できるかも」という感じです。unicornの2倍ぐらい速いRackサーバであるRhebokに手をいれてSO_REUSEPORT対応しました。オプションを追加します。Worldなアプリケーションを動かす為のDockerfileはこんな感じになりました。deployするためのツールです。最近ではlestrratさんのgolangバージョンもあります。descriptorを引き継ぎます。Deployを実現しています。shibayuさんのblogが詳しいです。SOCKETのパスを指定せずに起動することもでき、汎用のプロセスの無停止入れ替えツールとしても使う事が出来ます。Dockerコンテナも起動できます。今回はgolang版を使いました。プロセス入れ替え時に、新しいプロセスを起動してから古いプロセスをkillするまでに待つ秒数です。これがないと、新しいプロセスがlistenする前に古いプロセスが終了してしまい、サーバに接続出来ない時間ができてしまいます。HUPシグナルをおくって、エラーがでないか動画撮りつつやってみました。動画ファイル左上がstartserverを実行しているウィンドウ、HUPを受けてプロセスを入れ替えている様子がわかります。左下はApacheBenchの実行、右側はstartserverにHUPを送ってます。received何回かエラーがでています。ありますが、たぶんこれはエラーの数を単純に足しただけでエラーの数自体は20件だと思います。秒間6000リクエスト中の20件なので非常に少ないですが、リクエストの並列数があがるとエラーの件数も増えていく可能性があります。SocketのQueueに残っていたコネクションが解放される(RSTが送られる?)ために起きるエラーで、現状のLinuxの仕組み上、回避するのは難しそうです。Proxyが再接続を行ってくれれば、上の問題は回避できそうです。}}backupなupstreamはおまじないみたいなもんです。Fault今度はwrkをつかってアクセスしつつ、HUPシグナルを送ります。動画ファイル左下のwrkの結果にはエラーが出ていません。無事nginxで再接続してくれたようです。Deployができそうですね。imageとすれば起動前に必要な処理も行えます。Proxyを工夫すれば実用できるかもという感じではないでしょうか。それぞれのプロセスに接続を分散してくれるという機能です。preforkなサーバはlistenしてからworkerをforkし、それぞれでacceptを行うという手順を踏みますが、SO_REUSEPORTを使えばその手順を踏まなくても複数プロセスから同じポートをListenして処理の並列性をあげたり、hot-depolyが実現できます。networking機能とSO_REUSEPORTを使って、複数のコンテナから同じポートをbindできれば、コンテナのhot-deployができるんじゃないかと思ったので、試してみました。SO_REUSEPORTについては以下のblogが参考になります。SOTADockerなしで検証まず、DockerなしでSO_REUSEPORTを試します。GNU/Linux検証はmemcahedを使います。memcachedにSO_REUSEPORT対応patchをあててbuildします。127.0.0.1localhostの11211をbindしました。127.0.0.1同じポートなので、通常であればエラーになりますが、SO_REUSEPORTを有効にしているので普通に起動します。この状態で、11211に接続し、1回setしたのち、接続をやりなおしながら複数回getを繰り返すと、片方のmemcachedには値が存在しないので、getが成功したり失敗したりを繰り返すはずです。bar想定通りの動きとなりました。SO_REUSEPORTつぎはDockerでやってみます。memcached_reuseportおなじ11211を使いますが、普通に起動できました。bar同じような結果が得られました。networking機能とSO_REUSEPORTは組み合わせて使えそうです。いうことで、次はSO_REUSEPORTを有効にしたアプリケーションサーバを起動してhot-deployが可能どうか検証してみようと思います。検索このアーカイブについてこのページには、2015年1月に書かれたブログ記事が新しい順に公開されています。前のアーカイブは2014年12月です。次のアーカイブは2015年2月です。最近のコンテンツはインデックスページで見られます。過去に書かれたものはアーカイブのページで見られます。Typeこのブログはクリエイティブ・コモンズでライセンスされています。