tsuruを構築したときにDockerコンテナを外部に公開する場合は、Service DiscoveryのためにWildcard DNSとローカルのBIND、HipacheのHTTP Routingの仕組みが必要でした。
これでもFlynnやDeis、Deimosに比べると小規模なのですが、もっとカジュアルにバックエンドのDockerコンテナを見つけて、動的にルーティングしてくれるシンプルなリバースプロキシが欲しいです。
Service Discoveryにはいろいろな仕組みがあります。まだ分類が難しいのですが、勉強のためにまとめてみます。
分散ノードへClient Side Load Balancing
Building a smarter application stack - service discovery and wiring for Dockerに、SmartStackを使ったClient Side Load Balancingの仕組みがわかりやすく説明されています。
以前使ったRiakやCouchbaseクラスタでもクライアント側でトポロジ情報を持っていました。
Docker PaaSのRouter
オープンソースのPaaSではリバースプロキシを使って動的ルーティングを用意しています。
この前のtsuruは、HipacheとローカルのBINDでHTTP Routingの仕組みを作りました。
Looking for a 12factor app reverse proxyを読むと、SSLと認証の仕組みを持っているかどうかが気になります。
設定情報の分散データベースと通知
Zero Downtimeで動的に設定情報を変更して反映させるために、バックエンドに分散データベースが必要になります。
特にConsulはDNSと統合できるので、DNS Forwardingを使うローカルのBINDやdnsmasqを建てると、
アプリ側に変更を加えずDNSのインタフェースでService Disoveryができます。
Eventual consistencyの実装としてみると、あらためてDNSは実績のある分散データベースです。
カジュアルな動的HTTP Routing
もうちょっとカジュアルに、リバースプロキシとして動的なHTTP Routingだけを使いたい場合、
HAProxy, Nginx, Hipacheと、動的にバックエンドの設定情報を変更、通知できる仕組みを組み合わせます。
まとめ
今回はシングルノードなので、ミニマルなNginx + Docker Remote APIを使ってみようと思います。
APIのinspectと、monitor events機能を使い、動的にNginxのバーチャルホストの設定ファイルを作成してリロードします。
それにしてもDockerエコシステムはいろいろなアプローチがあっておもしろいです。