AWS Compute Blog Service Discovery via Consul with Amazon ECS My colleague Matt McClean sent a nice guest post that demonstrates how to use Consul for service discovery with Amazon ECS. —– With the advent of modern microservices-based architectures, many applications are now deployed as a set of distributed components. In such architecture, there is a need to configure and coordinate the various a
etcd/consulに認証情報を安全に保存する 分散Key-Valueストアとしてetcdやconsulの利用が増えている.ここにアプリケーションの設定値などを保存し,各ホストからそれらを購読して利用する. また,X-as-a-Serviceといった外部サービスの利用も多くなってきた.その場合API Tokenやパスワードといった認証情報が必要になる.PaaSやTwelve-factor的なアーキテクチャを採用する場合は,それらの値を環境変数に保存して利用することが多い(危険であるという意見はある.cf. http://techlife.cookpad.com/entry/envchain).etcdやconsulといった分散Key-Valueストアの利用を前提としたアーキテクチャでは,そこに外部に漏らしたくない設定値も一緒に保存してしまうのがシンプルになる. しかし,そういった設定値を
概要 最近,consul,etcd,ZooKeeper といった,いわゆる Coordination Service(この名前は ZooKeeper の論文から拝借した)の実装が頻繁に行われている.本記事では,開発が盛んな背景を踏まえた上で,オープンソース実装の Coordination Service の比較を行う. Chubby から現在まで Paxos が Google の手によって Chubby という形で実用化された後,故障検出+分散合意アルゴリズムを用いた高可用KVSという組み合わせによる Coordination Service のオープンソース実装がいくつが出てきた.そのはしりが ZooKeeper である.ZooKeeper は Hadoop ファミリではデファクトスタンダードの Coordination Service であり,Hadoop を初めとして HBase,M
Serfの足りない機能を補うConsul 前回の記事の復習になりますが、Serf(https://serfdom.io)の主要な役割は、オーケストレーション(自動的に複数のサーバなどのインフラ上で処理すること)と、クラスタ上のメンバ管理です。 Serfを単純なツールとして見た場合は、オーケストレーションを簡単に行える便利なツールと言えるでしょう。しかし、実際の運用シーンを考えますと、次のような弱点が浮かび上がります。 メンバ管理はSerfエージェント間の通信正常性が基準であり、アプリケーションやミドルウェアの状況に応じた自動処理が行えない(サーバは稼働しているが、ウェブサーバやデータベースが停止するような状況) 何らかの状態を保持する仕組みがないので、冗長化の仕組みは自分で考慮する必要がある Serfクラスタとの通信には独自のCLIかAPIを使う必要があり、他のツールとの親和性が低い これ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く