自宅サーバ

自宅サーバの構成をひととおり書き出す

家に置いてあるサーバで何を動かしているのか、どういう方針で組んでいるのかをまとめた。

公開日更新日読むのにかかる時間約 2 分

サーバのラックを模した図

家にサーバを置いている。用途が増えるたびに構成が変わっていくので、いまどうなっているかと、なぜそうしているかを一度書き出しておく。

何が載っているか

物理は 2 台で、その上に仮想マシンとコンテナが載っている。だいたい次のような役割で分けている。

層 置いているもの
CDN 外向きの公開、証明書
物理ホスト 仮想マシンとコンテナの土台、バックアップ
仮想マシンとコンテナ ゲームサーバ、監視、リバースプロキシ
外から内へ、CDN・物理ホスト・仮想マシンとコンテナの 3 層が並ぶ図
外側の層ほど、止まったときの巻き添えが大きい

置き場所を分けているのは、止まったときに巻き添えになる範囲を小さくしたいから。バックアップは物理ホストに集めていて、大事なものは家の外(クラウドのストレージ)にも送っている。家の中にしか無いと、家ごと失ったときに戻せない。監視は、集めるところまでを中でやり、記録と通知は外のサービスに任せている。サービスと同じ箱に置くと、その箱が落ちたときに何が起きたか分からなくなる。

方針

組み方については、だいたいこの 3 つを守っている。

  1. 手で触らない。設定はリポジトリに置いて、そこから流し込む
  2. 復旧を先に用意する。壊れない仕組みより、壊れたあと戻せることを優先する
  3. 障害のときに使う経路を、平時の仕組みに依存させない1

とくに 1 つめは、自分ひとりで運用している以上いちばん効く。手で直した設定は、半年もすると、なぜそうしたのか自分でも思い出せなくなる。

流し込みの形

設定は宣言として書いて、まとめて適用する。たとえばコンテナの定義はこんな見た目になる。

services:
example:
image: registry.example.com/example
restart: unless-stopped
volumes:
- ./data:/var/lib/example

適用そのものは CI から走らせていて、手元から本番へ直接つなぐことはしない。つなぐと、その日の手元の状態が本番に混ざる。

これから書くこと

  • ストレージとバックアップの取り回し
  • 監視をどこまで作るか(作りすぎると見なくなる)
  • ゲームサーバの運用

この連載では、構成そのものよりなぜその形にしたかを残していく。

脚注

  1. 復旧の手順が、普段の自動化の成功を前提にしていると、肝心なときに使えない。 ↩︎

サイト内を検索

カテゴリ
タグ