RabbitMQ と再送について
概要 : AMQP のプロトコルを読むと、一瞥して送信はパケットを送るだけ、受信はソケットを読み込むだけのようにも見える。しかしながら、実際に書いてみると、再送処理を自前で実装する必要があるため、現実には大変に複雑な処理が必要だ。 そもそもなぜ RabbitMQ を使うのかという話、あるいはなぜ再送が必要かという話たんにコンポーネント同士が疎結合で通信したいのであればわざわざ MQ を使う必然性は皆無である。ごくあたりまえに TCP で通信すればそれでいい。暗号通信が必要なら当然 SSL でいいし、パケットエンティティに依存する複雑な L7 リバースプロキシを MQ を使って実現することも、不可能ではないが、普通そういうのは varnish とかでやるだろう。 MQ において優れているのはデータの durability だ。つまり、一旦キューにためておけば、その両側のコンポーネントは好き勝
lxcについてくるlxc-execute(1)がお手軽すぎてヤバい
lxcは普段は仮想マシンみたいなのを作る用途で使うわけだけども、そんな大規模の必要ないよプロセスが一個ぽつんと隔離されて起動してくれればいいよ、というありがちなケースをカバーしてくれるのがlxc-execute(1)で、つまりこれはsudo(1)とかchroot(1)とかfreebsdのjail(1)みたいな使い方をするわけだ。特徴としては、 まずpid/uidの名前空間が他と分離されるので、仮にrootが奪取されても他のプロセスをkillしたりできないネットワークも他と分離されるので、仮にrootが奪取されてもパケットスニファとかからは何も見えないもちろんファイルシステムも分離されてるので、仮にroot奪取されてもファイル弄られたりしないデバイスへのアクセスも禁止なので、仮にroot奪取されても/dev/sda1をmknodして適当なマウントポイントにマウントとか不可、/dev/kmem
.travis.ymlめぐり
Travis CI というGithubと連動してGithubにコミットすると勝手にテストが走ってテスト結果を通知してくれる、ようするにJenkins as a Serviceみたいなやつがあって、とても便利なので知らなかった人はこの際使いましょう。 そんでTravisの設定ファイルが.travis.ymlで、プロジェクトのディレクトリに置いておくだけでいいんだけど、ごく最近rubyの.travis.ymlを書き直したので、そのときに調べたものを開陳しておこうというエントリ。 https://github.com/ruby/ruby/blob/trunk/.travis.yml これが最終的に今のRubyの.travis.ymlで、俺の趣味によるやりすぎ気味のコメントと、language: cの例としてはもっとも網羅的な(つまり微に入り際に穿った)記述が特徴。Cのプロジェクトはまずこれをコピ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
