- SerfのメインディッシュはGossip protocol、つまりP2Pでクラスタを構成するにあたりグループメンバをいい感じに管理するところ
- ConsulのメインディッシュはRAFT algorithm、つまりクラスタのメンバで情報を同期させる（同意アルゴリズム）ところ
- しかしConsulの全機能を利用するため、内部でSerf(Gossip protocol)を利用している
- つまり、クラスタを組むにあたり
- Consulの機能が欲しければConsulを使えばいい
- Serfの機能で十分ならSerfをもとに自作すればいい
となるのではないかと。
両方で「Orchestration」と言っているが、この中身はレイヤーが分かれていることに留意したい。
- 様々なコンポーネント、マネージドサービスを正しく意図した組み合わせで起動する層
- コンポーネントを構築してから上手に初期化する層
- コンポーネントに変更があったときにうまく協働させる層
このうち、Terraformの得意分野が1. Consulは2./3. （なお 2. についてはクラウドなら cloud-init という別のミドルウェアに任せるのが良い）ということ。
ちなみにTerraform経由で投げ込むそれぞれのパーツを作るために存在するのがPacker。
ここからはちゃんと触っていないので
- 単に「デプロイ」と考えるのなら、 Consul + stretcher とか Serf + mamiya とかでいいのでは。
- 実際僕は前者の組み合わせで困ってないし、それでもすごく便利になった。
- Railsアプリをボーンと投げる以上の複雑なデプロイ運用になったり、Continuous Deploymentがより過激な感じになってもっと上のレイヤーで監視したいとかになったら、活用を検討するかも。。
- 機密情報について考えるのは頭が痛いので多分重要。
- Consulとの絡みは、バックエンドとして使えること、ConsulのACLの仕組みをそのまま使えるというところらしい。