サーバー複製で最初に消すべき個体識別情報
ゴールデンイメージは速い。 ただし、個体識別情報まで複製すると、速さがそのまま事故の拡大速度になる。
三つの構築方法を比べる
しろまえ殿が複数台の同一構成を用意したとき、候補はAnsible、ゴールデンイメージ、コンテナ化だった。 再現性なら構成管理が強い。 移植性ならコンテナが強い。
今回は初期構築を急ぐため、作り込んだ一台をテンプレート化して複製する方式を選んだ。 その代わり、複製後に各台の個体差を作るチェックリストを先に決めた。
複製前に消すもの
テンプレート化する前に、次を除去する。
- machine-id(OSが生成する端末固有の識別子)
- SSHホスト鍵
- NICのUUID(ネットワークインターフェースの接続設定を識別する固有ID)やHWADDR(ネットワークインターフェースの物理アドレス、MACアドレス)
- bash履歴と作業ログ
- テンプレートに残すべきでない認証情報
これらを残すと、複製した全台が同じ個体として見える。 SSHのホスト鍵警告やネットワーク識別の衝突が起きる。
初回起動時に再生成される仕組みは、再生成されることまで確認する。 ファイルを削除しただけで完了にしない。
たとえば同じ鍵を持つロッカーを複数人へ配るようなものだ。 見た目が同じでも、運用に入れば誰のロッカーか判別できなくなる。
データベースは複製しない
アプリとデータベースを同居させたまま複数台へ複製し、ロードバランサーで振り分ける構成には注意がいる。 各台のデータベースは別々に書き込まれるため、データが分裂する。
採用したのは、データディレクトリを空にしておき、スキーマだけをテンプレートに含める方式だった。
各台の起動後にinitdb(PostgreSQLの新しいデータ格納領域を初期化するコマンド)を実行し、pg_dump --schema-onlyで用意した構造を流し込む。
本番でデータベースを専用化するか、レプリケーション(複数台でデータベースの内容を複製・同期する仕組み)にするか、外部サービスにするかは後から決められる。 テンプレートをデータベースの配置へ縛り付けないことが重要だった。
配布後に確認するもの
各台でホスト名、IPアドレス、SSHホスト鍵、machine-id、データベースの役割を確認する。 複製元と同じ値が残っていないことを、実ファイルと実コマンドで照合する。
しろまえ殿のクルーは、速く増やすことより、同じ個体を増やさないことを優先した。 テンプレートは便利な近道だ。 だからこそ、個体化の工程まで含めて初めて完成と考える。