Ticketing Ticketingサーバーのデプロイ
実行環境
シェル
モード
expand_moreセキュリティ · ネットワーク(任意)
bash
クライアント接続例
rust
ncによる簡易テスト
bash
環境変数
サーバーの設定はすべて環境変数を通じて行われます。キーは大文字小文字を区別せず、 空の値は未設定として扱われ、フラグ形式の値は1/true/yes/onのときだけ真になります。 Dockerイメージはscratchベースのため、設定ファイルなしで環境変数のみから注入されます。
| 環境変数 | デフォルト | 説明 |
|---|---|---|
PORT | 5225 | シングルモードでのリッスンポート。クラスタモードでは無視され、代わりにCLUSTER_SELFのポートが使われる |
SOCKET_BIND | 0.0.0.0 | リッスンアドレス |
CLIENT_TOKENS | (なし) | クライアント認証トークンのカンマ区切りリスト。未設定の場合、空トークンが許可される |
CLUSTER_SELF | (なし) | このノードの広告アドレス、host:port。設定するとクラスタモードが有効になる |
CLUSTER_PEERS | (なし) | 全ノードの広告アドレスのカンマ区切りリスト。ちょうど3または5、全ノードで同じ順序、selfを含む必要がある |
CLUSTER_TOKENS | (なし) | ピア間認証トークンのカンマ区切りリスト |
TLS_CERT / TLS_KEY | (なし) | 証明書/秘密鍵PEMファイルのパス — 両方セットするとTLSが有効になる |
TLS_CA | (なし) | ピア証明書の検証用CA — 未設定ならシステム信頼ストアにフォールバック |
TLS_SKIP_VERIFY | false | ピア証明書の検証を省略 — テスト専用 |
DOCKER | false | クラスタモードで内部リッスンポートを5225/6225に固定 — 公式イメージではデフォルトで設定される |
DEBUG | ビルドに依存 | 1/trueでデバッグログを有効化 |
全体のルール(ポートの導出、広告アドレス、無停止でのトークンローテーションなど)は 設定 (環境変数)を参照してください。
シングル vs クラスタ
- シングル(1台):
CLUSTER_*がなければ単独ノードとして動作します。最速ですが、 再起動時に短い瞬断があり、状態はインメモリのため再起動すると失われます (leaseが安全網になります)。 - クラスタ(無停止): 3台または5台。 ノードはRaftコンセンサスによって1つの ロック状態を共有します — リーダーだけがリクエストを処理し、すべての状態変更は 過半数のコミット後にのみ確定されます。リーダーが落ちると0.5〜1秒以内に新しい リーダーが選出され、過半数が生きている限りロック状態とサービスは継続します。 詳しい原理は動作原理とプロトコル (クラスタ) を参照してください。
- クラスタの各ノードは、クライアントポートに加えて**Raftポート(クライアントポート
- 1000)**をリッスンします — ファイアウォールで両方のポートを開いてください。
KubernetesでのクラスタデプロイにはStatefulSet + ヘッドレスServiceを使います。 各Podに安定したDNS名(
ticketing-0.ticketing…、ticketing-1.ticketing…)を 与えてそれらをCLUSTER_PEERSに入れ、各PodのCLUSTER_SELFはdownward API (metadata.name)で自動注入します。
無停止再起動(ローリング)
核心となるルールは1つだけです — 常に過半数を生かしておくこと(3台なら同時に 1台まで)。
- フォロワーから先に、1台ずつ再起動します。再起動したノードが複製またはスナップ ショットで追いついたら、次のノードに進みます。
- 最後に、リーダーを落とします — 0.5〜1秒以内に新しいリーダーが選出され、 クライアントは透過的に切り替わります。
- 落としたノードを再び起動すると、フォロワーとして再参加します。
詳細な手順は無停止再起動(ローリング)手順 を参照してください。
参考
- イメージ:
sarolab/ticketing· Github: saro-lab/ticketing - クライアント(ブローカー)にはすべてのノードアドレスを登録し、障害時に自動的に 切り替わるようにしてください。言語ごとの使い方はライブラリを参照して ください。