Hack for Docker's Network * ICC(Inter-Container Communication) * iptables rules * pipework Read less
![Hack for Docker's Network](https://cdn-ak-scissors.b.st-hatena.com/image/square/57d72f1338129576b7a8ded94a29bf28ccceb63f/height=288;version=1;width=512/https%3A%2F%2Fcdn.slidesharecdn.com%2Fss_thumbnails%2F20140212-hack-for-docker-network-140212212814-phpapp01-thumbnail.jpg%3Fwidth%3D640%26height%3D640%26fit%3Dbounds)
※ internal container connectionは標準でONでした。誤り修正 業務には利用してませんがDocker楽しいです。 AIX6.1Lで導入されたWPARに触れた時のような楽しさを感じています。 さてDockerで起動したコンテナ同士で通信したいケースがあると思います。 Link Containerという機能らしいです。 OS Xで稼働するboot2dockerで試してみました。 boot2docker内のDockerデーモン設定 Docker起動時にInter-container communicationフラグ(-icc=false)をOFFにすると Linkオプションで指定したコンテナ同士だけで通信できるようになるみたいです。 英語がさっぱりわからん! orenomac$ boot2docker start [2014-03-08 02:28:41] Start
Yesod is a Haskell web framework for productive development of type-safe, RESTful, high performance web applications. March 5, 2014By Michael SnoymanView source on Github I got a request to write up some examples of using network-conduit for server and client apps. I'm going to try to cover a few of the examples requested. I'm also going to be demonstrating some usage of the new conduit-combinator
やりたいこと fluentdを使うにはファイルディスクリプタ(FD)の数を増やしておく必要がある。これをdockerコンテナに対して設定したい。しかしこれは残念ながらホスト側やdocker側の設定が必要になりDockerfileには書けない。ここを参考に設定してみた。fluentdに限った設定ではないので、いろいろな用途に使えるはず。 とりあえずこうしてる どなたかもっとよい手順があれば教えてくだされ。 ホスト:Debian 7 on Google Compute Engine ゲスト:Ubuntu 12.04 Docker v0.8.1 ホスト側のFDを増やす /etc/security/limits.confでFDを増やしても自動起動スクリプトには効いてくれないので困っていた。外道父さんのエントリを参考に、/etc/initscriptを以下のように書いて追加したらうまく動いた。外道父
BazQux(バズクックス)は、Google Reader の代替として密かに注目されている RSS リーダです。実装と運用を一人でやっている Vladimir Shabanov さんによると、BazQux のウリは、 高速である ブログのコメントも表示できる 複数のビューがある モバイルに対応している などらしいです。 BazQux のフロントエンドは、Ur/Web で記述されたコードから生成された JavaScript、バックエンドは Haskell だそうです。高速なのは、Haskell のおかげであると Vladimir さんは言っています。我々が開発している HTTP エンジンの Warp も使われているそうです。 現在、僕は Haskell 用の HTTP/2 ライブラリの作成に取り組んでおり、必要な技術を調べている過程で、redditでの議論のことを思い出しました。今回、よく
tl;dr 書いていたら思わず長文の大作になってしまいましたので、プロトコルオタ以外の方は文章の多さに退屈されるかと思います。GoogleマップサービスでSPDYの問題が発覚し、GoogleがLinuxカーネルに修正を加えて対応したというお話です。将来 Linux + nginx + SPDY を使いリバースプロキシでサービス運用を検討されている方は参考になるかもしれません。 1. はじめに、 プロトコルに執着する年寄りエンジニアの老害が叫ばれて久しい。 年甲斐もなく自分好みのパケットを追っかけるおやじエンジニアの姿を見て眉をひそめる若者も多いと聞く。 そんな批判に目もくれず、今日も一つ、プロトコルオタのネタをブログで公開したいと思いますw 今回はちょうど1年ほど前に書いたブログ記事 「GmailがハマったSPDYの落とし穴」の続編です。といっても今度の舞台は、Googleマップ。ネタ元も
タイトルがすべてでございます。 NICの割り込み処理が1コアに集中してしまい、ボトルネックになって性能が出ない場合があるという話は最近広く知られていると思います。 NICのハードウェアレベルで割り込みを分散してくれる RSS(Receive Side Scaling) という仕組みがあり、それを利用すれば特になにもしなくても複数コアに分散されるはず、と思っていたのですが、どうも特定のマシンでそうならない。 # cat /proc/interrupts CPU0 CPU1 CPU2 (省略) CPU11 64: 1256214 0 0 ... 0 IR-PCI-MSI-edge eth1-0 65: 225711 0 0 0 IR-PCI-MSI-edge eth1-1 66: 402906 0 0 0 IR-PCI-MSI-edge eth1-2 67: 723539 0 0 0 IR-P
At work, we are evaluating Docker as part of our “epic next generation deployment platform”. One of the requirements that our operations team has given us is that our containers have “identity” by virtue of their IP address. In this post, I will describe how we achieved this. But first, let me explain that a little. Docker (as of version 0.6.3) has 2 networking modes. One which goes slightly furth
プログラマ兼経営者 登 大遊(のぼり だいゆう) 1984年生まれ。29歳。2003年、筑波大学1年に在学中、VPNソフトウェアSoftEtherの開発が「未踏プロジェクト」に採択される。2004年4月、ソフトイーサ株式会社を起業、代表取締役に就任。SoftEtherの後継となるVPNソフトウェアやサービスを次々に開発。筑波大学大学院システム情報工学研究科コンピュータサイエンス専攻博士後期課程に在学中の大学院生でもある。 「低レイヤー」、「異常な努力」、「AC」、「怠けるために仕事をしてるんです」──ソフトイーサ株式会社の経営者で、自らプログラムを書き続ける登大遊(のぼり だいゆう)の語り口は独特だ。だが、よく耳を傾けているうちに、登の中の価値観が浮かび上がってきた。登は、プログラマの言葉である“ハック”をなにより重んじる生き方をしてきたのだ。 まず時計の針を10年前に戻すところから始めよ
TCP Fast Open – Webを速くするためにGoogleがやっていること Make the Web Faster 4 – Jxck HTTPは、その下層にあたるトランスポートレイヤーのプロトコルとして、通常TCPを使用します。 したがって、TCPのレイヤで速度が改善することは、そのままWebの高速化につながる可能性があるといえます。 GoogleはWebを速くするための活動として、TCPのようなプロトコルレイヤの改善にも取り組んでいます。 今回はその中の一つ、TCP Fast Openを取り上げ、解説と動作検証、簡単なベンチマークを行います。 検証環境等は最下部に記載します. Make the Web Faster: TCP Fast Open 3 Way Handshake TCPは、「正確、確実にデータを届ける」ことを重視した設計になっています。 特に接続確立時には、双方の状
5.5 Graphic representation of the flow of messages in the basic Paxos
3GやLTE、さらには無線LANなどでインターネットに接続することなくスマートフォンのWi-Fi機能を利用して端末同士がつながり合うことでメッセージのやりとりを行い、通信時にはアプリを利用する端末が通信の中継点になるので、利用者が多ければ多い程広い範囲にメッセージを届けられるようになるコミュニケーションアプリが「TinCan」です。 TinCanアプリのイメージは以下のムービーを見るとつかむことができます。 TinCanではネットワーク通信を利用せず、アプリユーザーを中継点として広がる端末ネットワークを使うことでメッセージのやりとりが可能になります。 アプリは以下からインストール可能。 TinCan - Google Play の Android アプリ https://play.google.com/store/apps/details?id=com.hubski.com.kvh.tin
2013年11月11日 下り最大2Gbps!So-netが月4,980円で勝負してきた高速通信サビース「NURO光」がすげぇ! カテゴリ:感想便利なサービス インターネットプロバイダのSo-netが下り速度が最大2Gbpsという凄まじく高速なインターネットサービス「NURO 光(ニューロ)」を開始しました! 「NURO 光」は下り速度最大2Gbps・上り速度最大1Gbpsという世界最速の光ファイバーサービスで、例えば、みなさんの身近なLTEと比べると、その速度は比べ物にならないくらい速い! So-netそのものはピンクのクマ「モモちゃん」で知っている人も多いかもしれません。 驚いたのが、回線料金・プロバイダ料金・無線LAN(Wi-Fi)機器・セキュリティサービスが全部込みで月額4,980円という安さ! もうこれはすぐにでも体験してみたい!と思い、早速、銀座のソニービルで期間限定のキャンペー
更新し忘れたが、既に下記の脆弱性は修正されている 4/11/2013 6:42 PM 追記: 明日エンジニアと調査するとカスタマーサポートから連絡があり、また近日アップデートパッチを用意するとのことだ。 先日紹介した、Satechi Smart Travel Routerだが、ふと直感的にセキュリティに問題があるような予感がしたので、自分のルーターをアタックしてみた。 結果から言うとCSRFが存在し、外部からインターネット越しに細工をしてあるURLを踏ませることで、ルーターのパスワード、SSIDを書き換えたり、WiFi to WiFiのリピータ機能のソースとなるWiFiを勝手に別の場所に書き換えて、Man in the middle攻撃を成立させたりできることが発覚した。 自分がどのようにSatechi Smart Travel Routerの脆弱性を発見したのかを動画にとったので、無編集
Linux サーバでの「Too many open files」エラー対策について調べたのでまとめてみました。 確認した OS は CentOS 5.9 と CentOS 6.3 です。 「Too many open files」は Linux でプロセスが開けるファイルディスクリプタの上限に達してしまうと発生するエラーです。 「ファイルディスクリプタ」という名前ですが、 Linux ではソケットもファイルディスクリプタなので、ファイルを開いた場合だけでなく、ソケットを使って通信を行う場合にもファイルディスクリプタが使用されます。 そのため、Apache や Tomcat などで高負荷なサイトを運用している場合などには、比較的遭遇する確率の高いエラーではないでしょうか。 このエラーを回避するため、プロセスがオープンできるファイルディスクリプタの上限を変更します。 まずは以下のコマンドを実行
SDxCentral’s monthly top 10 stories — January 2024 Summary | Nicole Cunningham | February 3, 2024 2024 is already shaping up to be the year of cybersecurity, with seven of our top 10 stories from January related to the security industry. What is AI networking? Use cases, benefits and challenges Definitions | Taryn Plumb Artificial intelligence networking focuses on ongoing “day 2” management, main
去年ぐらいから情報通信業界ではSDN(Software Defined Networking)が話題です。 展示会に行けば、みんながSDNについて語っているようにも思えてしまいますし、実際に「SDN」という単語が入っている講演や展示に来場者が凄い勢いで集まっています。 SDNのビッグウェーブに乗るか乗らないかと言えば、乗らないと損であることが容易に想像できる状況です。 ただ、これまでなんかずっとSDNがワクワクできない感じが続いていました。 個々の技術や考え方は凄く面白かったりするのですが、全体としてSDNの話を聞いていても、何か釈然としない感じというか、モヤモヤした感じがあったわけです。 で、ついさっき「あ!こういうことか!?」みたいなものが自分の中で発見できたような気がしたので、嬉しくなって文章を書いています。 自分の中での発見のきっかけ 私がそういったことを思ったきっかけは、さくらイ
オープンソースのパケットキャプチャソフト「WireShark」。。。ネットワーク関係のお仕事をされている方は使った事のある方も多いかと思います。 ※「Ethereal」が開発終了し、WireSharkへと引き継がれていったものです。 WireSharkを使うと、ネットワークを流れるパケットをキャプチャリングすることが出来るわけですが、基本的にはGUIプログラム。お手軽にGUI操作でキャプチャが出来るのも良いんですが、TcpDumpのようにコマンドラインで実行したいという時もありますよね。 ※バッチファイル化したり、シェルでごにょごにょしたい時とか。あとは、GUIだと膨大なパケットを表示させる場合に、かなりのメモリを消費しますので、プログラムごと落ちてしまうこともありますし。 「あ〜、WireShark。。。コマンドラインで実行出来たら便利なのに。。。」と思っている方に朗報。実はコマンドライ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く