サービス・ディスカバリのためのConsul入門
Serfの足りない機能を補うConsul 前回の記事の復習になりますが、Serf（https://serfdom.io）の主要な役割は、オーケストレーション（自動的に複数のサーバなどのインフラ上で処理すること）と、クラスタ上のメンバ管理です。 Serfを単純なツールとして見た場合は、オーケストレーションを簡単に行える便利なツールと言えるでしょう。しかし、実際の運用シーンを考えますと、次のような弱点が浮かび上がります。 メンバ管理はSerfエージェント間の通信正常性が基準であり、アプリケーションやミドルウェアの状況に応じた自動処理が行えない（サーバは稼働しているが、ウェブサーバやデータベースが停止するような状況） 何らかの状態を保持する仕組みがないので、冗長化の仕組みは自分で考慮する必要がある Serfクラスタとの通信には独自のCLIかAPIを使う必要があり、他のツールとの親和性が低い これ
CoreOS 上の Docker コンテナのサービス情報を registrator を使って etcd へ自動登録する - Qiita
概要 registrator というサービス検出・登録・削除専用コンテナを使って、CoreOS 上に起動する Docker サービス（rails や redis, elasticsearch などポートを外部にさらすもの）を etcd へ自動登録するという話 サービス登録の選択肢 Docker をマルチホストで使おうと思ったときに出てくるのがサービスディスカバリの問題。例えば Web アプリケーションコンテナをロードバランサに登録しようと思ったとき、何らかの方法でアプリケーションコンテナがどのホストのどのポートで起動しているのか知らせる必要がある。 サービスディスカバリ用ミドルウェアとして Consul や etcd がある。そういったものに Docker コンテナとして起動したサービスを登録するには選択肢は 3 種類ある（他にもあるかもだけど） 起動するサービス自身が登録する: Webh
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
etcd vs consul vs ???
