2. お前 is 誰 けーえむ / @kamekoopa ただのプログラマ Java, PHP, Scala, Python Play2とかが好き 最近触れてない ボルダリングが上達しない ミニ四駆
概要 vulcand という HTTP プロキシを使って Docker コンテナをブルーグリーンデプロイするという話。 Consul と Nginx を組み合わせて動的にロードバランスするという話とやりたいことは同じだと思う。 vulcand とは vulcand は、Mailgun というメール系 SaaS の開発チームが作った HTTP プロキシ。 etcd をバックエンドに利用した HTTP プロキシ 再起動なしで設定を反映できる HTTP API と CLI プラガブルなミドルウェア ゼロダウンタイムデプロイのサポート リアルタイムメトリクスレポート TLS と certificate の管理 といった特徴を持つ。設定ファイルを etcd に保存して再起動なしで設定反映できるというのが非常に便利なポイントだと思う。 vulcand の仕組み vulcand に 以下の 2 つの主要
先週の Immutable Infrastructure Conference #1 に参加して意識が高まったので、@mirakui さんの発表で言及されていた、Synapse と Serf の組み合わせを試してみました。 Synapse とは Synapse は Airbnb が開発しているサービスディスカバリ用のツールです。簡単に言うと「バックエンドサーバを監視して、HAProxy の設定を書き換えてくれるツール」です。 詳しくは: SmartStack: Service Discovery in the Cloud – Airbnb Engineering Watcher Synapse にはバックエンドサーバの増減を監視するレイヤーとして、Watcher が用意されています。 (https://github.com/airbnb/synapse/tree/master/lib/s
http://nerds.airbnb.com/smartstack-service-discovery-cloud/ Airbnbが同社のエンジニアブログで、Zookeeperとともに、クラウド分散環境におけるバックエンド間の設定変更の自動化を支えているSmartStackを紹介しています。 1) 他の選択肢の検討 DNS: クライアントのライブラリからDNSをネイティブに使う方法だと、プッシュができないことと情報伝播の遅延（キャッシュによって更に悪化）がネックになる。 中央でのロードバランシング: バックエンド間の通信をロードバランサーで集中管理するかたちだと、ロードバランサー自体もしくはルーティングレイヤの障害が大きなリスクとなる。また、F5などの一般的なハードウェアはクラウドでは使えない。AWSのElastic Load Balancingはpublic IPを介さなくてはいけない
tsuruを構築したときにDockerコンテナを外部に公開する場合は、Service DiscoveryのためにWildcard DNSとローカルのBIND、HipacheのHTTP Routingの仕組みが必要でした。これでもFlynnやDeis、Deimosに比べると小規模なのですが、もっとカジュアルにバックエンドのDockerコンテナを見つけて、動的にルーティングしてくれるシンプルなリバースプロキシが欲しいです。Service Discoveryにはいろいろな仕組みがあります。まだ分類が難しいのですが、勉強のためまとめてみます。 tsuruを構築したときにDockerコンテナを外部に公開する場合は、Service DiscoveryのためにWildcard DNSとローカルのBIND、HipacheのHTTP Routingの仕組みが必要でした。 これでもFlynnやDeis、Dei
npm install --save-dev coffee-script npm install --save-dev protractor npm install --save-dev grunt-protractor-runner npm install --save-dev protractor-coffee-preprocessor npm install --save-dev grunt-exec coffee-script CoffeeScript のコンパイラ はじめ -g で入れていたのだがプロジェクトの中に入れないと使えなかった protractor angularJS 御用達の E2E テストフレームワーク selenium を angularJS プロジェクトで使えるようによしなにカスタマイズしている grunt-protractor-runner protracto
Aug 21, 2014 最近dockerの事ばかり考えてます。 マルチホストでdockerを運用する際、真っ先にぶちあたる問題はコンテナ間の連携をどのようにして実現するか、あるいは広義にはService Discoveryをいかにして実現するか、ということだ。 いろいろ調べたり作ったりした結果わかったことをまとめておく。 シングルホストの場合 まずシングルホストの場合についておさらいする。 dockerでコンテナ間のリンクを行う方法はたくさんある。シングルホストであれば一般的なのはLinking Containersである。 まずリンク先となるDB用コンテナを起動する docker run -d --name db training/postgres 次に、リンク元のwebアプリ用コンテナ起動する docker run -d -P --name web --link db:db trai
Introducing flannel: An etcd backed overlay network for containers https://coreos.com/blog/introducing-rudder/ Things are not as easy on other cloud providers where a host cannot get an entire subnet to itself. Rudder aims to solve this problem by creating an overlay mesh network that provisions a subnet to each server. Running Kubernetes Example on CoreOS, Part 2 - Qiita http://qiita.com/yungsang
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く