Chef/Puppet/Ansible などの従来の「静的」構成管理ツールからグローバルな状態を取り除き、代わりに中央集権型/分散型ツールに構成を保存するという新たな傾向があり、その主なプレーヤーは次のようになります。
- ズーキーパー (アパッチ)
- 領事（Hashicorp）
- エウレカ (Netflix)
これらのツールはそれぞれ動作が異なりますが、原則は同じです。
- 環境変数やその他の動的構成 (つまり、変更される可能性があるもの) をこれらのツールにキーと値のペアとして保存します
- 起動時にクライアント経由でこれらのツール/サービスに接続し、構成 KV ペアをプルダウンします。これには通常、クライアントがサービス名 ("
MY_APP") と環境 ("DEV"、"PROD" など) を指定する必要があります。
このすべてを美しく説明し、十分なコード例を提供する優れた Consul Java クライアントがあります。
これらのツールについての私の理解では、これらのツールはZab、Paxos、Gossip などのコンセンサス アルゴリズムの上に構築されており、構成の更新がノード全体に最終的な一貫性を保ちながらほぼバイラルに広がることを可能にします。したがって、myapp20 個のノードを持つアプリがある場合、それらの 1 つに構成変更myapp01をmyapp20加えると、その変更は 20 個のノード全体に数秒/分かけて自然に「広がる」という考えがあります。
私の問題は、これらの更新が実際に各ノードにどのようにデプロイされるかです。クライアント API (上記でリンクしたもの、ZooKeeper API、または Eureka API) のいずれにも、集中型サービス (たとえば、Consul cluster) は、設定の更新をプッシュしてリロードしたいと考えています。
だから私は尋ねます：これはどのように機能するはずですか（動的構成の展開とクライアントでのリロード）？ConsulのAPIは最も高度なIMHOのようですが、これら3つのツールのいずれかに対する実行可能な答えに興味があります.