Consul 0.5 がリリースされました。久々のメジャー・アップデートです。新機能や変更点がまとめられた内容が、HashiCorp のブログに投稿されました。例によって、自分の情報整理用の翻訳であり、死蔵しておくのもアレなので、参考程度にどうぞ。

■ Consul 0.5

私たちは Consul 0.5 のリリースを誇りに思います。Consul とは、現代のデータセンタが必要とする多くの機能、例えば、サービス検出（service discovery）や設定やオーケストレーションなどを行う、データセンタ・ランタイムです。分散や高可用性、千台ものノードにスケールすることの立証や、複数のデータセンタにまたがるサービスを行えるように設計されています。

数か月前に行った Consul のメジャーリリースでは、その驚くべき安定正により、大きな新機能、ユーザ経験の改善、バグ修正に集中することができました。

Consul 0.5 には多くの新しい機能が提供されています。自動クラスタリング（automated clustering）、Atlas を経由したシームレスな UI の統合、ACL の拡張、シンプルな N+1 デプロイ、ノードやサービスのメンテナンスモード、HTTP ヘルスチェック内蔵、ephemeral keys（一時キー）、セッション TTL、キーローテーション等、その他多くの機能があります。

Cosul 0.5 のダウンロードはこちらからできます。changelog はこちらです。

0.5 の主な新機能について学ぶには、以下を読み進めてください。

■ 自動クラスタリング（Automated Clustering）

Consul クラスタの構成にあたって、エージェントが既存のクラスタに参加するには、おなじみの IP アドレスや DNS アドレスを提供する必要がありました。これは Consul における鶏が先か卵が先かという問題を引き起こします。解決にはいくつかの方法がありますが、Consul 0.5 は auto-join （自動参加）機構によって、あらゆるネットワーク上の Consul エージェントの自動検出とクラスタ化を行います。これは良く知られたアドレスを管理するという重荷を取り除くので、この設定管理の自動化により、Consul のインストールを単純化します。

これは Consul の「auto-join」と呼ばれる機能であり、Atlas の無料アカウントを通して利用できます。

Atlas の auto-join （自動登録）を使うのは単純で、無料の Atlas アカウントと API トークンを使います。「-atlas」という CLI のフラグでクラスタ名を指定し、「-atlas-join」フラグを有効化しますと auto-join できます。

$ export ATLAS_TOKEN=...
$ consul agent -atlas armon/test -atlas-join
==> Consul agent running!
 Node name: 'foo'
 Datacenter: 'dc1'
 Server: false (bootstrap: false)
 Client Addr: 127.0.0.2 (HTTP: 8500, HTTPS: -1, DNS: 8600, RPC: 8400)
 Cluster Addr: 127.0.0.2 (LAN: 8301, WAN: 8302)
Gossip encrypt: false, RPC-TLS: false, TLS-Incoming: false
 Atlas: (Infrastructure: 'armon/test' Join: true)
==> Log data will now stream in as it occurs:
[INFO] serf: EventMemberJoin: foo 127.0.0.2
[INFO] scada-client: connect requested (capability: http)
[INFO] scada-client: auto-joining LAN with [127.0.0.1]
[INFO] agent: (LAN) joining: [127.0.0.1]
[INFO] serf: EventMemberJoin: Armons-MacBook-Air.local 127.0.0.1

auto-join 機能はデータセンタ内でクライアントを join できるだけでなく、サーバ間で直接つながっていない WAN のようなグローバルクラスタでも利用できます。

この auto-join 機能は Atlas における常時無料の機能です。

■ Atlas 統合

Consul 0.5 は Atlas と統合した初のリリースです。Atlas は HashiCorp が提供する商用プラットフォームです。Atlas は何らかのアプリケーションを何らかのインフラにデプロイするための単一プラットフォームです。Atlas との統合は完全にオプションですが、Consul に対して新しい機能を提供するものです。

Atlas によって自動登録が仲介されるだけでなく、-atlas フラグを使うことで自動的に美しい Consul UI を有効化します。

この Consul UI は、現時点の Atlas アカウントがあれば無料で利用可能です。将来的には、UI で取り扱うノードやサービス数によって支払いのサブスクリプションによる上限を設けるかもしれません。ですが、オープンソースの Consul UI プロジェクトは、機能の範囲が狭くなるかもしれませんが、今後も常にフリーで使える正式な選択肢です。

将来の Atlas Consul 統合によって、ヘルスチェックを基盤とするアラートの通知が有効になりますので、PagerDuryや電子メールや SMS 等から受け取ることができます。これは Atlas との統合がもたらす簡単な一例です。

Consul ドキュメンテーションから Consul と Atlas 統合を有効化する詳しい情報を参照できます。

■ アクセス制御 (ACL) の拡張

Consul 0.4 は ACL サポートを取り入れた初めてのバージョンであり、キーバリュー・ストアによるアクセス制御を実装しました。Consul 0.5 においては ACL を拡張し、サービス検出や登録の保護をサポートしました。

ポリシーの設定は ACL トークン毎に HCL か JSON を用います。ポリシー言語はサービス・キーワードをサポートするように拡張されました。

# デフォルトでは全てのサービス登録を拒否
service "" {
  policy = "read"
}
# web サービスのみ登録を許可
service "web" {
  policy = "write"
}

Consul 0.5 では、ポリシー言語は読み込み (read) レベルの権限を指定できますが、制限を強制できるのはサービス登録のみです。この意味する所は、書き込み (write) レベルの権限を持つエージェントのみがサービス登録可能であり、あらゆるレベルの権限は検出 (discovery) のために用います。

Consul の将来のバージョンでは、サービス検出 (service discovery) に対しても制限をできるように拡張し、サービスの可視化に対するきめ細かな制御を行えるようにします。

■ 分散ロックと N+1 デプロイ

Consul の利点の１つはセッションをサポートすることで、クライアント側のリーダー選出 (leader election) を使うことができることです。しかしながら、アプリケーションを Consul に認識されるように調整したり、リーダー選出を実装することは難しく、エラーを起こしがちです。

これを単純化するために、アプリケーションがリーダー選出を透過的に扱えるよう、Consul に新しく lock というサブ・コマンドを追加しました。foo という高い可用性のサービスが必要とすると、私たちは少なくとも１つのインスタンスが稼働することを保証するため、少なくとも2台のマシンにデプロイしようと考えるでしょう。

Consul の lock を使えば、とるに足らないことです：

(node1) $ consul lock service/foo/lock ./foo.py
service foo running
(node2) $ consul lock service/foo/lock ./foo.py

私たちはこの同じコマンドを N 台のマシンで実行すると、Consul は１つのインスタンスが稼働するということのみ保証します。そのかわりに、私たちが同時にもう１つの foo インスタンスを実行したいなら、実行インスタンス数の上限を変更することができます。

(node1) $ consul lock -n=3 service/foo/lock ./foo.py
service foo running
(node2) $ consul lock -n=3 service/foo/lock ./foo.py
service foo running
(node3) $ consul lock -n=3 service/foo/lock ./foo.py
service foo running
(node4) $ consul lock -n=3 service/foo/lock ./foo.py

「-n」フラグを指定することで、私たちは分散ロックから分散セマフォまで切り替えることができます。可用性のために N インスタンスが必要なサービスにおいて、Consul lock は N+1 スタイルのデプロイを簡単にしますので、アプリケーション側で認識しなくても、Consul が複雑な所を管理することができます。

詳細については lock ドキュメントをお読みください。

■ メンテナンス・モード

Consul に対する一般的なリクエストは、ノードやサービスに対してメンテナンス・モード機能でした。これにより、ノードの廃棄や、更新準備のためにトラフィックを避けるために使うことができます。

Consul 0.5 はファーストクラスのオペレーションによって単純化します。ノードとサービスレベルのチェックを行う API がサポートされたので、maint というサブ・コマンドを使って単純化することができます。

以下はメンテナンス・モードにノードを切り替える例です：

$ consul maint -enable -reason Testing
Node maintenance is now enabled
$ consul maint
Node:
 Name: Armons-MacBook-Air.local
 Reason: Testing
$ consul maint -disable
Node maintenance is now disabled

これはアプリケーションのデプロイプロセスの一部に組み込んだり、セットアップやサーバ解体時のインフラ自動化に使うことができます。

詳細については maint ドキュメントをお読みください。

■ HTTP ヘルスチェック

これまでの Consul はスクリプトと TTL をもとにしたヘルスチェック機構を提供していました。スクリプトベースのチェックは Nagios チェックと互換性があるもので、TTL チェックは Consul の検出情報をアプリケーション側で簡単に認識できるものです。

Consul 0.5 ではネイティブな HTTP ヘルスチェックを内包しています。REST をベースとしたマイクロサービス (micro-services) は一般的なパターンであり、HTTP ヘルスチェックはこれらのアプリケーションと Consul との統合を簡単にします。HTTP ヘルスチェックの使用は非常に簡単であり、必要なのは http をチェックするパスと interval （監視間隔）をサービスにおいて定義するだけです：

{
  "name": "foo",
  "port": 8000,
  "checks": [{
    "http": "http://localhost:8000/health",
    "interval": "10s"
  }]
}

加えて、Consul 0.5 ではサービス毎に複数のチェックが設定できるようになったので、HTTP のチェックは既存のチェックに対しても追加できます。

詳細については checks ドキュメントをお読みください。

■ Ephemeral keys（一時キー）

Consul におけるセッションの初期設計では、キーバリュー・ストアでクライアント側のロックを実現することを目標にしていました。セッションはキーバリュー・ストアを使って様々なロックと関連づけることができ、Consul はセッションが無効化されると自動的にロックを解放することもできました。

頻繁にあった要望は、ZooKeeper が実装しているような ephemeral keys をサポートするというものでした。このサポートにあたり、Consul におけるセッションは設定可能な Behavior （挙動）をサポートするように拡張されました。このデフォルトの挙動は「release」（解放）であり、セッション中の全てのロックがセッション無効時に解放されます。これは後方互換性のための挙動です。Consul 0.5 では、behavior に「delete」（削除）を設定することができ、セッションが無効化されたときに何らかの保持されているキーを削除することができます。

以下は新しい behavior を使った例です：

$ curl -X PUT -d '{"behavior":"delete"}' localhost:8500/v1/session/create
{"ID":"acf52e93-6b45-6297-6425-bb97a340b144"}
$ curl -X PUT localhost:8500/v1/kv/test?acquire=acf52e93-6b45-6297-6425-bb97a340b144
true
$ curl -X PUT localhost:8500/v1/session/destroy/acf52e93-6b45-6297-6425-bb97a340b144
true
$ curl localhost:8500/v1/kv/test
セッションにおける新しい behavior については、こちらのドキュメントをお読みください。

■ セッション TTL

Consul の設計時に判断する鍵となるのは、セッションの障害検出のために heartbeat や TTL をベースとした手法ではなく、ゴシップ・プロトコルを使うことでした。これにより、いくつかのスケーラビリティの課題にかかわる基本的な問題を解決しましたが、Consul がゴシップ機構を利用できない場合には、複雑さが増しています。 セッションがアプリケーションのより幅広い範囲で利用できるように、Consul 0.5 ではセッションに対する TTL をサポートしました。これらは Google Chubby をモデルにしており、他のヘルスチェックの代替となる動作をします。クライアントが TTL とセッションを作成したあとは、TTL の期限切れでセッションが無効になる前に、TTL を更新することになります。 セッションの新しい挙動については、こちらのドキュメントをお読みください。

■ 鍵の自動組み替え（ローテーション）

Consul はゴシップ・プロトコルの暗号化をサポートしていましたが、これまで複数の鍵や鍵のローテーションを使うことができませんでした。Serf による影響を強く受け、Consul 0.5 では keyring サブコマンドを追加しました。これで新しい鍵をインストールしたり、鍵の表示や削除ができるようになります。 これらの新機能によって、簡単に暗号鍵のローテーションを行うことができます：

$ NEW=`consul keygen`
$ consul keyring -install=$NEW
==> Installing new gossip encryption key...
==> Done!
$ consul keyring -use=$NEW
==> Changing primary gossip encryption key...
==> Done!
$ consul keyring -remove=$OLD
==> Removing gossip encryption key...
==> Done!

詳細については keyring ドキュメントをお読みください。

■ アップグレード時の詳細

Consul 0.5 では複数の新しい内部コマンドを導入していますが、これまでのバージョンとの互換性はありません。つまり Consul 0.5 のサーバ・ノードで構成される Consul リーダーは、古いバージョンのサーバと同時に扱えません。一方、Consul 0.5 サーバは古いバージョンのクライアントとしては動作することができます。

詳細については、こちらのアップグレード手順をご覧ください。

また、acl_default_policy を「deny」に設定している全ての利用者は、アップグレード前に、それぞれのポリシーをサービス enforcement するように更新する必要があります。そうしないと、ACL によってサービス登録が拒否されてしまいます。

私たちは新機能の追加時、可能な限り後方互換性を持たせるように努めていますが、残念ながらリリースによっては複雑な更新手順が必要になるかもしれません。

■ ロードマップ

Consul 0.5 は、多くの新機能や改良や安定正やバグ修正を行った大規模リリースです。そのため、私たちはリリース後に新しい問題が起こりうると予想しています。

このような状況のため、Consul 0.6 が焦点とするのは、性能の改善やブロッキング・クエリの忠実性の改良、ピュアな Go 言語への移行です。それまでは、私たちは皆さんに Consul 0.5 を、これまで以上に私たちよりも楽しんでもらえることを望みます！

何かしら問題があれば、GitHub に報告をお願いします。

■ 参考

Consul 0.5 – HashiCorp
https://hashicorp.com/blog/consul-0-5.html