2015/11/13追記 docker 1.9 正式版での検証した記事を、マルチホストDockerネットワーキング（正式版 native overlay）で公開した。 正式版のoverlay networkは、サブネットアドレスが指定できるようになるなどかなり進化しているため、今後はコチラを参照してほしい。 ずいぶん間が空いてしまったが、マルチホストで動作するDockerネットワーキングツールについてのまとめ第四弾。 （第一弾：pipework＋GRE） （第二弾：etcd+flannel） （第三弾：weaveworks/weave） 今回はDockerのnative overlay networkを取り上げる。 Dockerのnative networkについて Docker libnetworkのWiki pageにあるように、Dockerは1.7.0からネットワーク機能を「libn

みなさんDockerを利用しているでしょうか。Dockerを使ったことのある方は、そのネットワーク周りに不便を感じたことはないでしょうか。今回はDockerのネットワーク周りを概観し、Dockerをコンテナ型仮想化エンジンとして見た場合のネットワーク周りの問題点について解説します。また次回以降の記事で、その問題点を解決する既存の取り組みやツールについて触れていきます。 Dockerとは そもそもDockerとは、当時のdotCloud社（現Docker社）が自社のパブリックPaaSを実現するために、アプリケーションの実行環境をポータブルにしていつでも簡単に立ち上げられるように開発した技術が根幹となっています。様々なLinuxコンテナ技術を用いたリソース隔離も、コピーオンライトで差分管理を行うファイルシステムも、またOSやミドルウェアを自動構成してデプロイする仕組みも、もともとはPaaSを形

絶対に押さえておきたい、超高速システム構築5要件と3つのテクノロジ：クラウド時代のアジャイルシステムインテグレーション（2）（1/4 ページ） 多くの企業にとって“クラウドファースト”がキーワードとなっている今、クラウドを「適切に」活用する能力はSIerやIT部門のエンジニアにとって必須の技能となっている。今回はビジネス要請にアジャイルに応える「クラウドファースト時代のシステムインテグレーション」に必要な要素技術を解説する。 連載目次 クラウド時代のアジャイルなシステムインテグレーション 前回はクラウドが多くの企業に浸透している現状とともに、従来の「システムごとに最適化された、手作業を前提としたシステムインテグレーション」と、「クラウドを前提としたアジャイルなシステムインテグレーション」の違いを解説しました。今回はもう少し踏み込んで、後者のスタイルを実現するための要素技術を解説したいと思い

※ 2014年SoftLayer Advent Calendar 1枚目の21日目です。 SoftLayerの特徴のひとつとして、broadcastやmulticastが通り、IP aliasも利用できる「普通」のネットワークを持ったベアメタルサーバを利用できる点が上げられます。 今回はその特徴を最大限に活用し、SoftLayer上にOpenStack Icehouseをインストールします。 今回構築するOpenStack on SoftLayerの全体像 構築要件 今回のOpenStack on SoftLayerは、構築者が個人で検証活動に利用することを前提に、以下の要件を満たすようにインフラを構成します。 OpenStackの各種コンポーネントは、同一ベアメタルサーバ上に、できる限り簡単にインストールできるようにする インターネットにはOpenStackのAPIやGUIを公開しない

この記事は、Wakame-vdc / OpenVNet Advent Calendar 2014の19日目です。 OpenVNetのInstall Guideを見る限り、OpenVNetが動作保証されているOSは下記のようにかなり限定されています。 OS Kernel RHEL6系（CentOS6系）は2020年11月30日までメンテナンスされるとしても、最新OSで動作するに越したことはありません。そこでCentOS7にOpenVNetをインストールしてみました。 Vagrant Box 下記手順を一つずつ実施するには、かなり手間と時間がかかります。そこでchef/centos-7.0のbox上にOpenVNetをインストール（下記手順の1.〜7.まで実施）した、openvnet-centos7 boxをVagrant Cloudで公開しました。 $ vagrant init nmatsu

いつでも簡単にサーバを立ち上げることができるクラウドは大変便利ですが、オンプレミスで実装している機能が全てクラウド上で再現できるとは限りません。特に仮想ネットワークはアーキテクチャが複雑なため、仮想IPとmulticastを用いた冗長化などunicast以外の通信が必要な機能は、対象のクラウド上で問題なく動作するのか実際に確かめる必要があります。今回はSerfクラスタをクラウドの仮想ネットワーク上へ構築する場合を例に取り、AWSとSoftLayerの仮想ネットワークのアーキテクチャの差異について見ていきます。 AWS VPCのネットワーク AWS（Amazon Web Service）は、Amazon.comが提供しているクラウドサービス群の総称です。コンピュートサービスのAmazon EC2（Elastic Computing Cloud）やストレージサービスのAmazon S3（Sim

AWS VPC上の仮想ネットワークはmulticastとbroadcastを明示的に禁じているが、SoftLayerの仮想ネットワークにはそのような記述は見当たらない。 ということで、Serf0.4から実装されたmulticastDNSを用いたdiscover機能を使って、SoftLayerのPrivateVLAN上でmulticastが通るのか実験してみた。 --11/01追記-- 異なるPrivateVLANに所属するノードでも自動ディスカバリできるか追加実験してみた。 実験１ SoftLayerで3台のVirtual Serverを起動（DCはSan Jose 1、OSはUbuntu Server 14.04）。 これらのeth0は同一のPriavateVLAN（VLAN 2603） & Private Subnet（10.54.222.128/26）に所属している。 ホスト1 (s

AWS上でシステムを運用する場合、Amazon CloudWatchでシステムを監視させ、障害発生時にCloudWatchから通知を受け取ることで、迅速に障害対応をすることができます。今回はCloudWatchをGmailを介してIFTTTと連携させ、CloudWatchからの通知をソーシャルサービスで受け取る方法について解説します。 統合監視とAmazon CloudWatch システムダウンやパフォーマンス劣化などに対応するために、 Zabbix や Hinemos 等を利用した統合監視システムを別途構築する場面は多々あります。しかし統合監視システム自身がダウンしてしまっては意味がないので、統合監視サーバや監視ネットワーク自身も高可用にする必要があり、その構築には手間とノウハウが必要になります。 そのため情報発信サイトのようなシンプルで軽いシステムをクラウド上で運営したい場合には、ク

CodeZine編集部では、現場で活躍するデベロッパーをスターにするためのカンファレンス「Developers Summit」や、エンジニアの生きざまをブーストするためのイベント「Developers Boost」など、さまざまなカンファレンスを企画・運営しています。

CodeZine編集部では、現場で活躍するデベロッパーをスターにするためのカンファレンス「Developers Summit」や、エンジニアの生きざまをブーストするためのイベント「Developers Boost」など、さまざまなカンファレンスを企画・運営しています。

WebRTCを用いた遠隔作業支援システムを作ります。 前回 はシグナリング処理からスマートグラスのカメラ映像をリアルタイムで監視端末に表示する部分までを解説しました。最終回の今回は、DataConnectionを用いたテキストメッセージや画像の転送処理、及び接続終了処理について解説し、遠隔作業支援システムとして完成させます。 DataConnectionによるデータ転送の処理フロー 前回 までで、信頼性の有る状態でDataConnectionのP2P接続が確立しました。では実際に、監視端末からスマートグラスへデータを転送します。 遠隔作業支援システムではDataConnectionを通じて以下3種類のデータを転送しますが、P2Pの通信経路を通すためにはデータをシリアライズしなければなりません。 イベント通知 テキストメッセージの転送 画像の転送 転送データのシリアライズ PeerJSはD

WebRTCを用いた遠隔作業支援システムを作ります。 前回 はCoffeeScriptで記述されたモジュールの全体構成と、PeerJS & MediaStreamの初期化処理について説明しました。今回はWebRTCの肝となるシグナリング処理からスマートグラスのカメラ映像をリアルタイムで監視端末に表示する部分までを解説します。 シグナリングの処理フロー 前回 まででPeerJSの初期化が完了し、peerjs-serverとのWebSocket接続が確立されてユニークIDが通知されました。またMediaStreamも取得してあり、デバイス自身のカメラやマイクとの接続が確立しています。 では次に、スマートグラスと監視端末をP2P接続するシグナリングの処理フローとPeerJSを用いた実装をステップを追って確認しましょう。以下３つのステップで処理が行われます。 スマートグラスのPeerIDを監視端末

WebRTCを用いた遠隔作業支援システムを作ります。 前回 はWebRTCの概要について説明しましたが、今回は遠隔作業支援システムを作るための準備として、スマートグラス（ Vuzix M100 ）とサーバサイド（ node.js + express + peerjs-server ）の環境構築について解説します。 スマートグラス Vuzix M100とは Vuzix M100 はVuzix社が開発した片眼非透過型のスマートグラスです。Android4.0系で動作しており、カメラ・マイク・スピーカーやGPS&磁気コンパス、3軸のジャイロ&加速度センサーなど、ひと通りのセンサー類が搭載されています。 Vuzix M100にはヘッドセットや保護メガネへのマウント用具が付属するなど、業務用途として利用することも念頭に置かれています。実際昨年開催されたSAP社が主催するイベント SAPPHIRE N

WebRTCという技術をご存知でしょうか。WebRTCとは「ブラウザ上でリアルタイムコミュニケーションを実現するためのAPI仕様」のことで、Flash等のプラグイン無しにカメラ映像や音声の共有、データの双方向通信を可能とする技術です。このWebRTCとスマートグラスを活用し、遠隔作業支援システムを作ってみましょう。 WebRTCとは WebRTCは "Web Real-Time Communication" から作られた言葉で、ビデオデバイス/オーディオデバイスから得たストリームデータのブラウザ間双方向リアルタイム通信や、テキストデータ・バイナリデータのブラウザ間双方向データ通信などを定めています。WebRTCはHTML5で新しく策定された規格で、WebRTCのAPIレベルでの標準化はW3C、プロトコルレベルでの標準化はIETFで進められています。 WebRTCのコア機能 WebRTCは規

WebRTCとNode.jsを用いたリモート監視システムのサンプルを書きました。 WebRTCを自力実装するのは結構面倒なため、PeerJSを利用しています。 またシグナリングサーバもPeerJSが提供するpeerjs-serverを利用しました。 利用したライブラリ peer:0.2.5 express:4.2.0 node:0.10.28 動作検証した環境 Google Chrome 35.0.1916.153 / Mac OS X 10.7.5 / Macbook Air Mid 2011 Google Chrome for Android 35.0.1916.141 / Android 4.2.2 / HTL22 Google Chrome for Android 35.0.1916.141 / Android 4.0.4 / Vuzix M100 Vuzix M100 Vuzix

データセンター仮想化からのスピンアウト Wakame Software Foundation（WSF）は2013年10月28日、仮想ネットワークオープンソースソフトウェア「OpenVNet」の初版をリリースした。同ソフトは、仮想ネットワークを実現するソフトウェアとして、世界で初めてOpenFlowの最新バージョン1.3に対応したオープンソースソフトウェアだ。LGPLv3に基づいて公開されており、誰でも無料で自由に利用できる。 今回は、OpenVNetの開発元で、WSFの運営代表を務めるあくしゅ（axsh）の代表取締役 山崎泰宏氏に同技術について話を伺った。 「OpenVNetは、WSFの既存プロジェクトである『Wakame-vdc』に組み込まれた技術を抜き出し、いくつかの機能を追加した“スピンアウト技術”です。そのため、Wakame-vdcを抜きにして話をすることはできません」 Wakam