Ticketing サーバーのデプロイ

環境変数 ​

ticketing.toml（任意）の各項目はすべて環境変数としても指定できます。優先順位は環境変数 > ticketing.toml > デフォルト値で、キー・ブール値は大文字小文字を区別しません。Dockerイメージはscratch ベースのため、設定は環境変数で注入するのが基本です（設定ファイルを使う場合はマウント後にCONFIGでパスを指定）。

シングル vs クラスター ​

• シングル（1台）: [cluster]（またはCLUSTER_*）がなければシングルノードです。最も高速ですが、再起動時に短い 瞬断があり、状態はインメモリのため再起動すると消えます（leaseが安全網になります）。
• クラスター（無停止）: 最低2台。各ノードは同一のCLUSTER_PEERS（優先順位順）と、自分自身を 指すCLUSTER_SELFを持ちます。生存しているノードのうち優先順位が最も高い1台がアクティブになり、 残りはスタンバイとしてリアルタイムでレプリケーションを受けます。詳しい原理は動作原理と プロトコル — サーバー間を参照してください。

KubernetesクラスターのデプロイにはStatefulSet + ヘッドレスサービスを使用します。各Podが安定した DNS名（ticketing-0.ticketing…、ticketing-1.ticketing…）を持つようにし、それらの名前を優先順位順に CLUSTER_PEERSに入れ、各PodのCLUSTER_SELFはdownward API（metadata.name）で自動注入します。

無停止再起動（ローリング） ​

1. スタンバイから1台ずつ再起動します（アクティブはそのままサービスを継続）。
2. 最後にアクティブを終了（Ctrl+C）すると、ハンドオフによりスタンバイが昇格し、クライアントが切り替わります。
3. 停止した旧アクティブを再度起動すると、現在のアクティブのスタンバイとして合流します（自動フェイルバックなし）。

関連情報 ​

• イメージ: sarolab/ticketing · Github: saro-lab/ticketing
• クライアント（ブローカー）にはすべてのノードアドレスを登録し、障害時に自動で切り替わるようにしてください。言語ごとの使い方は ライブラリを参照。